# Iptables bug!!! or ignorance?

## XenoTerraCide

how is it I can access all services when my rules look like this. I shouldn't be able to start any new connection. 

```
SLAVE-I ~ # iptables -L -v

Chain INPUT (policy DROP 45 packets, 15306 bytes)

 pkts bytes target     prot opt in     out     source               destination         

 1927  683K ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 

Chain FORWARD (policy DROP 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1946 packets, 218K bytes)

 pkts bytes target     prot opt in     out     source               destination         

```

 I can browse the web emerge chat on IM. anything... I have restarted the machine to make sure that I shouldn't have any connections. so everything should have a "NEW" state... but it all works why? I'm so confused.

----------

## adaptr

There are probably more rules than those; what is in your nat table ?

----------

## XenoTerraCide

```
SLAVE-I ~ # iptables -t nat -L -v

Chain PREROUTING (policy ACCEPT 1798K packets, 147M bytes)

 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 1024 packets, 66544 bytes)

 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 757K packets, 47M bytes)

 pkts bytes target     prot opt in     out     source               destination         

```

 the only thing that might be working right, right now is the blocking of net.lo.

----------

## XenoTerraCide

all I know is that if I get rid of the related,established rule I can't get out like it's supposed to. but with it on I can access everything without any other rules (except net.lo).

----------

## XenoTerraCide

further analysis shows that it is the established rule that is causing this. I am able to retain connections with just established. but lose them with just related. am I correct in my thinking that this shouldn't work? is it possible something is establishing an all port's protocols connection or something?

----------

## eagle_cz

well i would suggest to strict those rules to TCP protocol only.

Im just wondering, that Iptables accepted sutch rule.

those flags should be allowed for TCP only.

Since you can not match those flags in other but TCP traffic, its useless, wrong defined rule... im not wondering that iptables behave in odd way as well  :Smile: 

try to set TCP protocol and let us know if it has changed.

I would also suggest to check netstat output to make sure, that your "testing" connection is not open before you apply those rules.

Try to remove related, and post your results please.

----------

## XenoTerraCide

yeah putting it as tcp only works... but I do find it odd... perhaps that should have a syntax error if not used with a protocol. scary thing is I'm not sure I had a protocol specified in my old rules... good thing this isn't a production system   :Very Happy: 

----------

## XenoTerraCide

I must correct myself. that works like removing the rule works... or similar. I can't browse to say anywhere with it.

```
SLAVE-I ~ # iptables -L -v

Chain INPUT (policy DROP 9 packets, 1611 bytes)

 pkts bytes target     prot opt in     out     source               destination         

   15  2231 ACCEPT     tcp  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 

    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere            

    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere            tcp dpt:domain 

    0     0 ACCEPT     udp  --  eth0   any     anywhere             anywhere            udp dpt:domain 

    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere            tcp dpt:http 

    0     0 ACCEPT     udp  --  eth0   any     anywhere             anywhere            udp dpt:http 

```

 shouldn't I be able to browse to here with these rules? or am I missing something?

----------

## XenoTerraCide

seriously I don't get it... shouldn't I just require the opening of the ports? I've even told it to set their state to NEW. and that doesn't work... the only thing that I've seen work is accepting both udp and tcp ESTABLISHED packets... and then everything works. In fact I shouldn't even have to use states at all should I? shouldn't just opening the ports work?

----------

## pteppic

With the 'accept if input is from local' and 'related or established' rules, unless you are running any servers then that should be all you need. They will allow a connection out to a server, and when the info comes back it is under the 'related or established' and let in.I'm assuming this firewall is running on the pc you are trying to browse from?

If not you need to add the lan interface to the input chain as accept, and a masquerade rule for the output interface to the postrouting chain.

For your last question, the ports opened by the http and domain rules are for servers, they are not neccessarily the ports your software will try to use to get to the outside world.

----------

## XenoTerraCide

yes it is on the same computer... this is my router as well but I'm trying to solve this issue first. I could just drop the firewall entirely and get the same effects I'm getting with the established only rule... or I can take that out and just not be able to access anything. this may not be a production environment. but I'm going to treat it like it's a computer that could go production and this is not acceptable.

----------

## XenoTerraCide

I've tried doing this 

```
Chain INPUT (policy DROP 68 packets, 19402 bytes)

 pkts bytes target     prot opt in     out     source               destination         

    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere            

    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere            tcp dpt:domain state NEW,RELATED,ESTABLISHED 

    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere            tcp dpt:domain state NEW,RELATED,ESTABLISHED 

    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere            tcp dpt:http state NEW,RELATED,ESTABLISHED 

    0     0 ACCEPT     udp  --  eth0   any     anywhere             anywhere            udp dpt:http state NEW,RELATED,ESTABLISHED 

```

 as well to see if it would work... and it didn't.

----------

## pteppic

For your first respone:-

In that case take out the local accept rule, replace it with a

```
iptables -A INPUT -p tcp -i lo -m tcp --dport 80 -m state --state NEW -j ACCEPT
```

for each protocol/port you use. 

Be aware with the only the accept local and related/established rules the firewall is doing what it is supossed to do, block unauthiorised connection attempts from the outside world, it's a firewall, not a solution to opening emails full of trojans and malware.

For your second response:- no it wont work, there will be no inbound traffic on those ports and that is what you are trying to allow with those rules.

----------

## XenoTerraCide

what do you mean there would be no inbound traffic with those rules?

and your rule doesn't help.... if anything it causes more problems I have the accept lo rule because many application make a call to lo. I know amarok does and I couldn't view my own http server without it either.

why would there be no inbound traffic on those ports and why does it sound like your saying everything a lot of people have said is wrong? of course my results are saying that to... I'm curious if this is a new problem on my machine or an old one that I have not been aware of. probably old. 

oh and by people and sources I mean like netfilter, daniel robbins document on ibm developer works, you know the kind of things that shouldn't be trusted.

----------

## XenoTerraCide

and I'm aware its trying to block attempts to access the outside world. I'm trying to secure ports to the outside world while allowing others... that's the point here. I only seem to be able to allow them all or deny them all.

----------

## pteppic

Lets clear up some possible confusion, the established/related rule is to dynamically open ports to software that is allowed to connect to the outside world, and has done so already through an allowed channel, in the most simple case by and allow local rule( allow all outbound traffic from local interface).

There are normally two chains you need to be looking at FORWARD and INPUT, but in this case I'm not sure FORWARD is going to be of any use to you as technically your not forwarding any connections (I dont think lo to eth0 counts).

All the default policies are set to DROP, thats fine.

To allow lo-lo traffic

```
iptables -A INPUT -i lo  -j ACCEPT

iptables -A OUTPUT -o lo -j ACCEPT
```

this way amarok and whatever else calls local can get through, but you haven't allowed arbitary outbound access

Then, for example allow web browsing and ftp

```

iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o eth0  -p tcp -m tcp --dport 21 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o eth0  -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
```

The established/related(RE) rule here allows iptables to dynamically open ports to your web browser and ftp program, as it will have allready have a related connection to destination port 80/21 on the server.

To test these simple rules try to contact a known webserver that allows port 81 connections (common for bypassing local proxies), then an ftp server that connects in passsive mode after contact to test the RE rules properly.

EDIT: Doh, you default output policy is ACCEPT.

----------

## XenoTerraCide

I was testing by the fact of when I could and could not connect to web pages and whether or not my Instant messengers which don't use any ports I had open could connect. and have you tried what your rules look like when you run 

```
iptables -L -v
```

it's gonna look an awful lot like mine. I'd like to know if anyone has bothered to strip there rules down to 

```
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
```

and see if they can access everything like I can. also if you want to talk about specifying the protocol I tried that and if I do both tcp and udp with that rule it work too but I can't get anything to work without it. I can't figure out why I even need states.

```

IPT='/sbin/iptables'

# Flush all rules in all tables

$IPT -t filter -F

$IPT -t nat -F

# set chain Policies

$IPT -P INPUT DROP

$IPT -P OUTPUT ACCEPT

$IPT -P FORWARD DROP

#***********************************************************************#

# INPUT CHAIN                        #

#***********************************************************************#

# accept all related established

$IPT -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT

#$IPT -A INPUT -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT

# accept all on net.lo rule

#$IPT -A INPUT -i lo -j ACCEPT

# accept all new dns lookups

$IPT -A INPUT -i eth0 -p tcp --dport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPT -A INPUT -i eth0 -p tcp --dport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# accept port 80(http) inbound connection on eth0 for tcp

$IPT -A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPT -A INPUT -i eth0 -p udp --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
```

 that's my current script. It doesn't work. I can't figure out why... like I said I'm wondering if any of my firewalls were actually working or if this is a new problem. I'm smart enough now to know what's going on isn't right. I suppose I could alter the mac address on my laptop and plug in the firewall and see if it works. maybe something got screwed up on this machine. but if it did I don't know what it would be.

I haven't altered the comment's on that script since I altered the code.

----------

## pteppic

Right, I have a problem with drop as the default policy, but this does work on the pc I'm typing from.

```
# Generated by iptables-save v1.2.11 on Wed Feb 22 06:17:09 2006

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [2:168]

-A INPUT -i lo -j ACCEPT

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-port-unreachable

-A OUTPUT -o lo -j ACCEPT

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -o eth0 -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT

-A OUTPUT -o eth0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT

-A OUTPUT -j REJECT --reject-with icmp-port-unreachable

COMMIT

# Completed on Wed Feb 22 06:17:09 2006

```

It give this pc the abilty to use the web and nothing else, no port 81 http requests, nothing.

EDIT: I had to enable udp on port 80 to be able to submit the post.

You need to accpet all from local to get lo to lo allowed through, so use the output chain to block lo to etho outbound traffic

You could also use 

```
iptables -I INPUT -i lo -d 127.0.0.0 -j ACCEPT
```

 to allow local to local access with OUTPUT defaulted to ACCEPT I think.Last edited by pteppic on Wed Feb 22, 2006 6:28 am; edited 1 time in total

----------

## XenoTerraCide

oh? so you have a problem with drop as the default policy? I have been messing with the reject thing. still that's why I'm wondering if there is a bug because this doesn't work as it should. I may update iptables and try... I also notice I may have had some conflicting iptables modules and I corrected it...

----------

## XenoTerraCide

if this fails I will poke around at netfilter... see if I can find an answer because i doubt this is a gentoo problem. it may be though.

----------

## XenoTerraCide

failed... I'm gonna go poke around netfilter... see if I can find my answer.

----------

## pteppic

 *XenoTerraCide wrote:*   

> if this fails I will poke around at netfilter... snip.

 

Stange you should say that, thier 'quick start guide' used the policies defaulted to accpet, with a drop at the end of the filter chain.

To be honest it's the only way I've ever done it, because drop is replaced with a custom chain that logs certain packets here, then drops it.

----------

## XenoTerraCide

most quick start's guides do it that way... but this way should work... I found this problem when I was re-writing my firewall after I had some routing problem... I was using this tutorial http://www-128.ibm.com/developerworks/edu/l-dw-linuxfw-i.html then I noticed my Instant messenger was working... It shouldn't have been because I no longer had those ports open.

EDIT: and I tried adding a drop at the end... didn't work. still had all access.

----------

## pteppic

Is your output chain still set to accept?Does it have Rules?

----------

## XenoTerraCide

still accept still no rules. if your thinking of my routing problem that may have been windows it needs to be reinstalled. it has an important file missing. teach me to shut it down once it has begun loading.  :Evil or Very Mad:  right now I have the firewall stopped... so I can browse around...because the rules don't seem to work anyway.

----------

## pteppic

Try this whole file with iptables-restore /path/to /saved/file

```
# Generated by iptables-save v1.2.11 on Wed Feb 22 06:56:01 2006

*raw

:PREROUTING ACCEPT [5419:2576241]

:OUTPUT ACCEPT [4192:558778]

COMMIT

# Completed on Wed Feb 22 06:56:01 2006

# Generated by iptables-save v1.2.11 on Wed Feb 22 06:56:01 2006

*nat

:PREROUTING ACCEPT [1178:40052]

:POSTROUTING ACCEPT [96:6120]

:OUTPUT ACCEPT [598:44015]

COMMIT

# Completed on Wed Feb 22 06:56:01 2006

# Generated by iptables-save v1.2.11 on Wed Feb 22 06:56:01 2006

*mangle

:PREROUTING ACCEPT [5419:2576241]

:INPUT ACCEPT [5419:2576241]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [4192:558778]

:POSTROUTING ACCEPT [3672:519833]

COMMIT

# Completed on Wed Feb 22 06:56:01 2006

# Generated by iptables-save v1.2.11 on Wed Feb 22 06:56:01 2006

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [2:168]

-A INPUT -i lo -j ACCEPT

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-port-unreachable

-A OUTPUT -o lo -j ACCEPT

-A OUTPUT -p udp -m udp --dport 80 -m state --state NEW -j ACCEPT

-A OUTPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT

-A OUTPUT -j REJECT --reject-with icmp-port-unreachable

COMMIT

# Completed on Wed Feb 22 06:56:01 2006

```

----------

## XenoTerraCide

interesting.... it works... what's even more insteresting is it works as expected if I change my policy on input to drop, from yours which is accept. now what did you do differently? that I never tried. I did have a reject rule in mine the first time...

----------

## XenoTerraCide

the only thing I see that is different is you output rules... odd why would that impact so much... I may still query with netfilter... but this seems to work. although I have to open the instant messenger ports... does this mean I have to open them on output instead of input? hmm... thx for the help.

----------

## XenoTerraCide

I get it... makes perfect sense now... I've had an epiphany. took all day and none of these tutorial's I've read would have made this click because they all seem content to ignore the output chain.

----------

## XenoTerraCide

btw your rules seem to work with all filter chains set to drop. of course if I'm routing I'll have to create some accept rules for forward but other than that they seem to work. thanks again.

----------

## XenoTerraCide

one last question pteppic. you don't have an rsync rule? don't you update your system? or do you drop the firewall when updating? if it works for you then I think your firewall may not because you don't have the drop policies or a catch all drop rule your reject rules are for icmp packets. but I dunno, just asking because I'll have to add one because I have portage updating nightly via cron.

----------

## pteppic

That setup was done quickly on a laptop on the lan, already behind the main firewall, needless to say that it is a little more complicated   :Wink: 

Normally when setting up for routing you are just attempting to block incoming from outside to unwanted ports, and this seems to be what most of the tutorials cover.

It's because you need to allow all from local to local that blocking incoming from local is not an option, meaning you have to block outgoing instead. That said it should be possible to specify a destination network/address on you local input allow rule (-d 127.0.0.0), leaving you free to set all output rules to accept as in the tutorials and create rules to allow specific destination ports. This helps because you can create a custom chain to use in both input and forward to save duplicating rules for the forwarded packets. 

At then end of the day the linux kernel packet filter is a highly configurable piece of kit, and you have to decide how *you* are going to do it or you'll spend days going round in circles.

----------

## XenoTerraCide

do you know what I have to enable to get the mport module to work. I get this error

```
iptables v1.3.5: Couldn't load match `mport':/lib/iptables/libipt_mport.so: cannot open shared object file: No such file or directory
```

EDIT: and another interesting thing seems for all the features of gmail to work they need port 80 on input open.

----------

## pteppic

mport is depreciated, use -m multiport --dports

----------

## XenoTerraCide

according to the man page using mport --ports both the source and destination port have to match one of the listed ports. where using multiports --ports either the source or the destination have to match. mport != multiport am I reading this wrong?

----------

## pteppic

 *XenoTerraCide wrote:*   

> according to the man page using mport --ports both the source and destination port have to match one of the listed ports. where using multiports --ports either the source or the destination have to match. mport != multiport am I reading this wrong?

 

You can use multiport in the same way by using it twice -m multiport --dports 80,81 -m multiport --sports 80,81.

IIRC I saw documentation stating the change from mport to multiport some time ago, I prefer to specify rules one at a time in custom chains, so it didn't interest me that much.

EDIT: I think you read it wrong *Quote:*   

> --port [port[,port]]
> 
>     Match if the both the source and destination ports are equal to each other and to one of the given ports.

 Last edited by pteppic on Wed Feb 22, 2006 9:59 pm; edited 1 time in total

----------

## XenoTerraCide

how does that work if you only want to allow it when sport=dport ? which is what i'm trying to do.

----------

