iptables help for newbie

x42bn6 · 03-21-2007, 07:09 PM

Running dmesg | less on a server I have control over gave me these messages (tons more):

TCP: Treason uncloaked! Peer 195.166.237.42:7081/80 shrinks window 1773266768:1773266769. Repaired.
TCP: Treason uncloaked! Peer 195.166.237.42:7081/80 shrinks window 1773266768:1773266769. Repaired.
TCP: Treason uncloaked! Peer 195.166.237.42:11489/80 shrinks window 2014710254:2014710255. Repaired.
TCP: Treason uncloaked! Peer 195.166.237.42:11489/80 shrinks window 2014710254:2014710255. Repaired.
TCP: Treason uncloaked! Peer 195.166.237.42:12121/80 shrinks window 2060906964:2060906965. Repaired.
TCP: Treason uncloaked! Peer 195.166.237.42:12139/80 shrinks window 2054277643:2054277644. Repaired.
TCP: Treason uncloaked! Peer 195.166.237.42:12121/80 shrinks window 2060906964:2060906965. Repaired.

The IP is blacklisted just about everywhere (http://www.completewhois.com/cgi-bin...splay=webtable) and I do get the feeling we are getting leached?

So I would like to ask how to set up an iptables rule to block this IP address. Unfortunately, I am a Linux server newbie and don't know how. Any help, please?

Simon Bridge · 03-21-2007, 07:18 PM

Code:

iptables -A INPUT -s 195.166.237.42 -j DROP

This should go right after the conditional "accept" that lets tcp packets through. I hope you have your firewall set with default DROP policy...

It is likely the attacker will just switch to a different IP when they get blocked.
http://kerneltrap.org/node/7182
... for an identical problem discussed.

x42bn6 · 03-21-2007, 07:27 PM

I ran it and checked the iptables command:

Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
DROP all -- pix.linkserve.net anywhere

Has it done its job properly? The IP address matches the range for pix.linkserve.net but I don't see that IP address anywhere in the console - is this OK?

win32sux · 03-21-2007, 07:59 PM

just to add to Simon_Bridge's suggestion: in cases like this, it's recommended to use an "-I" instead of an "-A"... this inserts the rule at the top of the chain and eliminates any possibility of packets from that IP getting sent to ACCEPT by a rule above ("-A" appends the rule to the end of the chain)...

Code:

iptables -I INPUT -s 195.166.237.42 -j DROP

FWIW, you can get a better view with this instead of "iptables -L":

Code:

iptables -nvL

you will see the IP doing it like that... the "n" tells iptables to skip doing domain name lookups (your problem IP resolves to pix.linkserve.net)

Simon Bridge · 03-21-2007, 10:27 PM

You are using the RH firewall - (is this RHEL - or are we still talking mandriva here?) you need to revise your firewall rules in the light of the services you want to run. One really wants a DROP policy, then explicitly open the needed services.

What you have a an ACCEPT policy, so you must explicitly DROP anything you don't want. See the difference?

Make sure you say what program you are using to view the iptables rules ... use programs directly whenever possible to avoid confusion when you are posting about problems. Thus: iptables -L to list the rules ... or -nvL as suggested (thanks).

However, if you are no longer getting the attack messages, then it must be OK. Check again later to see if the attack resumes from a different IP.

x42bn6 · 03-22-2007, 06:01 AM

Well, the other guy who runs the forum (he's more technical than me) has added a rule thanks to you guys helping me out last time:

Code:

> iptables -nvL
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RH-Firewall-1-INPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain INPUT (policy ACCEPT 442K packets, 86M bytes)
 pkts bytes target     prot opt in     out     source               destination         
  50M 4259M RH-Firewall-1-INPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       all  --  *      *       195.166.237.42       0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 65M packets, 72G bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain RH-Firewall-1-INPUT (2 references)
 pkts bytes target     prot opt in     out     source               destination         
<!-- 0.0.0.0/0 stuff -->
    0     0 DROP       all  --  *      *       86.126.25.217        0.0.0.0/0

The last one was from help I got on this forum a few months ago.

So I should delete the rule with the -A flag above, and then run the new command with -I?

win32sux · 03-22-2007, 12:33 PM

Quote:

Originally Posted by x42bn6

So I should delete the rule with the -A flag above, and then run the new command with -I?

yeah, you could do that... like:

Code:

iptables -D INPUT -s 195.166.237.42 -j DROP
iptables -I INPUT -s 195.166.237.42 -j DROP

you could also do it for the other IP you are filtering like:

Code:

iptables -D RH-Firewall-1-INPUT -s 86.126.25.217 -j DROP
iptables -I INPUT -s 86.126.25.217 -j DROP

you *really* should get your firewall going with an INPUT policy of DROP, as was pointed-out by Simon_Bridge earlier... FWIW, i'd also ditch the whole RH-Firewall-1-INPUT chain thing, but that's just me...

x42bn6 · 03-26-2007, 09:10 PM

Alright. Just a quick addition: Could anyone tell me what:

Code:

TCP: Treason uncloaked! Peer 195.166.237.42:7081/80 shrinks window 1773266768:1773266769. Repaired.

means exactly? As in what is happening? Thanks.

win32sux · 03-26-2007, 09:18 PM

Quote:

Originally Posted by x42bn6

Alright. Just a quick addition: Could anyone tell me what:

Code:

TCP: Treason uncloaked! Peer 195.166.237.42:7081/80 shrinks window 1773266768:1773266769. Repaired.

means exactly? As in what is happening? Thanks.

what kernel version are you running??

Code:

uname -a

my guess is you've run into this bug: http://git.kernel.org/?p=linux/kerne...40cf9c07261dd2

Quote:

This bug is responsible for causing the infamous "Treason uncloaked"

messages that's been popping up everywhere since the printk was added.

It has usually been blamed on foreign operating systems. However,

some of those reports implicate Linux as both systems are running

Linux or the TCP connection is going across the loopback interface.

In fact, there really is a bug in the Linux TCP header prediction code

that's been there since at least 2.1.8. This bug was tracked down with

help from Dale Blount.

The effect of this bug ranges from harmless "Treason uncloaked"

messages to hung/aborted TCP connections. The details of the bug

and fix is as follows.

When snd_wnd is updated, we only update pred_flags if

tcp_fast_path_check succeeds. When it fails (for example,

when our rcvbuf is used up), we will leave pred_flags with

an out-of-date snd_wnd value.

When the out-of-date pred_flags happens to match the next incoming

packet we will again hit the fast path and use the current snd_wnd

which will be wrong.

In the case of the treason messages, it just happens that the snd_wnd

cached in pred_flags is zero while tp->snd_wnd is non-zero. Therefore

when a zero-window packet comes in we incorrectly conclude that the

window is non-zero.

In fact if the peer continues to send us zero-window pure ACKs we

will continue making the same mistake. It's only when the peer

transmits a zero-window packet with data attached that we get a

chance to snap out of it. This is what triggers the treason

message at the next retransmit timeout.

if this is indeed the case, then you should update/patch your kernel instead of using iptables to deal with this...

x42bn6 · 03-26-2007, 09:21 PM

Redhat, a slightly old version. Here is what I get via 404: Apache/2.0.54 (Fedora)

Linux <censored> 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:57:02 EDT 2006 i686 i686 i386 GNU/Linux

I hope you are aware that I have no idea what the hell that other link is about.

win32sux · 03-26-2007, 09:28 PM

Quote:

Originally Posted by x42bn6

Redhat, a slightly old version. Here is what I get via 404: Apache/2.0.54 (Fedora)

Linux <censored> 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:57:02 EDT 2006 i686 i686 i386 GNU/Linux

is there an updated kernel package available for your distro??

if so, this bug might be one of the issues it patches...