This too?!

netstat -s
Ip:
35475696 total packets received
1 with invalid headers
3484 with invalid addresses
0 forwarded
0 incoming packets discarded
35470557 incoming packets delivered
34932772 requests sent out
4 reassemblies required
2 packets reassembled ok
Icmp:
1614 ICMP messages received
1258 input ICMP message failed.
ICMP input histogram:
destination unreachable: 339
timeout in transit: 921
source quenches: 1
echo requests: 353
8107 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 7754
echo replies: 353
Tcp:
0 active connections openings
1215 passive connection openings
17 failed connection attempts
134 connection resets received
504 connections established
35435997 segments received
34899221 segments send out
12 segments retransmited
71 bad segments received.
34821220 resets sent
Udp:
24246 packets received
7572 packets to unknown port received.
0 packet receive errors
25961 packets sent
TcpExt:
2338 SYN cookies sent
5327 SYN cookies received
3660 invalid SYN cookies received
17 resets received for embryonic SYN_RECV sockets
497 TCP sockets finished time wait in fast timer
129 delayed acks sent
Quick ack mode was activated 3 times
17326 times the listen queue of a socket overflowed
17326 SYNs to LISTEN sockets ignored
11 packets directly queued to recvmsg prequeue.
8 packets directly received from prequeue
4455 packets header predicted
9954 acknowledgments not containing data received
8465 predicted acknowledgments
2 times recovered from packet loss due to SACK data
1 TCP data loss events
10 fast retransmits
2 other TCP timeouts
3 DSACKs sent for old packets

Cheers m8's..

Can you try with iptables to drop all traffic coming to port 80 but only let your IP get in on port 80?
Then try to see if you can reach your website.

That's not a definitive solution, just a try to see if iptables alone can help.

I was never ddosed, so it's just suposition.


So what's the attack exactly?

It connects to port 80 and sends something if I got it right?
Or is only (potentially spoofed) Syn attack?
If it connects, can you give a line of these connections from your apache log?
Also how many different IPs dos you? For this you will need some self-made scripts.



Yes, that would be a good thing to try also.
In the same idea, you could use the tarpit rule. It sometimes gives good results.

Hmm, I'll try that, to block all the other IP-s and allow only myself...nice idea.

yea you got it right, it sends some crappy message, but nothing goes to the apace_log, nothing ... so I belive it's not a valid request, for apache, I mean yea.. because the packet isn't a GET, is a $MyNick .. bla bla...

Oh.. and A L O T of IPs ddos me, cause it's really easy to find some hubs with lots of users...

Basically maliciously redirecting legitimate DC++ clients from some DC++ hub to victims webserver. Attacker spoofs/sends a ForceMove command to all the legitimate clients on the hub who are redirected to a "new hub" by the attacker. Except instead of redirecting them to a new DC++ hub, the attacker points all the clients at the victims webserver on port 80. All the clients then send DC++ login packets (the whole $MyNick thing) to the victims webserver which overloads it. It sort of resembles a Smurf attack. Though in this case there are soo many connection attempts that it's hard to actually see if all of them are the DC++ logins or if it's a mixed attack with DC++ and SYN_flood. They are seeing a lot of packets, which is why they should contact their ISP. Look at all the Snort logs, all those packets are arriving in less than a second.


*If* any of these packets are getting through (and if Apache isn't fubared), then it should likely be serving up HTTP 501 "Method Not Implemented" responses as there isn't a valid HTTP method (GET/POST/FIND) in these DC++ packets

I would be careful in how you do that. It will decrease the amount of data transmitted per connection (by shrinking window size to 0), but each connection will retransmit until timeout so that you'll see and overall increase in number of packets. Plus connections will stay in the conntrack table longer than if the system just sent an RST. If you do, don't load the conntrack module or use the NOTRACK target in the raw table.

Ok, let's say I use:

iptables -A INPUT -m string --algo bm --string "DCPLUSPLUS" -j DROP

But I don't want to DROP only the packet, I want to DROP or BlackList the IP.
How do I do that?

I understood the vector (p2p.. bad..) but not the method. So easy... Looks like a big flaw in this DC protocol. Thanks for explaining.
Yes that's a lot. Poor snort
Modifiying a DC++ and connect to these hubs could be funny. Depending on the celverness of the protocol and of distribution of nodes... the new era of worms.
Legitimate traffic. Characterising is important for fighting against it.
Yes sure, tarpit is a trick to handle with care.. works in very few case, looking at the bandwidth it's probably not adapted.
It's why I would run some scripts with tcpdump output to know howmany source ip there are.
And sure yes, not any connection tracking, it's useless at this point and adds too much processing.
Huhh that's harder than my idea.
Poor iptables

cOOkie, your ISP contact is on holiday or what?
He probably has more tools and more ways to act than you???

My ISP kind of sucks, he says he cannot help me .

So... what to do what to do... ipp2p is no good.

You could do a log message before the DROP rule. Use pretty much the same rule but put a LOG target on it and use the --log-prefix "SOME MESSAGE". You'll need to use the 'limit' match so only a few packets are logged (otherwise your log will probably get bombed). Something like:
Then have script parse the log file every 15 min and add the new IP addresses. I'd also recommend that you use the REJECT target, so that the DC++ clients get an immediate icmp unreachable message and don't keep trying to resend the same packet.

There are probably some scripts in the "Failed SSH login attempts" thread near the top of the forum that you can alter for your purposes. Also make sure that when you add a new iptables rule to ban an IP, make sure that it is added above the LOG rule that way you don't see that same IP in the logs anymore and you'll be getting fresh unique IPs to ban.

You could likely do the same thing using the directories in /var/log/snort. You still haven't said how many unique IP addresses you are seeing, which is an important question. If you have a zillion IP addresses that you have to ban then you are going to have some problems doing that with IP tables (though I guess slow packet handling is better than the current situation).

I thought about that, but I think the catch is that you can't tell what hubs these clients were connected to beforehand based on the packets alone (there's no 'referer' or anything). Otherwise it might be interesting to see where the ForceMove packets are coming from.

Ok man, I'll try to create some rules, thx again for your help.

Well, I can't do it.. I need some help, again..

From what I've seen, I have to LOG all the IP's with the STRING, and DROP them...
How do I do that? I need to log them, that's easy, but how do I read the IP's from the LOGS and block them? Thats where I'm stuck...
I don't want to filter only port 80, or I donno.. I want to -s BLACKLISTEDIP -j DROP .

Can you help? I'm not really into this logging stuff.. i'm stuck..

Not too much into iptables so cant help you there but I believe Capt Caveman was saying that you needed to hack together a perl script or something. You need to write this Heres a start:

1.You've logged all those connections and you have all the bad IP addresses
2.Let your script parse the log file and read only all the bad IP addresses
3.Put all the bad IP addresses into a file
4.Create your exact iptables rule for dropping all packets from a specific IP.
5.Put this in a loop each time only changin the IP...each IP will be replaced by a bad IP
6.This way you have 1 trillion bad IP blocking iptables rules.
7.Once you have these rules ready dump them into the iptables config file or wherever your other rules are. Make sure you still allow legitimate traffic like yourself or you'll end up blocking yourself OUT

Hope this clarifies things a bit? Anyone please correct me if I'm wrong.

All the best and keep that chin up

Cheers
Arvind

This is just an idea to block offending IP's using (requiring) Snort, Guardian and iptables ("ipset"). I haven't read *ANY* data on this attack: no Apache logs and no packet captures. It may or may not work so YMMV(VM) as usual.


Short overview
Tune Snort performance-wise only looking at TCP/80 traffic and only using the custom ruleset, make Guardian fetch the IP's and block using iptables' ipset.


Caveats
You need to use iptables "ipset" module. Blocking using other iptables modules may have a resource starvation risk (memory).


What you need
I. Ipset.
See http://ipset.netfilter.org/features.html for default instructions. We'll opt for blocking whole netranges here,
- configure a drop list:
(Do check syntax yourself thrice, I'm not responsable for errors: you are.)

II. Snort
- Copy your /etc/snort/snort.conf to /etc/snort/snort_current.conf
- Edit /etc/snort/snort_current.conf and disable preprocessors you don't need like rpc_decode, bo, telnet, portscan, arpspoof, perfmon, xlink. Set "config detection: search-method lowmem". If all tests out well you can disable this later on. Disable unified and payload logging and make Snort log to it's own snort.alert file in fast mode. You only need the offending IP after all.
- Comment out all the rulesets.
- Create a custom ruleset (say "/etc/snort/dcplusplus.rules"):
Now add that "/etc/snort/dcplusplus.rules" to your config.
- Enable "include threshold.conf" and edit accordingly (alert per IP once per 3600 secs):
- Add the mapping (for reference):
- Add reference (for reference):
- Edit or add to your BPF config (to keep from checking traffic from "known good" ranges). Do substitute the subnet with your management IP ranges, `man tcpdump` for BPF filter details:
Edit your Snort commandline to include "-c /etc/snort/snort_current.conf -F /etc/snort/bpf.conf -A fast -N". Remove any commandline options that log packets or do unified logging. Test adding the "-T" switch.

III. Guardian.
See installation and configuration instructions in the tarball: http://www.chaotic.org/guardian/guardian-1.7.tar.gz
- Change Guardian's block.sh script iptables line so the subnet gets added to the set:
IV. TEST WELL BEFORE USING. Do use common sense and check syntax yourself. Check thrice. I'm not responsable for errors: you are.

HTH but remember YMMV(VM).

might be a tad off track but..

can't a rule be created to set the firewall to drop packets for say 5 minutes from an ip where that ip sends say, 30+ requests per second, and list that ip as suspicious.

then once an hour say, if they reappear we move those into a day long banlist, then if the 'usual suspects' keep appearing, move those to a permaban since those are the worst offending ips, probably botted, and maybe inform their isp?

i've no idea how to go about that in the software you mention tho.

Okay...its almost impossible to defend yourself against this attack. Did i say almost?...no...its impossible. Heres how it works:

You have 2 clients connected to a hub( C1 C2 ). When C1 tries to connect to C2 it initiates the Client2Client handshake specific to DC++. C1 sends a $ConnectToMe to the hub containing its IP address and port. The hub then sends the same command with all of C1's info ( IP and port ) to C2.
C2 initiates a connection with C1 and sends $MyNick and immediately after that $Lock. C1 responds with $Key and $Lock and waits for C2 to send its $Key command after which C1 finally sends its $MyNick back to C2. So to make a long story short its like this:

C-->Hub: $ConnectToMe
Hub-->C2: $ConnectToMe
C2-->C1: $MyNick
C2-->C1: $Lock
C1-->C2: $Key
C1-->C2: $Lock
C2-->C1: $Key
C1-->C2: $MyNick

This exploit basically takes advantage of $ConnectToMe and sends multiple requests to the hub with the IP and port of the victim server as its own. The Clients on that Hub receive the requests and initiate a connection back to the IP and Port they receive( which can be a web server or an SQL server).

The only solution to this is to block all the IP's connecting to you and feeding you this bogus string. It will NOT solve your problem entirely because you will still experience DOS until those IP's get droped and that happens only after u already receave a connection and an apache child gets spawned. Decrease the "Timeout" limit to say 30 seconds in httpd.conf and hope for the best. At least this way you wont have a bogus connection to your server for 6 mins. We ended up dropping over 8000 IP's in less then 30 mins.

Good Luck!

Hmmm..

One solution is to blacklist ip's, the other solution.. I think could be to filter the http requests so if it's no GET / POST, etc. to block it.