Help writing a iptables rule
in [Firewalls]
|
Prev: SPAM
Next: Personal Security virus removal
From: Moe Trin on 27 Dec 2009 16:01 On Sun, 27 Dec 2009, in the Usenet newsgroup comp.security.firewalls, in article <4b36bd32$0$7565$a729d347(a)news.telepac.pt>, Paulo da Silva wrote: >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. '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. >>> Thank you. This happens with almost all connections (http at least). >>> Somehow guarddog misses to allow these packets to pass! >> You've got it doing something unusual >I don't think so. From what you wrote, I think guarddog is blocking >(aborting) termination packets. 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. >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. 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). >So, I would like to get a rule to allow *only* these termination >packets to pass. 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. >> It seems no one here knows guarddog, >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. 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.
From: Paulo da Silva on 27 Dec 2009 20:27
Moe Trin escreveu: > On Sun, 27 Dec 2009, in the Usenet newsgroup comp.security.firewalls, in article > <4b36bd32$0$7565$a729d347(a)news.telepac.pt>, Paulo da Silva wrote: > .... > > '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. guarddog produces a bash script. So, I can see the rules there. .... > .... > >> 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. > > 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). OK, thanks for the explanation. So, the only problem that remains is the logs and this is not important. > >> So, I would like to get a rule to allow *only* these termination >> packets to pass. > > Sounds like a very bad idea, but it's probably something like > > ACCEPT tcp -- Source_Addr Dest_Addr tcp --tcp-flags: ACK,RST 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. |