Tag Info

Hot answers tagged

97

You are experiencing a denial of service attack. If you see traffic coming from multiple networks (different IPs on different subnets) you've got a distributed denial of service (DDoS); if it's all coming from the same place you have a plain old DoS. It can be helpful to check, if you are able; use netstat to check. This might be hard to do, though. ...


43

They're 13 highly available clusters of servers, not simply 13 servers. Among other things, root nameserver operators are required to have enough capacity to handle three times their normal traffic load (RFC 2870). This leads to rather large clusters. However, the root nameservers only serve responses for the top level domains themselves, i.e. com., net., ...


40

Help! My house is on fire! Lets burn down the fire station to get their attention!


26

tail -n 10000 yourweblog.log|cut -f 1 -d ' '|sort|uniq -c|sort -nr|more Take a look at the top IP addresses. If any stand out from the others, those would be the ones to firewall. netstat -n|grep :80|cut -c 45-|cut -f 1 -d ':'|sort|uniq -c|sort -nr|more This will look at the currently active connections to see if there are any IPs connecting to port ...


23

A DDOS (or even a DOS), in its essence, is a resource exhaustion. You will never be able to eliminate bottlenecks, as you can only push them farther away. On AWS, you are lucky because the network component is very strong - it would be very surprising to learn that the upstream link was saturated. However, the CPU, as well as disks I/O, are way easier to ...


22

Doing as you propose is unethical, potentially illegal and technically pointless. Redirecting your DDoS traffic to another site makes you as complicit in the attack as the people attacking you. You do not like dealing with the mess that such an attack causes; why do you think that the sysadmin at any other site will like it more. How would you feel if ...


19

Please do not write obvious comments (hire a professional person/company) - we'll consider that after this issue is resolved. I'm sorry to say that you are not managing that security incident the right way then. If there's a fire in your house, are you waiting for it to extinguish itself before calling the fire-fighters? If you have nobody in staff ...


18

First, this kind of attack is not (mainly) targeting DNS itself as your title suggests. It will of course create some additional load on DNS servers but the main purpose is to DDoS someone else. Bad server configuration might make it worse but in the end this issue is inherent in the design of DNS and UDP and, in fact, any stateless communication protocol. ...


18

An "open DNS resolver" is a DNS server that's willing to resolve recursive DNS lookups for anyone on the internet. It's much like an open SMTP relay, in that the simple lack of authentication allows malicious 3rd parties to propagate their payloads using your unsecured equipment. With open SMTP relays, the problem is that they forward spam. With open DNS ...


16

Generally your options are (in the order you should try them): Your ISP Your ISP should be willing to block (and deal with) DoS attacks on your behalf. At minimum they should be willing to block the traffic to your port/system with a firewall (though they may charge you for that privilege). Your comments indicated that your ISP's attitude is "If it's not ...


16

What is going on here? Is my name server under attack? Can I do something about this? What is going on here? It's impossible to tell from the munged log entries. Here are just a few possibilities: Your service is popular in China. Congrats Someone misconfigured a script that uses your API Someone's running code that gathers DNS information for ...


15

If your version of FreeBSD is relatively modern, top has a -m option that shows the top I/O talkers if you supply it with the "io" parameter: top -m io In this case, I'd also use the -S option (to show system processes, in case one of them is the culprit). To behave better under load, I would use -q (to renice it to run at a higher priority), and -u (to ...


15

Over at the ISC SANS Diary entry for this topic, there is a very strong clue in one of the comments. By DarkFiber: I used to work with an organization that came under constant attack from anonymous and their LOIC tool. It's very easy to mitigate these DoS attacks as they're not particularly bandwidth intensive. Simply limiting the connections per IP per ...


14

You can also further isolate your EC2 instances by putting them behind an Elastic Load Balancer and only accepting traffic from the ELB instance. This puts more of the onus on Amazon to manage DDOS attacks. I assume that you'll still have SSH open to all, so it's likely you'll still see some rogue traffic coming in there, unless you can lock down that port ...


14

netstat print network connections -n show numerical address grep :80 filter connections connect to port 80 cut -c 45- get only 4th and 5th column cut -d: -f1 take the first field separate by colon sort | uniq -c sort by IP address and count the numbers of unique IP sort -rn reverse the numerical sort You can use awk instead of cut -c 45- to get the 5th ...


14

These attacks have been around for ages, they just became popular again the last couple of months. They work like any regular amplification attack: a host spoofs a query so that the source IP address seems to be the targetted host. The NTP server sends its answer to the spoofed address. Since the answer for specific query types can be quite large and usually ...


12

Quanta & DTest explained what the command does. Everyone will tell you that a few hundred connections does not a DoS make (talk to me when you have at least 5-10 thousand), and I'll expand on that by saying that in order for it to be a DDos you'd be seeing a lot more entries (probably with a lot more connections each) than what you're showing above. ...


12

You should be working with your hosting company to mitigate the attack. They likely have other resources and means with which to deal with a DDOS attack. It is better handled at the network edge rather than the target.


12

No is the effective answer. It is not the absolute answer since a theoretical condition exists where one could successively ask each upstream connection to the next to look at their complete dump of traffic and tell you where the packet came from. In a sustained attack with a lot of volume from a single source, one might be able to do this with live data and ...


11

There are several different types of DDoS so any generic information about them may only be correct for one particular type. For instance, the idea that a DDoS always exhausts your bandwidth is incorrect. What you need to do is analyse (some of) the traffic, determine why it's breaking your site, find a way of identifying it and then decide on an action ...


11

Ask your ISP to produce logs showing your server's involvement in the incident (a suspicious traffic graph, for example, generated by data from your ISP's routers or switches). If they can produce such evidence, your system is suspect. If your machine was in fact involved in a DoS attack and you didn't initiate such action yourself your machine is almost ...


11

You did not mention your operating system. Linux has netfilter/iptables, Net/Open/FreeBSD has pf, Windows Server 2008 R2 has the Windows Firewall with Advanced Security which would easily be able to filter traffic based on source ip addresses. There is nothing that will be able to (reliably) filter based on a geographical location, though. But depending on ...


11

There is no easy way to stop DDoS attacks. Get in touch with your provider and ask them for help. No program will help you against a DDoS which is intended to consume your bandwidth, you can only absorb these attacks by having more capacity and working with your upstream providers to dismantle the attack.


10

To limit traffic by source IP, based on what @sysadmin1138 says, there's a great iptables module called "hashlimit". Here's an example set of rules: iptables -A INPUT -p tcp --dport 80 -m hashlimit --hashlimit-upto 50/min \ --hashlimit-burst 500 --hashlimit-mode srcip --hashlimit-name http -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j DROP What ...


10

IP packets don't contain any information about the path they traversed (with the exception of the TTL header, but that wouldn't tell you what it was initially). So there is no practical way to do this. You could contact your upstream provider, and they might be able to tell roughly where it came from if they have large network. But unless it is a serious ...


10

Assuming your port size is smaller then 1Gbps: Simple answer. Get a hardware firewall. Fighting a dDoS, especailly one in the Gbps range is not going to happen at the actual server. If all the traffic is coming from port 53, have your provider block port 53 upstream.


10

You can't identify the origin of the attack-- the packets your DNS server is receiving are from spoofed source addresses. Basically, an attacker is sending packets with forged source addresses to your DNS server. They're asking it questions that will result in it sending large responses. To use your DNS server as an attack tool the attacker is spoofing the ...


10

You can eliminate this single point of failure by using two DNS providers. It might also be feasible to run your own DNS server on one of your servers. GoDaddy allows you to do zone transfers from their servers (IIRC premium DNS is required for this). Get a second DNS provider which allows you to run a slave server (or run it yourself). Adjust NS/Nserver ...


9

They don't. The root nameservers just have to tell you what nameservers handle com. From then on, you don't need to go to them to handle any domain inside com. The root nameservers have no idea who owns example.com. They're root nameservers, not com nameservers. What slimsuperhero said is also true. Many high-volume nameservers use anycast to have a single ...


9

Absolutely yes, because a DDoS attack is designed to overwhelm server resources. Meaning your load average shoots up & your memory is maxed to the point of swapping out to disk. And it does not have to be just an attack on port 22. I have managed tons of web servers that become unreachable due to the scenario I describe above. The best solution to an ...



Only top voted, non community-wiki answers of a minimum length are eligible