Re: DNS replies not RELATED/ESTABLISHED?
martin f krafft([EMAIL PROTECTED]) is reported to have said: > also sprach Blair L Strang <[EMAIL PROTECTED]> [2005.03.15.2256 +0100]: > > Sorry I didn't understand from your original post that this was > > only happening occasionally. Duh! > > It does only happen occassionally... > > > Perhaps look into ip_conntrack_max? > > I don't have such a file. ip_conntrack_expect is the only other > one... > grep -i conntrack /boot/config-2.6.[7-10] CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_MATCH_CONNTRACK=m Maybe you need to re-configure the kernel?? WT -- The reason computer chips are so small is computers don't eat much. ___ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS replies not RELATED/ESTABLISHED?
martin f krafft wrote: also sprach Blair L Strang <[EMAIL PROTECTED]> [2005.03.15.2256 +0100]: Sorry I didn't understand from your original post that this was only happening occasionally. Duh! It does only happen occassionally... Perhaps look into ip_conntrack_max? I don't have such a file. ip_conntrack_expect is the only other one... It /is/ a bit of a long shot because you probably would have noticed messages saying "ip_conntrack: maximum limit of entries exceeded" from your kernel. But worth a look anyway. ip_conntrack_max is a sysctl which determines how many conntrack entries are kept. See: /proc/sys/net/ipv4/ip_conntrack_max. Comparing this with "wc -l /proc/net/ip_conntrack" will tell you how close to the limit you are at a given point in time. The numbers can change pretty dramatically depending on use or abuse; a single nmap -sU -T Insane will chew through a lot of conntracks (1600 or so at peak when I tried it). Ta, Blair. -- M-x yow! Well, O.K. I'll compromise with my principles because of EXISTENTIAL DESPAIR! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS replies not RELATED/ESTABLISHED?
also sprach Blair L Strang <[EMAIL PROTECTED]> [2005.03.15.2256 +0100]: > Sorry I didn't understand from your original post that this was > only happening occasionally. Duh! It does only happen occassionally... > Perhaps look into ip_conntrack_max? I don't have such a file. ip_conntrack_expect is the only other one... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: DNS replies not RELATED/ESTABLISHED?
martin f krafft wrote: also sprach Blair Strang <[EMAIL PROTECTED]> [2005.03.15.1245 +0100]: I am guessing the problem is elsewhere. What does /proc/net/ip_conntrack say the kernel is expecting? The UDP "connection" is not listed. Someone else told me in private mail that DNS is special, but I do not see anything special about the following: 16:27:15.369276 217.233.52.92.62406 > 217.237.151.97.53: 21533+ A? debian.org. (28) (DF) 16:27:15.424481 217.237.151.97.53 > 217.233.52.92.62406: 21533 1/0/0 A 192.25.206.10 (44) The corresponding ip_contrack entry: udp 17 27 src=217.233.52.92 dst=217.237.151.97 sport=62406 dport=53 packets=1 bytes=67 src=217.237.151.97 dst=217.233.52.92 sport=53 dport=62406 packets=1 bytes=115 mark=0 use=1 This looks all good and fine. Whenever I get log entries generated by iptables, it seems that they are some sort of spurious responses by the servers, or else iptables would let them through. Of course right now there aren't any. However, I have seen this for years and always wondered... Sorry I didn't understand from your original post that this was only happening occasionally. Duh! Perhaps look into ip_conntrack_max? Conntrack stress can be triggered by an nmap scan, heavy worm traffic, low memory, very busy fw etc etc. Regards Blair. -- [WARNING: A meme virus was detected in this signature. It has been cleaned by MemeSweeper(tm) 4.0] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS replies not RELATED/ESTABLISHED?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 martin f krafft said: > also sprach Phil Dyer <[EMAIL PROTECTED]> [2005.03.15.1512 +0100]: >> for INPUT, lose the conntrack. >> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > > why? > Actually, good question. I thought that conntrack was for forwarding/natting only, but looking at the man page, it's not. It should be a superset of the -m state module. I do know that using the state module works for my setup. Have you tried it like above? Does it work? - -- /phil -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Public Key: http://www.dyermaker.org/gpgkey iD8DBQFCNxP6Gbd/rBLcaFwRAtE+AKDdmxGmbJ11jI8PVkuhX3hQQo+uKQCgxBvl VJEdhF8Q3hSMwMbB9IGVKUA= =MbOv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS replies not RELATED/ESTABLISHED?
also sprach Phil Dyer <[EMAIL PROTECTED]> [2005.03.15.1512 +0100]: > for INPUT, lose the conntrack. > -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT why? Also, please do not CC me on replies. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: DNS replies not RELATED/ESTABLISHED?
also sprach Blair Strang <[EMAIL PROTECTED]> [2005.03.15.1245 +0100]: > I am guessing the problem is elsewhere. What does > /proc/net/ip_conntrack say the kernel is expecting? The UDP "connection" is not listed. Someone else told me in private mail that DNS is special, but I do not see anything special about the following: 16:27:15.369276 217.233.52.92.62406 > 217.237.151.97.53: 21533+ A? debian.org. (28) (DF) 16:27:15.424481 217.237.151.97.53 > 217.233.52.92.62406: 21533 1/0/0 A 192.25.206.10 (44) The corresponding ip_contrack entry: udp 17 27 src=217.233.52.92 dst=217.237.151.97 sport=62406 dport=53 packets=1 bytes=67 src=217.237.151.97 dst=217.233.52.92 sport=53 dport=62406 packets=1 bytes=115 mark=0 use=1 This looks all good and fine. Whenever I get log entries generated by iptables, it seems that they are some sort of spurious responses by the servers, or else iptables would let them through. Of course right now there aren't any. However, I have seen this for years and always wondered... Maybe someone has a smart way to diagnose this? For now, I'll use -A INPUT -i ppp0 -p udp -m udp --sport 53 -j ULOG --ulog-prefix "[DNS in] " -A OUTPUT -o ppp0 -p udp -m udp --dport 53 -j ULOG --ulog-prefix "[DNS out] " -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i ppp0 -p udp -m udp --sport 53 -j ULOG --ulog-prefix "[spurious DNS] " Let's see what that brings... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: DNS replies not RELATED/ESTABLISHED?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 martin f krafft said: > > Here are the relevant rules: > > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT > -A INPUT -m conntrack --ctstate INVALID -j DROP > > -A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix > "[INPUT]: " > > -P INPUT DROP for INPUT, lose the conntrack. - -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT - -- /phil -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Public Key: http://www.dyermaker.org/gpgkey iD8DBQFCNu08Gbd/rBLcaFwRAji0AJ0cwYWcRPji9AFpsJzHr+Dr0OIAbwCeJGej RfAAkcC+CCg3lgOGKKHl7GA= =l8Ym -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS replies not RELATED/ESTABLISHED?
martin f krafft wrote: > I have a firewall which allows ESTABLISHED,RELATED packets on INPUT, > and port 53/udp on OUTPUT. Now, if I query for a DNS name, the > packet leaves the machine, but the reply is usually dropped: > > [INPUT]: IN=ppp0 OUT= MAC= SRC=217.232.161.91 DST=62.159.154.42 > LEN=68 TOS=0x00 PREC=0x00 TTL=58 ID=9949 PROTO=UDP SPT=53 > DPT=16468 LEN=48 > > Here are the relevant rules: > > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT > -A INPUT -m conntrack --ctstate INVALID -j DROP > > -A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[INPUT]: " > > -P INPUT DROP > > I always have to add specific udp sport rules for all nameservers, > which is a pain, and which should not be required. > As a quickie I applied this subset of the INPUT rules on my workstation and everything seemed to work as expected. I am guessing the problem is elsewhere. What does /proc/net/ip_conntrack say the kernel is expecting? Cheers, Blair -- How much SPAM would CAN-SPAM can if CAN-SPAM could can SPAM? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS replies not RELATED/ESTABLISHED?
I have a firewall which allows ESTABLISHED,RELATED packets on INPUT, and port 53/udp on OUTPUT. Now, if I query for a DNS name, the packet leaves the machine, but the reply is usually dropped: is it running a recursive dns server, or are you using $ISP's designated pair? [INPUT]: IN=ppp0 OUT= MAC= SRC=217.232.161.91 DST=62.159.154.42 LEN=68 TOS=0x00 PREC=0x00 TTL=58 ID=9949 PROTO=UDP SPT=53 DPT=16468 LEN=48 Here are the relevant rules: -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT I'm not entirely certain, but I believe I've read that ctstate only applies to NAT - I could be wrong though (and the documentation at location listed below doesn't make it completely clear). Anyhow - it looks like it `falls' through the first two rules, and gets pummeled by your LIMIT/LOG rule, and then a DROP into /dev/null, so - atleast something hints that connection tracking on udp has a few issues (not entirely unexpected on my behalf) -A INPUT -m conntrack --ctstate INVALID -j DROP Do you do SNAT/Masquerade outbound? (perhaps unlikely, but it's possible), if so, you might need to use -j SNAT|DNAT on --ctstate (http://www.netfilter.org/documentation/HOWTO//netfilter-extensions-HOWTO-3.html#ss3.3) -A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[INPUT]: " -P INPUT DROP I always have to add specific udp sport rules for all nameservers, which is a pain, and which should not be required. What am I doing wrong? (Note that I get the same results with '-m state' instead of '-m ctstate'). that's even stranger - I've made drop policy firewalls with recursive dnscache's with the box accepting only ssh from $LAN, and a few select external ip's for maintenance, with -m state --state ESTABLISHED,RELATED -j ACCEPT - without any problems. not much of a solution, but hopefully it raises a few questions that might make you go "h". hth. /Tommi -- Programmers love Unix and C because they are powerful, and they are powerful because programmers love them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
