Date: Thu, 03 Apr 2008 17:20:07 -0700 From: Julian Elischer <julian@elischer.org> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Trouble with IPFW or TCP? Message-ID: <47F57437.6040400@elischer.org> In-Reply-To: <ft3phn$ai3$1@ger.gmane.org> References: <ft3phn$ai3$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ivan Voras wrote: > In which case would an ipfw ruleset like this: > > 00100 114872026 40487887607 allow ip from any to any via lo0 > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00600 1585 112576 deny ip from table(0) to me ipfw add 700 check-state > 01000 90279 7325972 allow icmp from any to any > 05000 475961039 334422494257 allow tcp from me to any setup keep-state > 05100 634155 65779377 allow udp from me to any keep-state > 06022 409604 69177326 allow tcp from any to me dst-port 22 setup > keep-state > 06080 52159025 43182548092 allow tcp from any to me dst-port 80 setup > keep-state > 06443 6392366 2043532158 allow tcp from any to me dst-port 443 setup > keep-state > 07020 517065 292377553 allow tcp from any to me dst-port 8080 > setup keep-state > 65400 12273387 629703212 deny log ip from any to any > 65535 0 0 deny ip from any to any lots of keep-state rules but nothing to check the state > > Generate syslog messages like these: > > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:60725 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:57387 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:57387 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:61998 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:61998 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:64288 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:64288 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:50212 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:50212 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:58149 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:58149 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:61919 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:61919 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:56792 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:13 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:56792 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:14 my.ip kernel: ipfw: 65400 Deny TCP yy.yy.yy.yy:53795 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58314 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63204 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58314 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:52125 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53386 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63626 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63204 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:51376 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:61880 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:49319 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:52125 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:62381 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53386 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:63626 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:51376 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:54109 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56945 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:61880 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:50800 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:49319 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53347 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58735 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58732 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:62381 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56837 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:54109 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:65318 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56945 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:50800 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:53347 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58735 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:58732 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:56837 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:16 my.ip kernel: ipfw: 65400 Deny TCP zz.zz.zz.zz:65318 > my.ip.my.ip:443 in via em0 > > ? > > I can connect with plain telnet from the reported addresses without > problems. One thing that is suspicious is that the messages come in > these bursts (which I can't explain) but the Apache's listen backlog > should handle those. In any case, I don't think they are connection > requests: > > Here's output of "tcpdump -v host xx.xx.xx.xx and port 443": > > 01:13:07.654677 IP (tos 0x0, ttl 58, id 54089, offset 0, flags [none], > proto TCP (6), length 40) xx.xx.xx.xx.58789 > my.ip.my.ip.https: ., > cksum 0x54ca (correct), ack 3708282724 win 0 > 01:13:07.654764 IP (tos 0x0, ttl 58, id 54095, offset 0, flags [none], > proto TCP (6), length 40) xx.xx.xx.xx.61579 > my.ip.my.ip.https: ., > cksum 0xf60d (correct), ack 610863831 win 0 > 01:13:07.654810 IP (tos 0x0, ttl 58, id 54099, offset 0, flags [none], > proto TCP (6), length 40) xx.xx.xx.xx.61852 > my.ip.my.ip.https: ., > cksum 0xab18 (correct), ack 1491048554 win 0 > 01:13:07.654854 IP (tos 0x0, ttl 58, id 54103, offset 0, flags [none], > proto TCP (6), length 40) xx.xx.xx.xx.63950 > my.ip.my.ip.https: ., > cksum 0x1e51 (correct), ack 2955921131 win 0 > 01:13:07.654897 IP (tos 0x0, ttl 58, id 54107, offset 0, flags [none], > proto TCP (6), length 40) xx.xx.xx.xx.53299 > my.ip.my.ip.https: ., > cksum 0xa141 (correct), ack 2339864417 win 0 > 01:13:07.654940 IP (tos 0x0, ttl 58, id 54121, offset 0, flags [none], > proto TCP (6), length 40) xx.xx.xx.xx.50521 > my.ip.my.ip.https: ., > cksum 0x2c55 (correct), ack 216576745 win 0 > 01:13:07.654984 IP (tos 0x0, ttl 58, id 54123, offset 0, flags [DF], > proto TCP (6), length 52) xx.xx.xx.xx.58789 > my.ip.my.ip.https: ., > cksum 0x882d (correct), ack 1 win 33304 <nop,nop,timestamp 140692997 > 4077078528> > 01:13:07.655026 IP (tos 0x0, ttl 58, id 54126, offset 0, flags [DF], > proto TCP (6), length 52) xx.xx.xx.xx.61579 > my.ip.my.ip.https: ., > cksum 0x0617 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997 > 3172245833> > 01:13:07.655069 IP (tos 0x0, ttl 58, id 54128, offset 0, flags [DF], > proto TCP (6), length 52) xx.xx.xx.xx.61852 > my.ip.my.ip.https: ., > cksum 0x7006 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997 > 3472415360> > 01:13:07.655112 IP (tos 0x0, ttl 58, id 54130, offset 0, flags [DF], > proto TCP (6), length 52) xx.xx.xx.xx.63950 > my.ip.my.ip.https: ., > cksum 0x7ade (correct), ack 1 win 33304 <nop,nop,timestamp 140692997 > 415365400> > 01:13:07.655155 IP (tos 0x0, ttl 58, id 54132, offset 0, flags [DF], > proto TCP (6), length 52) xx.xx.xx.xx.53299 > my.ip.my.ip.https: ., > cksum 0x4087 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997 > 2999393370> > 01:13:07.655197 IP (tos 0x0, ttl 58, id 54139, offset 0, flags [DF], > proto TCP (6), length 52) xx.xx.xx.xx.50521 > my.ip.my.ip.https: ., > cksum 0x13e0 (correct), ack 1 win 33304 <nop,nop,timestamp 140692997 > 3427580559> > > There are no SYNs here, so it looks to me like something mid-traffic. > > For addresses such as those in the ipfw log, I see several messages like: > > Mar 24 17:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:64714 to > [my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: > Received 198 bytes of data after socket was closed, sending RST and > removing tcpcb > Mar 24 17:10:57 my.ip kernel: 6110>ipfw: 65400 Deny TCP > xx.xx.xx.xx:58213 my.ip.my.ip:443 in via em0 > Mar 25 00:00:05 my.ip kernel: TCP: [xx.xx.xx.xx]:52233 to > [my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed > SYNCOOKIE authentication, segment rejected (probably spoofed) > Mar 25 01:45:05 my.ip kernel: TCP: [xx.xx.xx.xx]:51120 to > [my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed > SYNCOOKIE authentication, segment rejected (probably spoofed) > Mar 25 01:45:05 my.ip kernel: TCP: [xx.xx.xx.xx]:51120 to > [my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed > SYNCOOKIE authentication, segment rejected (probably spoofed) > Mar 25 14:00:09 my.ip kernel: TCP: [xx.xx.xx.xx]:55665 to > [my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed > SYNCOOKIE authentication, segment rejected (probably spoofed) > Mar 25 14:00:09 my.ip kernel: TCP: [xx.xx.xx.xx]:55665 to > [my.ip.my.ip]:443 tcpflags 0x10<ACK>; syncache_expand: Segment failed > SYNCOOKIE authentication, segment rejected (probably spoofed) > Mar 25 17:00:00 my.ip kernel: TCP: [xx.xx.xx.xx]:60048 to > [my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: > Received 346 bytes of data after socket was closed, sending RST and > removing tcpcb > Mar 25 17:00:00 my.ip kernel: TCP: [xx.xx.xx.xx]:60048 to > [my.ip.my.ip]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment > failed SYNCOOKIE authentication, segment rejected (probably spoofed) > Mar 25 23:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:50205 to > [my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: > Received 346 bytes of data after socket was closed, sending RST and > removing tcpcb > Mar 25 23:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:50205 to > [my.ip.my.ip]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment > failed SYNCOOKIE authentication, segment rejected (probably spoofed) > Mar 26 00:38:49 my.ip kernel: <a10>ipfw: 65400 Deny TCP > xx.xx.xx.xx:61129 my.ip.my.ip:443 in via em0 > Apr 2 09:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:57248 to > [my.ip.my.ip]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: > Received 330 bytes of data after socket was closed, sending RST and > removing tcpcb > Apr 2 09:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:57248 to > [my.ip.my.ip]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment > failed SYNCOOKIE authentication, segment rejected (probably spoofed) > > But these messages do *not* occur when the ipfw log and tcpdump record > the above described behaviour so it might not be connected. > > The machine at my.ip is running 7.0-RELEASE i386, the rest are a set of > machines that send trivial periodic (every 15 minutes) HTTPS messages to > this machine. > > In this set most are 6.2 or 6.3, mixed i386 and amd64. The one 7-STABLE > machine that does the same thing doesn't generate the behaviour > described above so it might be something specific to when 6.x machines > talk to 7.x. Was there a bug like that in 6.x? > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47F57437.6040400>