I'm not sure. I believe that the packets should ideally get dropped even before they are processed by the kernel itself. Even if you dont drop the packets..the kernel will eventually drop it due to too many timeouts/re-transmissions..only it wont be quick enough to stop the DOS. SO ideally I'd say whatever filtering device you use - should drop it before the Kernel processes the packet.

I'm not certain though ; if someone who knows more about this can back up what I said I'd feel more comfortable.

Cheers
Arvind

You should begin by the easier solutions.
I would first try to tweak some kernel options, as said by Capt_Caveman
Also he mentionned modevasive, did you try it?

Do you also have burst limit on SYN packets in iptables?

Snort is supposed to be an intrusion detection system, not a firewall. It can be very resource intensive. Running it on the same machine as apache could make things worse IMO.

Yes, we have mod_evasive
We also have SYNWatch on that interface.
Don't have syn burst limit (iptables), but we tried it days ago and was not working.
Will try the kernel mods.


Any other ideea will be great, and about snort ... yeah ... at our traffic rating
it will be a great resource consumer.


Regards,

That thread is closed and I think this is why?
feels like i am watching a movie.
<sorry for contributing nothing>

this is the output from snort .. please give us a rule to drop $MyNick .....

If you have Snort-Inline working then you can simply use the 'drop' action. Once you are comfortable that everything is working properly you can switch to sdrop if you like (probably using a threshold limit would be better).

Though the string "Pk=DCPLUSPLUS" might be useful triggering as well. Also make sure to edit the config file properly so that $HTTP_SERVERS and $HTTP_PORTS variables are accurate.

If you are still working on getting Snort-Inline working you may find this helpful.

If you are concerned about the resources consumed by Snort, you can also use iptables string match. I believe it's still not part of the basic iptables installation, so you'd need to do the whole patch-o-matic and kernel recompile to use it.

a little questions .. all that $EXTERNAL_NET and so over must be replaced with my ip / port etc?

ty for help ...

I usually define $HOME_NET with whatever IPs or IP ranges are on my network and then just set $EXTERNAL_NET as !$HOME_NET. $HTTP_SERVERS and $HTTP_PORTS are what they sound like. You can use actual IP addresses or ranges of IPs (in CIDR notation) in place of any of those variables if you like.

The Snort docs are excellent resources:
http://www.snort.org/docs/faq/1Q05/node34.html

now ... what should i say to iptables:

iptables -A INPUT -p tcp --dport 80 -j QUEUE

or

iptables -A OUTPUT -p tcp --dport 80 -j QUEUE

?

and the final rule for me is:

snort loggs a lot of data in log folder but the site is still unreachable ... any updates pls/.

You'll want to send packets coming into the box from the internet to the QUEUE, so this will either be INPUT or FORWARD. If Apache is running on that machine then you'll send packets in INPUT to the QUEUE, if the webserver is on another machine inside the network and DNATed then you'll want to use FORWARD. You use OUTPUT for analyzing packets going outbound from the system/network to the internet (which you don't need and adds overhead).

i've done all the above but still the site can't be reached .. and in console i still see Possible SYN Flood on port 80 messages.

any other ideea or a better rule.

Yup, me and ipv6waiting are gettin' crazy over here xD

/var/log/snort is like this:
But, no good !

You may want to change the 'drop' action to 'reject' to eliminate retries. Also, take a look in /var/log/snort and see how many unique IPs are you seeing? How many alerts per IP? What I'm getting at is that if these are coming from a limited number of IP addresses, you can block them out-right with IPtables.

If you've legitimately tried all of the above recommendations (TCP/Netfilter/Apache tuning) then you're really at the limits of what you can do by yourself to mitigate it. The next option would to be to throw several load-balancing proxy servers in front of the webserver and let them split the connection load and then only the valid HTTP requests would be proxied to the internal webserver.

I think you're also at the point where you should contact your ISP and see if they can help you mitigate the attack on their end. These are real connection attempts, not spoofed packets, so they should be able to null route much of it. So I would definitely contact them and let them know what's going on. Make sure to explain in detail the type of traffic that you are seeing (DC++ connection attempts on port 80) and why (malicious redirection of DC++ clients using the ForceMove command). Send relevant logs as well.

All this time.. we still h ave'nt fixed this issue, if you look here :

Snort received 118092 packets
Analyzed: 13297(11.260%)
Dropped: 104585(88.562%)
Outstanding: 210(0.178%)
===============================================================================
Breakdown by protocol:
TCP: 13244 (99.601%)
UDP: 42 (0.316%)
ICMP: 6 (0.045%)
ARP: 5 (0.038%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
ETHLOOP: 0 (0.000%)
IPX: 0 (0.000%)
FRAG: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
===============================================================================
Action Stats:
ALERTS: 0
LOGGED: 13297
PASSED: 0
===============================================================================
Snort exiting

I think that... we have a bunch of packets, don't we? lol. Oh.. that happened in only 5 SECONDS.

You might want to disable all your rules except the DC++ one. That will drastically reduce the number of alerts Snort is triggering and setting off.

Yeah its normal ..the number of packets you're receiving .

Cheers
Arvind