No ads? Contribute with BitCoins: 16hQid2ddoCwHDWN9NdSnARAfdXc2Shnoa
Oct 222016

Yesterday lots of people found the Internet disappearing on them due to a significant DDoS attack against the DNS infrastructure of one company. Now there are all sorts of suggested fixes for this sort of problem, some of which are useful.

However it is notable that people have not mentioned one method built into DNS which could have been used more effectively. Indeed one suggestion was for the DNS to do something it already does – caching.

When you ask your ISP’s DNS servers to resolve a name such as, the answer that your ISP’s DNS server gets back contains several bits of information in addition to the answer you are interested in (the IP address to connect to). One of which is how long to cache the value for, which means that your ISP’s DNS servers can save themselves some work for as long as they are allowed to cache the answer for.

Now it is awfully convenient to set this value to something like 5 minutes because if you have a need to change the value, it is nice to have the value change as quickly as possible.

But it also increases your vulnerability to a weaknesses in the DNS infrastructure.

If you increase the time-to-live (TTL) value to something more like 24 hours, then your DNS servers (or more usually the DNS servers of your DNS service provider) are required less frequently which means that if something takes them offline for any reason then there would be a decreased impact. It will still stop some people from getting the DNS answers they need, but the proportion unable to get an answer will drop dramatically.



Sep 282016

One of the things that has happened recently was that a commentator on security matters (Brian Krebs) was taken offline by a massive denial of service attack, which (not so) mysteriously happened after he published an article on denial of service attacks. The short version of the story was that his site was hit by a denial of service attack totalling approximately 650Gbps (that’s roughly 6,000 times as much network bandwidth as your typical broadband connection), when his denial of service protection threw their hands up in the air and said: “That’s too much like hard work for a pro-bono service” and gave him 2 hours to move his site.

Google helpfully provided an alternative with Project Shield, and the site was reasonable quickly available again. And to be fair to the original denial of service attack providers (which I’m not naming), this level of attack was sufficient to cause problems to their paying customers and protecting from this level of attack is very expensive.

And indeed paying for denial of service protection is very expensive; the income for the entire lifetime of this blog site would pay for approximately 2 hours of protection. If that.

There are two aspects to this attack, although to be honest neither are particularly new.

The first is technical. Most distributed denial of service attacks are quite simple in nature – you simply ask a question of a dumb “server” with the return address of the site you want to attack. If you send out enough questions to enough dumb “servers” (which can actually be simple workstations or even Internet of Things devices), then you can overwhelm most sites on the Internet.

There are two fixes for this :-

  1. Don’t run dumb and insecure servers.
  2. ISP’s should stop allowing people to forge addresses on network traffic (Ingres Filtering or BCP38).

The second fix is the simplest method, but given how successful the decades long campaign for ISPs to do ingres filtering has been, tackling both ISPs and dumb servers is worthwhile.

As this latest attack may have been chiefly by IoT devices simply sending requests to the victim, the implementation of ingres filtering may not have been of much use in this case, but it is still worthwhile – this attack is not the only one that is happening. Attacks are happening constantly. However, tackling these “dumb servers” that were controlled by the attacker is also a priority, and we need to start seeing concrete action by the ISPs to tackle their customers’ mismanaged networks (home networks in many cases) – aggressive filtering of infected customer networks, and customer notifications that include advice.

Of course ISPs are not going to like doing that just as IoT manufacturers don’t like paying more to make secure appliances. Well, it’s time to name and shame the worst offenders; the bad publicity may help to counteract the lack of incentive to invest in processes that don’t immediately help the bottom line.

The second aspect is rather more serious. We now have an Internet where it is relatively easy to silence anyone who says something you do not like – if you’re rich enough to hire a denial of service gang. Anyone that is who cannot afford protection from such gangs, and there are suspicions that some gangs also provide denial of service protection services.

And this story is not the first time it has happened, and we need to start thinking about mechanisms to keep smaller publishers online when attackers try to censor them. Unless we want all our media controlled by the big players of course.

2016-03-28-swamped bandstand.small

Feb 222014

Having had a wee bit of fun at work dealing with an NTP DDoS attack, I feel it is long past time to tackle the root cause of the problem – the ISP’s who have neglected to implement ingress/egress filtering despite it being considered best practice for well over 15 years. Yes, longer than most of us have been connected to the Internet.

It is easy to point at the operators of NTP services that allow their servers to be used as attack amplifiers. And yes these insecure NTP servers should be fixed, but given the widespread deployment of NTP in everything it could take up to a decade for a fix to be universally deployed.

And what then? Before the widespread use of NTP for the amplification distributed denial of service attacks, DNS was commonly used. And after NTP is cleaned up? Or even before? There are other services which can be exploited in the same way.

But the way that amplification attacks are carried out involves two “vulnerabilities”. In addition to the vulnerable service, the attacker forges the packets they send to the vulnerable service so that the replies go back to the victim. Essentially they trick the Internet into thinking that the victim has asked a question – millions of times.

Forging the source address contained within packets is relatively easy to do, and it has been known about for a very long time and the counter-measure has also been known for nearly as long. To put it simply, all the ISP has to do is to not allow packets to exit their network(s) which contain a source address that does not belong to them. Yet many ISPs – the so-called “bad” ISPs – do not implement this essential bit of basic security. The excuse that implementing such filters would be impossible with their current routers simply doesn’t wash – routers that will do this easily have been on the market for many years.

It is laziness pure and simple.

These bad ISPs need to be discovered, named, and shamed.

Mar 282013

This article is short on references because I haven’t gotten around to filling them in … they will come

The fuss in the mainstream media about the distributed denial of service (DDoS for short) attack against Spamhaus goes to show that journalists need to buy more drinks for geeks, and the right geeks. It is nowhere near as bad as described, although the DDoS attack was real enough and definitely caused “damage” :-

  1. New York Times:
  2. Daily Mail:

This article is not intended to be totally technically accurate in every detail; it is intended to describe the incident in enough detail and with enough accuracy that it can be understood without übergeek status.

So What Happened?

Spamhaus are experiencing on ongoing distributed denial of service attack that started on the 20th March, and is ongoing. The initial attack very quickly overwhelmed their 10Gbps (that’s about 1,000 times faster than your Internet connection) link to the Internet. Whilst this disrupted the Spamhaus web site, and various back office services, the main service that Spamhaus provides kept running (as it is distributed).

The very clued up geeks at Spamhaus who have had plenty of experience of being under attack, very quickly contacted CloudFlare which started hosting their web sites and other back office services at numerous data centres around the globe. Their services rapidly started returning to life – it isn’t the sort of thing that can be done instantly, and probably took a lot of late nights.

However the attacks escalated and reached levels of up to at least 300Gbps (that’s about 30,000 times faster than your Internet connection) or about 13Gbps of traffic for each of CloudFlare’s 23 data centres. That’s a lot and could be responsible for Internet slowdowns …

The Internet Is Slow. Is It The DDoS?

Well perhaps. We all have a very understandable tendency to blame known events for problems we’re having. Is the Internet slow? It must be that DDoS . But it is not necessarily so.

And if all the Internet was slow for you, it is quite possible that you were unknowingly taking part in the attack! Because the attack relied on infected PCs together with other stuff described below.

It is also possible that some parts of the Internet were overwhelmed by the DDoS. Reports have indicated that Internet services plugged in alongside the CloudFlare data centres (or in them) were suffering somewhat because of the extraordinary levels of traffic. However, this is the Internet and there is always lots of stuff going on that may cause slower performance than normal in various corners of the ‘net.

Was This The Biggest DDoS Attack?

Possibly. The figure of 300Gbps (and it was probably larger than that – the 300Gbps figure was through one Tier-1 ISP) probably qualifies as the largest known public DDoS.

However DDoS attacks are not always made public; there could well have been larger attacks that were not made public.

Various responses have indicated that the attack was not as serious as described by others :-


It may be that these commentators are mistaken to the extent that they didn’t see a problem; it may be that European and Asian networks were more prone to a slow-down than elsewhere.

What Is A Distributed Denial Of Service Attack?

If you were an attacker, you could try sending network traffic as fast as your PC could handle to the target of your attack. However the amount of traffic you could send would be very limited – you can’t send more than the speed of your Internet connection. Say 10Mbps … a lot less than most large services use for their own Internet connections.

To make an attack more effective, you will want to have lots of people send traffic as quick as they can. And the easy way to do that is to infect PCs with some sort of malware, and use your control of those infected PCs to send out that denial of service traffic. At which point it becomes a distributed denial of service attack because the attack traffic is distributed around the Internet.

And if you can find some way of amplifying your attack traffic so that say 10Mbps of traffic becomes 1Gbps of traffic, you make your attack much more effective.

So How Was This Done?

The details of what went on become pretty hairy very quickly, but very simply :-

  1. The attacker takes control of a large number of infected PCs to make his or her “robot army” to send out network traffic under their control.
  2. The attacker instructs their robot army to send out DNS requests as quickly as possible with the source address forged as the victim’s address.
  3. The negligent ISP allows those packets out by not applying source filtering.
  4. The network traffic reaches any number of misconfigured DNS servers that answer with a larger reply sent to the victim’s address.


This is short for the domain name system and is a service that turns names into numbers (amongst other things). You type in a name such as and the DNS server your PC is configured to talk to turns that name into an Internet address such as or possibly 2001:db8:0:1234:0:5678:9:12. Your PC then makes a network connection to that numeric address in the background, and fetches a web page, a music stream or some other content you want.

Without the DNS we would all have to rely on numeric addresses to make connections – a lot tougher!

There’s another factor here as that DNS is an amplifying service – you ask for a name such as, and the answer is a whole lot longer than just the numeric address you “need” as it can (and often does) contain a number of network addresses together with associated information :-

% dig  

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 4

;			IN	A

;; ANSWER SECTION:		61	IN	A		61	IN	A		61	IN	A		61	IN	A		61	IN	A		61	IN	A

;; AUTHORITY SECTION:		126160	IN	NS		126160	IN	NS		126160	IN	NS		126160	IN	NS

;; ADDITIONAL SECTION:		126160	IN	A		126160	IN	A		126160	IN	A		126160	IN	A

;; Query time: 1 msec
;; WHEN: Sat Mar 30 09:52:59 2013
;; MSG SIZE  rcvd: 264

If you are talking to a misconfigured DNS server, it could answer even when it should not. Normally DNS servers are configured to answer just for those they are intended to provide answers to – your ISP’s DNS servers will answer your questions, and not mine. However if they are misconfigured, they will answer any question and will function as a DDoS amplifier.

This does not include public DNS servers such as OpenDNS, or Google’s public DNS servers – they are specially configured to avoid acting as a DDoS amplifier – probably by imposing a rate limit to stop answering if you ask too many questions.

Source Filtering?

When you click on a link in your web browser, your browser sends out a network packet containing the request (“GET /webpage”), and that network packet contains the destination of the web server – so your request reaches it, and your own address – so the web server knows where to send the answer! Your own address (in these circumstances) is known as the source address.

With appropriate software, you can forge your source address so that replies to your request go back to a different place. Without that only the very simplest DDoS attacks would work.

Of course, it has been best practice to block forged source addresses since well, not long after the beginning of the Internet. This is known as source filtering. An Internet router is capable of deciding that packets coming in from wire A should not have the address assigned to wire B, so should be dropped on the floor.

An Internet router that doesn’t do that is poorly configured.

So How Can This Be Stopped?

The answer is that we have known how to stop this sort of attack for at least a decade. And indeed the best Internet citizens have done so for years.

The trouble lies with those on the Internet who are not necessarily the best Internet citizens. Of the big three remedies, two are probably being neglected because managers of ISPs do not see the business benefits of applying those remedies. And there isn’t a business benefit, but a social responsibility.

The three remedies are :-

  1. The average Internet user needs to take action to prevent their PC from getting infected. Get anti-virus protection, and an Internet firewall. If the PC acts weird, get it looked at. And if the Mac acts weird, get it looked at too (yes they do get infected).
  2. ISPs should apply BCP38 (which dates back to 2000) which specifies source filtering.
  3. ISPs running DNS servers should ensure that their DNS servers are properly configured to only answer queries for legitimate clients.

And if you happen to know a senior manager at an ISP, ask them about BCP38 and if they’re doing it – source filtering is probably the most important action here.

But Who Is Responsible?

It is easy to get distracted by the problems caused by those leaving poorly configured router, and insecure PC lying around on the Internet. Whilst their owners are responsible for effectively leaving tools around that attackers can use (and all too often do use), they are not directly responsible for the attack.

The attacker is.

But who were they?

The fairly credible rumours are that the attackers were either Cyberbunker or, as part of a campaign against the actions of Spamhaus. Various criminals behind the flood of spam targeting your mailbox with all sorts of rubbish have long complained about the actions of Spamhaus, as they try and prevent spam arriving. And Cyberbunker is an ISP dedicated to providing hosting to services that may get shut down elsewhere – they deal with anyone except paedophiles and terrorists, which leaves a whole world of swamp dwellers that you would really rather not know about. And spammers.

Who Are Spamhaus?

Spamhaus are subject to a great deal of black propoganda – including accusations of blackmail, extortion, censorship, and probably kicking cats too. The reason? They help identify spammers, so that ISPs can choose to block spam.

Spammers are somewhat irritated by this – their business model relies on polluting your mailbox so that the 1% (or so) of people who do respond to spam is a large enough number that they can carry on making money. And they get irritated very quickly if someone tries to interfere with their “right” to use your inbox to make money.

Mail server operators have long been blocking spammers using a whole variety of methods, and some of the best collaborated on producing lists of addresses of spammers that others could use. These evolved into DNS based RBLs, and one of the most respected groups of volunteers became known as Spamhaus.

You may be thinking that you still get plenty of spam, so they cannot be doing too great a job. But :-

  1. You may be with an ISP that chooses not to use Spamhaus.
  2. You don’t see the spam that gets blocked. Even if you see dozens of spam messages a day, you may be seeing only 5% of the spam that was sent your way.

It is telling that amongst those in the know, those who deal with spam and Internet abuse in general, there is practically nobody who thinks of Spamhaus as anything other than the good guys.


Facebook Auto Publish Powered By :

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.