Remko Lodder wrote:
Joel V. wrote:
Hopefully the situation will be fixed soon. One final question though: are
there any quick steps one can take to protect their server from DDOS attacks
like these?
If someone wants to flood your network connection with packets there is
nothing you can do about it, your line can only handle so much packets
even if you just drop them or something.
You'll just have to wait till the ISP can resolve it or the attack
stops :(
Well, that all depends on the impact the flood has on your network
connection and what kind of contract you have with your upstream
provider. If the amount of traffic coming in over your uplink does not
exceed the available uplink bandwidth by a large margin, you will not
noticeably suffer packet loss due to congestion. I've had a 100MBit/s
DDoS-attack against a server that was connected to a 100MBit/s link and
didn't even notice it, even though I was logged in over SSH. Such
amounts of traffic may cost you a lot of money though, so it may be wise
to filter it at the upstream even if it doesn't degrade performance
noticeably. From your e-mails I concluded your link was swamped, due to
too much traffic coming in. If that's the case, there's not really much
you can do..
Generally speaking, the following may help. A possibly important factor
to consider is the number of packets per second you're receiving. Given
the packet size of over 9000KBytes in your tcpdump output, the packet
rate can't be too much. However, if you're receiving, let's say 80Mbit/s
in 64 bytes small packets, that's 150Kpps, which can have quite an
impact depending on what your system does with all those packets.
So, what you want your system to do, is to handle as much packets per
second as possible, and to have them thrown away as soon as possible.
Using interrupt coalescing, polling, checksum or possible even
reassembly offloading will help against deadlocks. When there's only
one, or a limited set of attacking IP addresses, it's probably easiest
to just block traffic from that addresses in the first rule of a
firewall. Even when lots of hosts are attacking, firewalling them may be
beneficial (be sure to use tables in your firewall configuration,
instead of lots of per-address rules!). As far as I've seen in the past,
only a small amount of DDoS-attacks are based on spoofing the entire
32-bits address range (most hosts can only spoof the host-part of the
address due to filtering on access routers). So if the largest part of
traffic you're seeing comes from non-spoofed or hardly-spoofed
addresses, firewalling becomes possible.
If firewalling isn't an option and traffic is sent to a port that isn't
listening, blackholing (sysctl net.inet.tcp.blackhole and
net.inet.udp.blackhole) can be useful. This ensures that your system
doesn't send ICMP unreachables or TCP RST's back. By default, FreeBSD
ratelimits these to 200 per second, which should suffice. Still, in that
case the packets will have to traverse more of the TCP/IP stack, so if
you're seeing lots of packets per second, blackholing may reduce the
load somewhat.
Lastly, if the packets can not be filtered because they are sent from
lots and lots of random source addresses, or firewalling isn't an
option, and the packets are sent to an active service, the service
itself could possibly be tuned to handle the load better. For DNS
there's not much options besides running a more performant nameserver or
dropping incorrect queries without sending a 'REFUSED' answer. For other
applications accept_filters may be useful or possibly ratelimiting
built-in the service (inetd, ntp, sendmail/postfix, etc).
So, even though DDoS-attacks are hard to handle, there's still some
possibilities left. The only thing nothing can be done about without
help from the uplink ISP(s) is having a lot more traffic coming in over
the uplink than it can handle.
Good luck with your sucky situation,
--
Pieter
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
