LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 02-24-2015, 11:16 AM   #31
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled

Its still not being blocked, sadly :/

I just did a top while its being hit, and the service is at 100% CPU , sy still low.
 
Old 02-24-2015, 12:15 PM   #32
Miati
Member
 
Registered: Dec 2014
Distribution: Linux Mint 17.*
Posts: 326

Rep: Reputation: 106Reputation: 106
It might be helpful to only LOG stuff right now so that you know what is being caught or not.
Basically, instead of -j DROP, do -j LOG.
It won't fix the problem, but it might help figure out what will.

Logs should be in /var/log/syslog
 
Old 02-24-2015, 12:24 PM   #33
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Miati View Post
It might be helpful to only LOG stuff right now so that you know what is being caught or not.
Basically, instead of -j DROP, do -j LOG.
It won't fix the problem, but it might help figure out what will.

Logs should be in /var/log/syslog
I already sent him packet captures when there is an attack and whats normal traffic.

Last edited by Skidprevention; 02-24-2015 at 03:23 PM.
 
Old 02-24-2015, 12:51 PM   #34
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,679

Rep: Reputation: Disabled
Quote:
Originally Posted by Skidprevention View Post
Its still not being blocked, sadly :/

I just did a top while its being hit, and the service is at 100% CPU , sy still low.
Since the server process is consuming all available CPU power then yes, I agree that the incoming network traffic is somehow affecting the process.

However, I'm fairly certain that the rule is correct, as I've actually set up a small test environment where I'm generating UDP packets with a payload of just zeroes and filtering them with this rule:
Code:
iptables -t filter -A INPUT -p udp --dport 27035 -m u32 --u32 "0>>22&0x3C@8&0xffffffff=0x0 && 0>>22&0x3C@12&0xffffffff=0x0" -j DROP
This rule absolutely does filter UDP packets to destination port 27035 with a UDP payload of 8 bytes or more, where the first 8 bytes are all zeroes.

You can quite easily verify this for yourself if (like Miati suggested) you create an identical rule with a LOG target (something like -j LOG --log-prefix "empty UDP: ") and then send an empty packet from another system using, say, netcat:
Code:
echo -ne \\0\\0\\0\\0\\0\\0\\0\\0 | nc -u -w1 destination_host 27035
You should then be able to see an entry in the log. Usually, iptables LOG targets end up in /var/log/syslog, but that is somewhat distribution-specific.

Since server is still affected by the attack, then either the rule isn't actually in effect (perhaps it's being negated by other rules in the chain), or the attack is more sophisticated than the capture files indicate, and there might are other, non-empty UDP packets involved.

Last edited by Ser Olmy; 02-24-2015 at 12:52 PM.
 
Old 02-24-2015, 01:04 PM   #35
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
Since the server process is consuming all available CPU power then yes, I agree that the incoming network traffic is somehow affecting the process.

However, I'm fairly certain that the rule is correct, as I've actually set up a small test environment where I'm generating UDP packets with a payload of just zeroes and filtering them with this rule:
Code:
iptables -t filter -A INPUT -p udp --dport 27035 -m u32 --u32 "0>>22&0x3C@8&0xffffffff=0x0 && 0>>22&0x3C@12&0xffffffff=0x0" -j DROP
This rule absolutely does filter UDP packets to destination port 27035 with a UDP payload of 8 bytes or more, where the first 8 bytes are all zeroes.

You can quite easily verify this for yourself if (like Miati suggested) you create an identical rule with a LOG target (something like -j LOG --log-prefix "empty UDP: ") and then send an empty packet from another system using, say, netcat:
Code:
echo -ne \\0\\0\\0\\0\\0\\0\\0\\0 | nc -u -w1 destination_host 27035
You should then be able to see an entry in the log. Usually, iptables LOG targets end up in /var/log/syslog, but that is somewhat distribution-specific.

Since server is still affected by the attack, then either the rule isn't actually in effect (perhaps it's being negated by other rules in the chain), or the attack is more sophisticated than the capture files indicate, and there might are other, non-empty UDP packets involved.
There is a slight variation at times.

This is the standard with all 0's
Code:
000000000000000000000000000000000000
And this is the one where something is apparently added to the end, I just noticed that. It changes the last 8 hex it seems.
Code:
000000000000000000000000000099e5e0c6
Next time it runs, I will capture once more to see if all the 0's only are gone.
 
Old 02-24-2015, 01:28 PM   #36
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,679

Rep: Reputation: Disabled
Quote:
Originally Posted by Skidprevention View Post
Next time it runs, I will capture once more to see if all the 0's only are gone.
Just note that tcpdump will capture traffic as it enters the interface, before iptables does any filtering.

(I'd love for there to be a way to capture only packets that made it through the iptables ruleset. Edit: And so would someone else, it seems, and that person did something about it: http://www.honeynet.org/node/691)

Last edited by Ser Olmy; 02-24-2015 at 01:36 PM.
 
Old 02-24-2015, 01:54 PM   #37
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
Just note that tcpdump will capture traffic as it enters the interface, before iptables does any filtering.

(I'd love for there to be a way to capture only packets that made it through the iptables ruleset. Edit: And so would someone else, it seems, and that person did something about it: http://www.honeynet.org/node/691)
I checked my syslog, this was posted.
Code:
Feb 24 19:50:39 fr-2-eu kernel: nf_conntrack: table full, dropping packet
Feb 24 19:50:40 fr-2-eu kernel: nf_conntrack: table full, dropping packet
Feb 24 19:50:42 fr-2-eu kernel: nf_conntrack: table full, dropping packet
Then I did
Code:
sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000
sysctl -w net.netfilter.nf_conntrack_generic_timeout=120
sysctl -w net.ipv4.netfilter.ip_conntrack_max=256000
Will keep you updated.
 
Old 02-24-2015, 04:10 PM   #38
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Ser Olmy, do you have any other means of communication? I cannot reply to the emails sadly, maybe you could send one through LQ and we can speak on there?
 
  


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
iptables not blocking ssh attacks mfoley Linux - Security 12 04-20-2014 01:58 PM
Hello / DDoS attacks cybernet2u Linux - Security 7 11-21-2009 10:30 PM
iptables not blocking brut force attacks (something simple?) MikeOfAustin Linux - Security 6 11-20-2008 12:51 AM
DDOS attacks Challengers alamlinux Linux - Security 2 03-23-2008 02:12 PM
Concerning DDoS attacks joji_in_changwon Linux - Security 13 11-27-2007 12:12 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 07:04 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