Help writing a iptables rule

Concepts:

278012 Jul 23 2002 Security-Quickstart-HOWTO 287057 Jul 23 2002 Security-Quickstart-Redhat-HOWTO

a search engine should find those if you don't have them installed on your system in /usr/share/HOWTO/. Then go to

[TXT] NAT-HOWTO.txt 25-Sep-2008 07:04 25K [TXT] netfilter-double-nat-HOWTO.txt 25-Sep-2008 07:04 9.4K [TXT] netfilter-extensions-HOWTO.txt 25-Sep-2008 07:04 79K [TXT] netfilter-hacking-HOWTO.txt 25-Sep-2008 07:04 84K [TXT] netfilter-mirror-HOWTO.txt 25-Sep-2008 07:04 8.1K [TXT] networking-concepts-HOWTO.txt 25-Sep-2008 07:04 28K [TXT] packet-filtering-HOWTO.txt 25-Sep-2008 07:04 52K [DIR] pt/ 25-Sep-2008 07:04 -

That is one packet where the source web server is shutting down the connection ('WINDOW=0' and 'RST') for an unknown reason. You would have to look at the packets that occurred before this.

Start with the networking-concepts-HOWTO and then the packet-filtering-HOWTO from the netfilter.org site (you may want to look in

to see if these documents are available in translation). For further help, you will find a lot more readers in the Usenet newsgroup comp.os.linux.networking that can help, but you will need to post something about the packets that occurred before this one - this is merely the server saying "good bye".

Old guy

Moe Trin escreveu:

No, thank you. I don't want and don't have time to learn this stuff. I just want to give my pc a little more protection. That's why I am using guarddog. ...

Thank you. This happens with almost all connections (http at least). Somehow guarddog misses to allow these packets to pass! So I thought it should be a trivial task for those fluent in these concepts, perhaps one who knows guarddog, to write a rule or a couple of them to fix this. This is the reason for my help request.

Thanks anyway.

You really should look at the concepts, so that you can understand what protection you have to start with, what you may need, and what guarddog is doing.

You've got it doing something unusual - but what you show being blocked doesn't provide the clue needed. You have it blocking the termination of a connection, and not blocking the connection itself. This is not the normal behavior of any firewall. You added some rule to block some things without knowing what those things are, perhaps some specific TCP or IP flags.

It seems no one here knows guarddog, which is why I suggested using a different news group. You really do need to have some understanding of what a firewall does before you can configure one - even using a helper program like guarddog.

[compton ~]$ sudo /bin/netstat -anptu Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1621/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1423/cupsd tcp 0 0 :::22 :::* LISTEN 1621/sshd tcp 0 0 ::1:631 :::* LISTEN 1423/cupsd [compton ~]$

Here for example, the only services _running_ on this computer are SSH and a printer daemon - both listening on IPv4 and IPv6. But the printer daemon is only listening on the loopback (127.0.0.1 and ::1, so no bad guy can reach it. I've added a firewall rule to restrict access to the SSH port, only allowing connections from specific IPv4 addresses. There are no other firewall rules, because none are needed - there is nothing listening that _needs_ protection.

You showed a packet destined for an RFC1918 address (192.168.1.yy), which means you have to have something - most likely a cable modem - translating Internet addresses to RFC1918. Unless that modem is forwarding all traffic to a specific computer on your 192.168.1.yy network (highly unlikely), then the bad guys outside can't get in unless you invite them by making a connection to their site - not the other way around.

Old guy

Moe Trin escreveu:

I understand the very basics of a network and how a firewall "works". I don't know how to write iptables rules. I tried at first to write my own rulesets but ended up with lots of things not working. It's also natural that those rules didn't full protect things as I expected. So I gave up and went to guarddog. It was very very simple to use. Of course I can not evaluate the quality of the rules produced. I just trust them.

I don't think so. From what you wrote, I think guarddog is blocking (aborting) termination packets. Except for the logs and perhaps another problem (see below) everything works fine.

What caused me a problem was that sometimes firefox freezes for a few variable number of seconds. I looked at the logs and thought that may be some pluging could be expecting (waiting) for these packets.

So, I would like to get a rule to allow *only* these termination packets to pass. ...

but at least someone could know how to specify a rule that allowed only packets with those flags that appear in the rejection logs as aborted to pass. Then I could adapt the rule(s) to include IP addresses, etc...

Thank You

'guarddog' is one of many helpers that tries to create firewall rules for the kernel. You can actually use '/sbin/iptables -L' to view those rules. Most firewall setups are over-written and not well planned.

You would have to see the packet before this - the one that caused the server to send this rejection. A "RST" packet occurs when you try to send something to a system that doesn't want to talk to you (perhaps they are firewalling you)[1], _OR_ when you try to send a packet where there isn't a connection (perhaps there was an earlier timeout - perhaps this is a different host with a dynamic IP address or perhaps the server application failed). The server doesn't want to talk. Your firewall would probably also drop _this_ packet if it wasn't expecting it, because it had closed the connection earlier or never had opened one.

No - this is a network level packet. The application never would see it. If the application tried to get something from some host and that host has a firewall that blocks such access, the remote host may send a "WINDOW=0"/"RST" packet, and the kernel would tell the application that the connection could not be established. For this to be a problem with your application, you would have to have a special firewall rule blocking such packets[2] as this is not the default situation. The other case where this would occur is if your kernel thought it had a connection to something on the server, and the server actually did not have the connection - often a timeout, but it could also be a situation where the server failed or it had a dynamic address (and disappeared, and some OTHER computer got turned on and got the same IP address).

Sounds like a very bad idea, but it's probably something like

ACCEPT tcp -- Source_Addr Dest_Addr tcp --tcp-flags: ACK,RST

I do NOT recommend this.

I think you are trying to fix the symptom of the problem, rather than fixing the problem itself. This packet is never seen by your browser even if you did not have a firewall, and has nothing to do with the way the browser operates. This isn't the cause of your browser problem. There could be something else happening, but this is not it.

Old guy

[1] If the 'SEQ' field was not zero or missing, this is not likely to be the case. [2] Does the command '/sbin/iptables -L | grep RST' show any rule with the 'RST' argument to the '--tcp-flags:' option? That's probably wrong if one exists.

Moe Trin escreveu:

...

guarddog produces a bash script. So, I can see the rules there. ...

...

OK, thanks for the explanation. So, the only problem that remains is the logs and this is not important.

Yes! I think --tcp-flags is what I was looking for.

Anyway, I have just seen that Gentoo, the distro I use, is dropping guarddog because it depends on kdelibs-3. Besides, guarddog seems to have been abandoned. So, I have to change to another firewall gui. May be fwbuilder. It seems a lot more complicated but I didn't find any other. In the meanwhile I'll take a look at the bash script generated by guarddog and try to understand what is happening. May be I can keep going with this script alone if I can full understand it.

Thank you very much.