From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 23:34:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94A56106566C for ; Thu, 3 Apr 2008 23:34:36 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id ECDB18FC13 for ; Thu, 3 Apr 2008 23:34:35 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JhYwt-0001AG-17 for freebsd-net@freebsd.org; Thu, 03 Apr 2008 23:34:27 +0000 Received: from 78-0-69-170.adsl.net.t-com.hr ([78.0.69.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Apr 2008 23:34:27 +0000 Received: from ivoras by 78-0-69-170.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Apr 2008 23:34:27 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 04 Apr 2008 01:34:07 +0200 Lines: 262 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1FB290221A96A9CD76AF169F" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-69-170.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) X-Enigmail-Version: 0.95.6 Sender: news Subject: Trouble with IPFW or TCP? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2008 23:34:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1FB290221A96A9CD76AF169F Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 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=20 keep-state 06080 52159025 43182548092 allow tcp from any to me dst-port 80 setup=20 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=20 setup keep-state 65400 12273387 629703212 deny log ip from any to any 65535 0 0 deny ip from any to any Generate syslog messages like these: Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:60725=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 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=20 my.ip.my.ip:443 in via em0 ? I can connect with plain telnet from the reported addresses without=20 problems. One thing that is suspicious is that the messages come in=20 these bursts (which I can't explain) but the Apache's listen backlog=20 should handle those. In any case, I don't think they are connection=20 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],=20 proto TCP (6), length 40) xx.xx.xx.xx.58789 > my.ip.my.ip.https: .,=20 cksum 0x54ca (correct), ack 3708282724 win 0 01:13:07.654764 IP (tos 0x0, ttl 58, id 54095, offset 0, flags [none],=20 proto TCP (6), length 40) xx.xx.xx.xx.61579 > my.ip.my.ip.https: .,=20 cksum 0xf60d (correct), ack 610863831 win 0 01:13:07.654810 IP (tos 0x0, ttl 58, id 54099, offset 0, flags [none],=20 proto TCP (6), length 40) xx.xx.xx.xx.61852 > my.ip.my.ip.https: .,=20 cksum 0xab18 (correct), ack 1491048554 win 0 01:13:07.654854 IP (tos 0x0, ttl 58, id 54103, offset 0, flags [none],=20 proto TCP (6), length 40) xx.xx.xx.xx.63950 > my.ip.my.ip.https: .,=20 cksum 0x1e51 (correct), ack 2955921131 win 0 01:13:07.654897 IP (tos 0x0, ttl 58, id 54107, offset 0, flags [none],=20 proto TCP (6), length 40) xx.xx.xx.xx.53299 > my.ip.my.ip.https: .,=20 cksum 0xa141 (correct), ack 2339864417 win 0 01:13:07.654940 IP (tos 0x0, ttl 58, id 54121, offset 0, flags [none],=20 proto TCP (6), length 40) xx.xx.xx.xx.50521 > my.ip.my.ip.https: .,=20 cksum 0x2c55 (correct), ack 216576745 win 0 01:13:07.654984 IP (tos 0x0, ttl 58, id 54123, offset 0, flags [DF],=20 proto TCP (6), length 52) xx.xx.xx.xx.58789 > my.ip.my.ip.https: .,=20 cksum 0x882d (correct), ack 1 win 33304 01:13:07.655026 IP (tos 0x0, ttl 58, id 54126, offset 0, flags [DF],=20 proto TCP (6), length 52) xx.xx.xx.xx.61579 > my.ip.my.ip.https: .,=20 cksum 0x0617 (correct), ack 1 win 33304 01:13:07.655069 IP (tos 0x0, ttl 58, id 54128, offset 0, flags [DF],=20 proto TCP (6), length 52) xx.xx.xx.xx.61852 > my.ip.my.ip.https: .,=20 cksum 0x7006 (correct), ack 1 win 33304 01:13:07.655112 IP (tos 0x0, ttl 58, id 54130, offset 0, flags [DF],=20 proto TCP (6), length 52) xx.xx.xx.xx.63950 > my.ip.my.ip.https: .,=20 cksum 0x7ade (correct), ack 1 win 33304 01:13:07.655155 IP (tos 0x0, ttl 58, id 54132, offset 0, flags [DF],=20 proto TCP (6), length 52) xx.xx.xx.xx.53299 > my.ip.my.ip.https: .,=20 cksum 0x4087 (correct), ack 1 win 33304 01:13:07.655197 IP (tos 0x0, ttl 58, id 54139, offset 0, flags [DF],=20 proto TCP (6), length 52) xx.xx.xx.xx.50521 > my.ip.my.ip.https: .,=20 cksum 0x13e0 (correct), ack 1 win 33304 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=20 [my.ip.my.ip]:443 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2:=20 Received 198 bytes of data after socket was closed, sending RST and=20 removing tcpcb Mar 24 17:10:57 my.ip kernel: 6110>ipfw: 65400 Deny TCP=20 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=20 [my.ip.my.ip]:443 tcpflags 0x10; syncache_expand: Segment failed=20 SYNCOOKIE authentication, segment rejected (probably spoofed) Mar 25 01:45:05 my.ip kernel: TCP: [xx.xx.xx.xx]:51120 to=20 [my.ip.my.ip]:443 tcpflags 0x10; syncache_expand: Segment failed=20 SYNCOOKIE authentication, segment rejected (probably spoofed) Mar 25 01:45:05 my.ip kernel: TCP: [xx.xx.xx.xx]:51120 to=20 [my.ip.my.ip]:443 tcpflags 0x10; syncache_expand: Segment failed=20 SYNCOOKIE authentication, segment rejected (probably spoofed) Mar 25 14:00:09 my.ip kernel: TCP: [xx.xx.xx.xx]:55665 to=20 [my.ip.my.ip]:443 tcpflags 0x10; syncache_expand: Segment failed=20 SYNCOOKIE authentication, segment rejected (probably spoofed) Mar 25 14:00:09 my.ip kernel: TCP: [xx.xx.xx.xx]:55665 to=20 [my.ip.my.ip]:443 tcpflags 0x10; syncache_expand: Segment failed=20 SYNCOOKIE authentication, segment rejected (probably spoofed) Mar 25 17:00:00 my.ip kernel: TCP: [xx.xx.xx.xx]:60048 to=20 [my.ip.my.ip]:443 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1:=20 Received 346 bytes of data after socket was closed, sending RST and=20 removing tcpcb Mar 25 17:00:00 my.ip kernel: TCP: [xx.xx.xx.xx]:60048 to=20 [my.ip.my.ip]:443 tcpflags 0x11; syncache_expand: Segment=20 failed SYNCOOKIE authentication, segment rejected (probably spoofed) Mar 25 23:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:50205 to=20 [my.ip.my.ip]:443 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1:=20 Received 346 bytes of data after socket was closed, sending RST and=20 removing tcpcb Mar 25 23:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:50205 to=20 [my.ip.my.ip]:443 tcpflags 0x11; syncache_expand: Segment=20 failed SYNCOOKIE authentication, segment rejected (probably spoofed) Mar 26 00:38:49 my.ip kernel: ipfw: 65400 Deny TCP=20 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=20 [my.ip.my.ip]:443 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1:=20 Received 330 bytes of data after socket was closed, sending RST and=20 removing tcpcb Apr 2 09:00:01 my.ip kernel: TCP: [xx.xx.xx.xx]:57248 to=20 [my.ip.my.ip]:443 tcpflags 0x11; syncache_expand: Segment=20 failed SYNCOOKIE authentication, segment rejected (probably spoofed) But these messages do *not* occur when the ipfw log and tcpdump record=20 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=20 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=20 machine that does the same thing doesn't generate the behaviour=20 described above so it might be something specific to when 6.x machines=20 talk to 7.x. Was there a bug like that in 6.x? --------------enig1FB290221A96A9CD76AF169F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9Wl1ldnAQVacBcgRAnwfAJ9jkCiQbHFCari7u2iR/FseGAlbeQCfSF7y RpnNQrpzFeYeXTGhcg6UBGg= =WLHk -----END PGP SIGNATURE----- --------------enig1FB290221A96A9CD76AF169F--