LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 03-07-2007, 09:09 AM   #31
c00kie
Member
 
Registered: Mar 2007
Location: CORE
Distribution: FC6, FreeBSD, XP?
Posts: 34

Original Poster
Rep: Reputation: 15

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..
 
Old 03-07-2007, 09:13 AM   #32
nx5000
Senior Member
 
Registered: Sep 2005
Location: Out
Posts: 3,307

Rep: Reputation: 57
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.



Quote:
Originally Posted by Capt_Caveman
You may want to change the 'drop' action to 'reject' to eliminate retries
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.

Last edited by nx5000; 03-07-2007 at 10:20 AM.
 
Old 03-07-2007, 10:20 AM   #33
c00kie
Member
 
Registered: Mar 2007
Location: CORE
Distribution: FC6, FreeBSD, XP?
Posts: 34

Original Poster
Rep: Reputation: 15
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...
 
Old 03-07-2007, 03:28 PM   #34
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 69
Quote:
Originally Posted by nx5000
So what's the attack exactly?
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.


Quote:
If it connects, can you give a line of these connections from your apache log?
*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

Quote:
In the same idea, you could use the tarpit rule. It sometimes gives good results.
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.

Last edited by Capt_Caveman; 03-07-2007 at 03:33 PM.
 
Old 03-07-2007, 04:02 PM   #35
c00kie
Member
 
Registered: Mar 2007
Location: CORE
Distribution: FC6, FreeBSD, XP?
Posts: 34

Original Poster
Rep: Reputation: 15
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?
 
Old 03-07-2007, 04:45 PM   #36
nx5000
Senior Member
 
Registered: Sep 2005
Location: Out
Posts: 3,307

Rep: Reputation: 57
Quote:
Originally Posted by Capt_Caveman
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.
I understood the vector (p2p.. bad..) but not the method. So easy... Looks like a big flaw in this DC protocol. Thanks for explaining.
Quote:
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.
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.
Quote:

*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
Legitimate traffic. Characterising is important for fighting against it.
Quote:
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.
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.
Quote:
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?
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???

Last edited by nx5000; 03-07-2007 at 04:48 PM.
 
Old 03-07-2007, 06:35 PM   #37
c00kie
Member
 
Registered: Mar 2007
Location: CORE
Distribution: FC6, FreeBSD, XP?
Posts: 34

Original Poster
Rep: Reputation: 15
My ISP kind of sucks, he says he cannot help me .

So... what to do what to do... ipp2p is no good.
 
Old 03-07-2007, 09:32 PM   #38
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 69
Quote:
Originally Posted by c00kie
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?
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:
Code:
iptables -A INPUT -m string --algo bm --string "DCPLUSPLUS" -m limit --limit 10/minute -j LOG --log-prefix "WARNING: DC++ DOS ATTEMPT"
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).

Quote:
Modifiying a DC++ and connect to these hubs could be funny.
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.
 
Old 03-08-2007, 08:34 AM   #39
c00kie
Member
 
Registered: Mar 2007
Location: CORE
Distribution: FC6, FreeBSD, XP?
Posts: 34

Original Poster
Rep: Reputation: 15
Ok man, I'll try to create some rules, thx again for your help.
 
Old 03-10-2007, 06:31 AM   #40
c00kie
Member
 
Registered: Mar 2007
Location: CORE
Distribution: FC6, FreeBSD, XP?
Posts: 34

Original Poster
Rep: Reputation: 15
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..
 
Old 03-11-2007, 12:19 AM   #41
live_dont_exist
Member
 
Registered: Aug 2004
Location: India
Distribution: Redhat 9.0,FC3,FC5,FC10
Posts: 257

Rep: Reputation: 30
Quote:
Originally Posted by Capt_Caveman
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.
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
 
Old 03-11-2007, 08:04 AM   #42
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,409
Blog Entries: 55

Rep: Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582
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:
Code:
ipset --create blacklist nethash
iptables -A INPUT -m set --set blacklist src -j DROP
(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"):
Code:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"DDOS DC++"; flow:established,to_server; content:"DCPLUSPLUS"; reference:lq,533834; classtype:attempted-dos; sid:30001
; rev:1;)
Now add that "/etc/snort/dcplusplus.rules" to your config.
- Enable "include threshold.conf" and edit accordingly (alert per IP once per 3600 secs):
Code:
threshold gen_id 30001, sig_id 1, type limit, track by_src, count 1, seconds 3600
- Add the mapping (for reference):
Code:
echo '30001 || DDOS DC++ client to server || lq,533834' >> /etc/snort/sid-msg.map
- Add reference (for reference):
Code:
echo 'config reference: lq http://www.linuxquestions.org/questions/showthread.php?t=' >> /etc/snort/reference.config
- 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:
Code:
echo 'not src net 10.1.1.0/24' >> /etc/snort/bpf.conf
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:
Code:
# source-to-24 (Bash only):
/location/of/ipset --add blacklist "${source%.*}.0/24"
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).
 
Old 03-11-2007, 10:09 AM   #43
Cliffster
LQ Newbie
 
Registered: Feb 2007
Posts: 26

Rep: Reputation: 15
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.
 
Old 04-07-2007, 07:28 AM   #44
d3nv3r
LQ Newbie
 
Registered: Apr 2007
Posts: 2

Rep: Reputation: 0
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!
 
Old 04-07-2007, 09:17 AM   #45
c00kie
Member
 
Registered: Mar 2007
Location: CORE
Distribution: FC6, FreeBSD, XP?
Posts: 34

Original Poster
Rep: Reputation: 15
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Verlihub addouns Padawan.AVT Linux - Server 0 12-12-2006 01:27 PM
VerliHub on Slackware? :-/ NightSoul Linux - Software 4 07-27-2006 05:46 PM
Trying to install verlihub z9_87 Linux - Software 0 10-19-2005 05:20 PM
Apache getenv bug? wu1821 Linux - General 1 06-29-2005 10:00 AM
Slackware 9.1 and Apache bug? xipxap Slackware 3 10-14-2003 11:09 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 10:16 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration