iptables: block ports and RELATED, ESTABLISHED
 

Hi,

I have iptables 1.2.5 and the following problem.

I want to block some special ports, but I want to allow most RELATED and ESTABLISHED traffic.

I did:

...
$IPTABLES -t filter -A INPUT -p tcp -m multiport --dport 161,162,7100,8080,3128,1080,2049,4045,31337 -j DROP
$IPTABLES -t filter -A INPUT -p udp -m multiport --dport 161,162,7100,8080,3128,1080,2049,4045,31337 -j DROP

$IPTABLES -t filter -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT $IPTABLES -t filter -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
$IPTABLES -t filter -A INPUT -p tcp --dport 1024:65535 -m state --state RELATED -j ACCEPT
$IPTABLES -t filter -A INPUT -p udp --dport 1024:65535 -m state --state RELATED -j ACCEPT
$IPTABLES -t filter -A INPUT -m state --state INVALID -j DROP
...

Everything works fine, but my Snort reports some traffic on port 1080 and 8080 and some others from the above.
Why they don't closed? I tried reverse:

$IPTABLES -t filter -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT $IPTABLES -t filter -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
$IPTABLES -t filter -A INPUT -p tcp --dport 1024:65535 -m state --state RELATED -j ACCEPT
$IPTABLES -t filter -A INPUT -p udp --dport 1024:65535 -m state --state RELATED -j ACCEPT
$IPTABLES -t filter -A INPUT -m state --state INVALID -j DROP

$IPTABLES -t filter -A INPUT -p tcp -m multiport --dport 161,162,7100,8080,3128,1080,2049,4045,31337 -j DROP
$IPTABLES -t filter -A INPUT -p udp -m multiport --dport 161,162,7100,8080,3128,1080,2049,4045,31337 -j DROP


But no effect.
Maybe it's very easy to solve, I'm new with firewalling and iptables.

Thanks for help,
Greetings from Black Forrest, Germany,
Klaus

IMO the best way to learn it yourself, after reading the iptables tutorial (see 1st sticky thread in this forum, post #2 or ffwd to http://iptables-tutorial.frozentux.n...-tutorial.html), would be to add LOG target rules just before the target decision, something like

for dport in 161 162 1080 2049 3128 4045 31337 7100 8080; do
$IPTABLES -A INPUT -p tcp --syn -m state --state NEW --dport $dport -j LOG --log-prefix "SYN on port $dport"; done

before

$IPTABLES -t filter -A INPUT -p tcp -m multiport --dport 161,162,7100,8080,3128,1080,2049,4045,31337 -j DROP

That way you can see what goes on.
This example would trigger attempts setting up a new connection (TCP SYN flag set) to those destination ports.
Btw, post some of those Snort alerts if you can.

Thanks a lot, unSpawn.

I will try the logging thing, good idea.
The tutorial (the best one I know) i read very carefully. But I found no solution for that.

The problem occurs mostly on the ports 1080 and 8080 and I don't know the state of these connections. With the logging I will find it.

Before this here are two of the snort-logs:

[**] [1:620:3] SCAN Proxy (8080) attempt [**]
[Classification: Attempted Information Leak] [Priority: 2]
07/14-03:21:56.130771 38.112.199.137:5625 -> 217.160.95.177:8080
TCP TTL:112 TOS:0x0 ID:256 IpLen:20 DgmLen:40
******S* Seq: 0x28376839 Ack: 0x0 Win: 0x4000 TcpLen: 20

[**] [1:615:4] SCAN SOCKS Proxy attempt [**]
[Classification: Attempted Information Leak] [Priority: 2]
07/14-00:35:46.052020 209.164.40.234:3652 -> 217.160.95.177:1080
TCP TTL:113 TOS:0x0 ID:58795 IpLen:20 DgmLen:48 DF
******S* Seq: 0x7BFC0699 Ack: 0x0 Win: 0xFAF0 TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
[Xref => http://help.undernet.org/proxyscan/]


I will post the results from the logging.

Greetings,
Klaus Pforte

O.K. My mistake.

I found that Snort is sitting IN FRONT of iptables.
So he/she logs all what could be dangerous, but unfiltered from iptables.

Then I wrote filter rules, tested them with iptables-logs and now I'm happy. Nothing comes through.

O.K. nearly nothing.
I work on it.

Greetings,
Klaus

No, that ain't exactly true. In short Snort hooks in "below" the netfilter part, and so should always see each and every packet before it hits Netfilter. Leaves me kinda wondering what rules you wrote...

Why wondering?
Tell me, I want to learn and to know how to make them better.
I'm really new to iptables, read a really lot in the last weeks but my experiences are not so much.

Thanks again,
Klaus

Ah, well. I should have just asked you to post those Snort rules (if they are, if they're Iptables rules I've said nothing).