My RH dedicated server has been DoS by some lame hackers. Is there a way to block such kind of attacks.

Firewall (ipchains, etc)

You could also use this line:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

What would this do to help?

protects from SYN flooding attacks

Could you provide some more info on what protocols they used, time of attack, used source addresses, maybe some logs from Snort/tcpdump/whatever else and what you tried to stop it?

My main job is web developper. I'm quite new to Linux and do not know much about it. But I suppose that my server is not vulnerable to SYN flood ( I've used a SYN flooder to test my server and it had not been affected). So may be the hackers used another method to attack. Although everything is over but I still want to know how to prevent DoS in the future.

Thanks.

I guess, real hardware controled firewall would be the best solution when it is configured tightly. Masquerading your network is one more step to securing your box and entire network, packet filter wich is a basic software firewall is not enough to prevent anybody from sneaking around your box. There are too many options available, custom access control list (ACL), I suggest for now getting a book, first comes to my mind is "Hacking Exposed" which has also different derivatives like "Hacking Linux Exposed" http://www.amazon.com/exec/obidos/AS...707679-4628865 , another good source is "Linux Firewalls" http://www.amazon.com/exec/obidos/AS...707679-4628865

It could be ddos or drdos'ed, check out www.grc.com, I believe they have some really good docs on DoS and their variants.

[edit] this is the direct link to the doc: http://grc.com/dos/grcdos.htm [/edit]

~Progster

I just seen this, while compiling new kernel for one of my system, and it is disabled by default.

Thanks!

If its a syn flood, which you should check by running tcp dump to make sure. you can enable syn cookies. Also, you can increase the number of syns the stack will take by entering following command
sysctl -w "net.ipv4.tcp_max_syn_backlog=XXX"

where xxx is a large number. Redhat default is 1024, i have gone as high as 4096. In some lab tests it significantly mitigated some of the syn flood effects.

Some excellent posts in this thread, did some digging to come up with some starting points, so it's presented rather sparse as not to cramp your Google searching stylee :-]

= Type of DoS attacks:
- TCP floods (SYN, ACK, RST) *Google ?q="3-way handshake SYN flood"
- ICMP echo request (Smurf, Fraggle)
- UDP floods (chargen)
- DDoS attacks are "distributed", DoS attacks launched from compromised hosts.

= DoS defense:
- ISP filtering
- Host filtering (Netfilter)
Filtering means you/ISP should check that IP source addresses do not contain reserved or broadcast addresses, on inbound (ingress) that the source address shouldn't be the same as the destination addresss and reverse on outbound (egress) routes.
- Rate limiting
- Kernel SYN cookies
- TCP Wrappers
- Tweak network serving application/master (xinetd) parameters, like for instance Xinetd using "sensors" and explicitly denying in Apache's conf: allow,deny. Maybe also check out max childs etc.
- Test your setup!

= Handle DoS attacks:
- Start tcpdump capture if possible: save evidence of attack.
Pro: evidence available, con: none
- Rate-limit sources: try and curb traffic.
Pro: may alleviate load, con: may slow response for legitimate traffic if applied w/o scrutiny
- Track down offending source addresses.
Pro: aid in contacting remote ISP's, con: may be impossible due to spoofed source addresses
- Aggresively filter sources: drastic way to try and curb excess traffic.
Pro: may alleviate load, con: may also cut out legitimate traffic
- Close down networking daemons: no-way-out effort.
Pro: reduces load, con: obviously doesn't serve availability
- Notify remote ISP to apply egress filtering.
Pro: may alleviate load, con: depends on ISP service-mindedness so YMMV.
- Notify ISP to apply ingress filtering.
Pro: alleviates load, con: depends on ISP service-mindedness so YMMV.
The ISP may also decide in their wisdom to just kill the pipe for just now.

More docs:
SANS - Help Defeat Denial of Service Attacks: Step-by-Step: http://www.sans.org/dosstep/index.htm
CERT - Denial of Service Attacks: http://www.cert.org/tech_tips/denial_of_service.html
NWC - Fireproofing Against DoS Attacks (forms of): http://www.nwc.com/1225/1225f38.html
SANS - ICMP Attacks Illustrated: http://rr.sans.org/threats/ICMP_attacks.php
Xinetd Sensors: http://www.gate.net/~ddata/xinetd-sensors.html
Xinetd FAQ: http://synack.net/xinetd/faq.html

============================
DDOS Attacks:
SANS - Consensus Roadmap for Defeating Distributed Denial of Service Attacks: http://www.sans.org/ddos_roadmap.htm
SANS - Spoofed IP Address Distributed Denial of Service Attacks: Defense-in-Depth: http://rr.sans.org/threats/spoofed.php
SANS - Understanding DDOS Attack, Tools and Free Anti-tools with Recommendation: http://rr.sans.org/threats/understan...nding_ddos.php
Juniper.net - Minimizing the Effects of DoS Attacks: http://arachne3.juniper.net/techcent...te/350001.html
CISCO - Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks: http://www.cisco.com/warp/public/707/newsflash.html

*If any docs don't come tru due to registration, bad internet weather, no blood sacrifices been made to SCSI chains etc etc, just prefix with "http://216.239.51.100/search?q=cache:" to get 'em from the Google cache :-]

You should also configure your router(s) for eggres filtering. If you do so, spoofing will we a lot harder. In this way your machines wont be that interesting for hackers to launch DDOS attacks from.

irony... oh irony...if u click on this link (today ; tue jul 19 2005)-->
http://docs.linux.com/article.pl?sid.../1719214&tid=5

u see this -->
"Stopping DDOS Attacks
Wednesday March 26, 2003 (05:13 PM GMT)
Considering how difficult they are to trace back to the original offender, if anyone is willing to do so, what might be an alternative means of ending DDOS attacks?
Click here!
Read more at linuxjournal.com �


and then u click on -->

"Click here!
Read more at linuxjournal.com "

u see this -->
"Linux Journal Is Currently Unavailable Due to a DDoS Attack
Sorry for any inconvenience."