[Urgent] Help - Blocking DoS Attacks.

R

rhasson

Hello All!

Yesterday my server was a victim of a denial of service attack.

It is a high-performance server, but still can be a victim.

I would like some advice about the best way to block a DoS Attack.

It was a kind of SYN attack, completely large number of packets.


Code: 
21:35:20.002060 IP 110.45.144.89.43184 > myserver: [|domain]
21:35:20.002063 IP 110.45.144.89.43184 > myserver: [|domain]
21:35:20.002066 IP 110.45.144.89.43184 > myserver: [|domain]

I'm posting it as urgent, because by now I did not find the right way to block it and I'm still vulnerable.

I already blocked the IP above, but the attacker is changing the machine to attack again.

I really would appreciate some advise.
 
Tricky. If your attacker manages to flood your connection then there's really nothing you can do. Your ISP is the only one that can help in that case. This is because the packets will need to be stopped before they get routed to your connection.

If your internet connection is able to handle it but your server buckles under the load you may be able to throttle the connection requests with a few clever firewall rules.
 
I'm in contact with the ISP as well, do you have any suggestion about how this kind of packets can be stopped on the router/firewall settings?

Thanks for your reply!
 
If you have PF running then using synproxy might help.

I'm not sure what you're trying to protect though. It looks like your DNS service is being attacked?
 
Hi SirDice,

Yes, this was my DNS service being attacked.

But I also received attacks on port 80 as well.

I can say that I being attacked by all ports! unfortunately...
 
Hey SirDice,

One more update.

Now I blocked ALL the ports, just leaving 80 and other port that I'm using for SSH.

I also blocked all UDP protocol connections (because I don't use).

So my plan now is to get the PF using the synproxy to port 80 to prevent the attacks at all!!

Do you think that my logic would protect the server from all kind of DoS attacks?

Thank you!
 
Your DNS service uses UDP/53. It only uses TCP/53 for oversized replies and zone transfers. If your nameserver serves replies to DNS requests from the outside, make sure inbound UDP/53 and TCP/53 are open. Note also that synproxy is typically used when the server is not running on the firewall itself, but on a machine behind it.
 
Hi DutchDaemon,

Thanks for your collaboration as well.

This server is behind a firewall (running FreeBSD too).

All the settings of IPFW I'm doing on the firewall machine.

Making only port 80, 25 and other for SSH open.

Also, blocking all UDP protocol (because this machine don't resolve DNS, is just a webserver).

And then, to help protect against any DoS attack on the possible open ports (80,25,ssh), I was thinking on the synproxy, as advised.

So, with those methods I would be protected against DoS attacks?
 
No, you're not protected as in 'they will no longer happen', but synproxy will stop the attacks from reaching the servers behind the firewall if these attacks do not negotiate a full three-way handshake with the firewall, and if they do, the firewall will take the brunt of the attack instead of the servers behind the firewall being flooded with connection attempts directly. Implementing some connection throttling and state limiting (don't know if and how ipfw does that) should help further by ignoring or holding off IP addresses that are too pushy.
 
Ok, I got your point on that!

I was doing some research.

To complement the method above, I would like to include:

in /etc/sysctl.conf:

* net.inet.tcp.msl=7500
If ACK is delayed more than 7500ms, the connection will not form

* net.inet.tcp.blackhole=2
When set to '2', all packets arriving on a closed port are dropped without an RST being sent back.

* net.inet.icmp.icmplim=50
Controls the maximum number of ICMP "Unreachable" and also TCP RST packets that will be sent back every second.

* kern.ipc.somaxconn=256 (too low?)
Limits the maximum number of sockets that can be open at any one time.

Looking for all ways :)
 
You must log in or register to reply here.
Back
Top