Help writing a iptables rule
in [Firewalls]
|
Prev: SPAM
Next: Personal Security virus removal
From: Paulo da Silva on 23 Dec 2009 19:09 Hi! I don't know how to write iptables rules. I have a set of them produced by guarddog. However they are aborting packages like this one: ABORTED IN=wlan0 OUT= MAC=... SRC=xx.xx.xx.xx DST=192.168.1.yy LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=7099 DF PROTO=TCP SPT=80 DPT=5194 SEQ=SSSSSSSS ACK=AAAAAAAA WINDOW=0 RES=0x00 ACK RST URGP=0 Does anyone pls. write one or more rules to allow these packages and only these? Where do I place them? Thank you very much
From: Moe Trin on 24 Dec 2009 11:38 On Thu, 24 Dec 2009, in the Usenet newsgroup comp.security.firewalls, in article <4b32b11d$0$28317$a729d347(a)news.telepac.pt>, Paulo da Silva wrote: >I don't know how to write iptables rules. I have a set of them produced >by guarddog. However they are aborting packages like this one: 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 http://www.netfilter.org/documentation/HOWTO/ [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 - >ABORTED IN=wlan0 OUT= MAC=... SRC=xx.xx.xx.xx DST=192.168.1.yy LEN=40 >TOS=0x00 PREC=0x00 TTL=122 ID=7099 DF PROTO=TCP SPT=80 DPT=5194 >SEQ=SSSSSSSS ACK=AAAAAAAA WINDOW=0 RES=0x00 ACK RST URGP=0 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. >Does anyone pls. write one or more rules to allow these packages and >only these? >Where do I place them? Start with the networking-concepts-HOWTO and then the packet-filtering-HOWTO from the netfilter.org site (you may want to look in http://www.netfilter.org/documentation/HOWTO/pt/ 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
From: Paulo da Silva on 25 Dec 2009 12:12 Moe Trin escreveu: > On Thu, 24 Dec 2009, in the Usenet newsgroup comp.security.firewalls, in article > <4b32b11d$0$28317$a729d347(a)news.telepac.pt>, Paulo da Silva wrote: > >> I don't know how to write iptables rules. I have a set of them produced >> by guarddog. However they are aborting packages like this one: > > 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 > 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. .... > >> ABORTED IN=wlan0 OUT= MAC=... SRC=xx.xx.xx.xx DST=192.168.1.yy LEN=40 >> TOS=0x00 PREC=0x00 TTL=122 ID=7099 DF PROTO=TCP SPT=80 DPT=5194 >> SEQ=SSSSSSSS ACK=AAAAAAAA WINDOW=0 RES=0x00 ACK RST URGP=0 > > 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. > 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.
From: Moe Trin on 26 Dec 2009 14:08 On Fri, 25 Dec 2009, in the Usenet newsgroup comp.security.firewalls, in article <4b34f282$0$7515$a729d347(a)news.telepac.pt>, Paulo da Silva wrote: >Moe Trin escreveu: >> 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 >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. 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. >> 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. >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 - 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. >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. 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
From: Paulo da Silva on 26 Dec 2009 20:49
Moe Trin escreveu: > On Fri, 25 Dec 2009, in the Usenet newsgroup comp.security.firewalls, in article > <4b34f282$0$7515$a729d347(a)news.telepac.pt>, Paulo da Silva wrote: > >> Moe Trin escreveu: > >>> Concepts: >... > > 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. 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. > >>> 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. > >> 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. 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. .... > >> 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. > > 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. Then I could adapt the rule(s) to include IP addresses, etc... Thank You |