Date: Fri, 6 Oct 2017 23:31:09 -0700 From: Doug Hardie <bc979@lafn.org> To: Dave Horsfall <dave@horsfall.org> Cc: FreeBSD PF List <freebsd-pf@freebsd.org> Subject: Re: Rate-limiting in PF Message-ID: <ECE71287-0D34-4379-A3FC-E596AFF8A827@mail.sermon-archive.info> In-Reply-To: <alpine.BSF.2.21.1710071632520.876@aneurin.horsfall.org> References: <alpine.BSF.2.21.1710010949380.73049@aneurin.horsfall.org> <alpine.BSF.2.21.1710050853400.73049@aneurin.horsfall.org> <3dc9c2a9-ae68-1e56-d2b1-12530772690f@unsane.co.uk> <alpine.BSF.2.21.1710051116480.73049@aneurin.horsfall.org> <alpine.BSF.2.21.1710071632520.876@aneurin.horsfall.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 6 October 2017, at 22:51, Dave Horsfall <dave@horsfall.org> wrote:
>=20
> On Thu, 5 Oct 2017, Dave Horsfall wrote:
>=20
>>> is anything added to the table (pfctl -t woodpeckers -T show)
>>=20
>> I have lots of them because I've been adding them by hand, but this =
time I'll hold back and observe, just to be sure.
>=20
> No, they are not being added; here's an extract from the mail log:
>=20
> Oct 7 15:21:28 aneurin sm-mta[6908]: v974LI1n006908: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct 7 15:21:48 aneurin sm-mta[6909]: v974Lcwj006909: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct 7 15:21:59 aneurin sm-mta[6910]: v974LnTe006910: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct 7 15:22:13 aneurin sm-mta[6923]: v974M2QU006923: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct 7 15:22:24 aneurin sm-mta[6924]: v974MGKm006924: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct 7 15:22:35 aneurin sm-mta[6925]: v974MOQW006925: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct 7 15:22:45 aneurin sm-mta[6926]: v974MZOZ006926: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct 7 15:22:56 aneurin sm-mta[6927]: v974MkO2006927: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct 7 15:23:07 aneurin sm-mta[6928]: v974MvjQ006928: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct 7 15:23:18 aneurin sm-mta[6930]: v974N7c3006930: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct 7 15:23:38 aneurin sm-mta[6931]: v974NRZM006931: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct 7 15:23:49 aneurin sm-mta[6932]: v974NcYF006932: [37.49.224.104] =
did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
>=20
> "pfctl -t woodpeckers -T show | grep 37.49.224.104" is empty.
>=20
> But wait...
>=20
> It looks for all the world like they are deliberately stopping after =
5/m without getting blocked, waiting a bit, then starting up again... =
Either that, or the block is not "sticking" for some reason.
>=20
> Hence my question: can anyone state unequivocally that the rate =
limiting does indeed work (pref. with proof) and that I am doing =
something subtly wrong, and if so what is it?
>=20
> In the meantime, I've enabled logging on the rate-limited packets, to =
see if that sheds a little more light.
>=20
> If/when confirmed as a PF bug I'll report it accordingly, as I prefer =
to eliminate my own stupidity first :-)
mail# pfctl -Ts -twoodpeckers
54.218.78.120
64.142.105.165
67.231.156.214
74.208.165.59
117.92.178.86
117.92.197.203
169.232.46.186
223.130.19.71
223.240.208.137
Using the last entry as it was undoubtedly entered today:
mail# grep 223.240.208.137 maillog | grep " CONNECT"
Oct 6 22:22:06 mail postfix/postscreen[6784]: CONNECT from =
[223.240.208.137]:3583 to [10.0.1.230]:25
Oct 6 22:22:08 mail postfix/postscreen[6784]: CONNECT from =
[223.240.208.137]:2623 to [10.0.1.230]:25
Oct 6 22:22:36 mail postfix/postscreen[6784]: CONNECT from =
[223.240.208.137]:1571 to [10.0.1.230]:25
Oct 6 22:22:39 mail postfix/postscreen[6784]: CONNECT from =
[223.240.208.137]:1154 to [10.0.1.230]:25
Oct 6 22:22:42 mail postfix/postscreen[6784]: CONNECT from =
[223.240.208.137]:4433 to [10.0.1.230]:25
Oct 6 22:22:45 mail postfix/postscreen[6784]: CONNECT from =
[223.240.208.137]:1485 to [10.0.1.230]:25
mail# tcpdump -r pflog -ve host 223.240.208.137
reading from file pflog, link-type PFLOG (OpenBSD pflog file)
22:22:51.546323 rule 2/0(match): block in on bge0: (tos 0x0, ttl 112, id =
14786, offset 0, flags [none], proto TCP (6), length 40)
223.240.208.137.4737 > mail.smtp: Flags [.], cksum 0x35b0 (correct), =
ack 2194297633, win 65535, length 0
22:22:54.554098 rule 2/0(match): block in on bge0: (tos 0x0, ttl 112, id =
53710, offset 0, flags [none], proto TCP (6), length 40)
223.240.208.137.4737 > mail.smtp: Flags [.], cksum 0x35b0 (correct), =
ack 1, win 65535, length 0
22:22:57.636227 rule 2/0(match): block in on bge0: (tos 0x0, ttl 112, id =
30650, offset 0, flags [none], proto TCP (6), length 40)
223.240.208.137.4737 > mail.smtp: Flags [.], cksum 0x35b0 (correct), =
ack 1, win 65535, length 0
The way I read this is that 223.240.208.137 tried 6 times in less than =
one minute. It was added to woodpeckers around 22:22:45. The next =
connection was after that at 22:22:51 and it was blocked by pf rule 2 =
which is:
block drop in log quick on bge0 from <woodpeckers> to any
Rule 3 is:
pass in inet proto tcp from any to any port =3D smtp flags S/SA keep =
state (source-track rule, max-src-conn 10, max-src-conn-rate 5/60, =
overload <woodpeckers> flush global, src.track 60)
This is on FreeBSD 11.1.
-- Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ECE71287-0D34-4379-A3FC-E596AFF8A827>