Re: PF and Raptor SMTP gateway incompatible?

[Dries Schellekens <gwyllion@ace.ulyssis.org>]

Duh, this has been discussed and explained at misc@. Please search the
archive:
http://marc.theaimsgroup.com/?l=openbsd-misc&m=101655617430410&w=2

This out of window ACK is some SYN flooding protection.

On Fri, 14 Jun 2002, Mike Lewinski wrote:

> I think I've tracked this down.... it's also visible under ipfilter on a 2.9
> box with very generic configs. For readability the sample IPs below have
> been replaced with 'openbsd' and 'raptor'.
>
> We've also gotten sporadic reports of MX connect failures to certain MTA's
> with/behind $NEW_FIREWALL_FEATURE (apparently billed as "stopping people
> from telnetting on port 25") as follows:
>
> $ uname -a
> OpenBSD mx01 2.9 GENERIC#0 i386
>
> ipfilter is enabled at this point (ruleset attached):
>
> mx01# tcpdump -n -s 512 host raptor
> tcpdump: listening on xl0
> 10:35:25.361902 openbsd.6857 > raptor.25:
>     S 3681698923:3681698923(0) win 16384
>     <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1284736385 0>
> (DF) [tos 0x10]
>
> 10:35:25.436022 raptor.25 > openbsd.6857:
>     . 612268372:612268396(24) ack 3682698923 win 16384
>     (DF) [tos 0x10]
>
> 10:35:31.320696 openbsd.6857 > raptor.25:
>     S 3681698923:3681698923(0) win 16384
>     <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1284736396 0>
> (DF) [tos 0x10]
>
> 10:35:31.398016 raptor.25 > openbsd.6857: . 0:24(24) ack 1 win 16384 (DF)
> [tos 0x10]
>
> </wash, rinse, repeat>
>
> So their SYN-ACK is missing the SYN needed for three-way handshaking? Let's
> see what happens if I disable ipfilter:
>
> mx01# ipf -D
> mx01# tcpdump -n -s 512 host raptor
> tcpdump: listening on xl0
> 10:35:53.698465 openbsd.46610 > raptor.25: S 3907864920:3907864920(0) win
> 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1284736441 0>
> (DF) [tos 0x10]
> 10:35:53.773702 raptor.25 > openbsd.46610: . 386102375:386102399(24) ack
> 3908864920 win 16384 (DF) [tos 0x10]
> 10:35:53.773781 openbsd.46610 > raptor.25: R 3908864920:3908864920(0) win
> 16384 (DF)
> 10:35:59.320944 openbsd.46610 > raptor.25: S 3907864920:3907864920(0) win
> 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1284736452 0>
> (DF) [tos 0x10]
> 10:35:59.398854 raptor.25 > openbsd.46610: S 2536349184:2536349184(0) ack
> 3907864921 win 8760 <mss 1460> (DF)
> 10:35:59.398935 openbsd.46610 > raptor.25: . ack 1 win 17520 (DF) [tos 0x10]
> 10:35:59.635440 raptor.25 > openbsd.46610: P 1:48(47) ack 1 win 8760 (DF)
> 10:35:59.635575 openbsd.46610 > raptor.25: . ack 48 win 17520 (DF) [tos
> 0x10]
> 10:36:08.091198 openbsd.46610 > raptor.25: P 1:7(6) ack 48 win 17520 (DF)
> [tos 0x10]
> 10:36:08.165825 raptor.25 > openbsd.46610: P 48:92(44) ack 7 win 8754 (DF)
> 10:36:08.165914 openbsd.46610 > raptor.25: . ack 92 win 17476 (DF) [tos
> 0x10]
> 10:36:08.365233 raptor.25 > openbsd.46610: F 92:92(0) ack 7 win 8754 (DF)
> 10:36:08.365311 openbsd.46610 > raptor.25: . ack 93 win 17520 (DF) [tos
> 0x10]
> 10:36:08.368739 openbsd.46610 > raptor.25: F 7:7(0) ack 93 win 17520 (DF)
> [tos 0x10]
> 10:36:08.441722 raptor.25 > openbsd.46610: . ack 8 win 8754 (DF)
> ^C
> 171 packets received by filter
> 0 packets dropped by kernel
>
> Apparently they will not send a SYN-ACK to setup a connection unless a RST
> is received for the first bogus SYN-ACK, while both ipfilter and pf
> (3.1-stable) using a fairly generic ruleset appropriate for an MTA block
> their bogus packet, preventing any further communications. I've duplicated
> this with the same two MTA's across quite a few different boxes.
>
> $ grep raptor /var/log/ipflog | tail -n 3
> Jun 14 10:35:25 mx01 ipmon[24954]: 10:35:25.436057              xl0 @0:9 b
> raptor,25 -> openbsd,6857 PR tcp len 20 64 -A IN
> Jun 14 10:35:31 mx01 ipmon[24954]: 10:35:31.398045              xl0 @0:9 b
> raptor,25 -> openbsd,6857 PR tcp len 20 64 -A IN
> Jun 14 10:35:43 mx01 ipmon[24954]: 10:35:43.395523              xl0 @0:9 b
> raptor,25 -> openbsd,6857 PR tcp len 20 64 -A IN
>
>
> $ grep -v ^# /etc/ipf.rules
> pass in quick on lo0 all
> pass out quick on lo0 all
> pass in quick on xl0 proto tcp from any to openbsd port = 25
> pass out quick on xl0 proto tcp from openbsd to any keep state
> pass out quick on xl0 proto udp from openbsd to any keep state
> pass out quick on xl0 proto icmp from openbsd to any keep state
> block in log on xl0 from any to openbsd
>
> Would someone who knows the RFC requirements better than I do please comment
> (reading 793 now...)?
>
> Mike
>
> P.S. I'm not sure what the raptor is really trying to accomplish, since it
> isn't stopping anyone from telnetting to port 25...
>

-- 
Dries Schellekens
email: gwyllion@ulyssis.org