* [9front] WANTED: ip based filtering of incoming connections
@ 2024-07-25 21:56 Stanley Lieber
2024-07-25 22:08 ` B. Atticus Grobe
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Stanley Lieber @ 2024-07-25 21:56 UTC (permalink / raw)
To: 9front
ai crawlers have discovered one of my servers.
smtpd has the -k flag, which i use to manually block especially egregious spammers, but ip(3) and listen(8) seem to offer nothing generic to bar aggressive customers from entry.
am i missing something?
sl
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-25 21:56 [9front] WANTED: ip based filtering of incoming connections Stanley Lieber
@ 2024-07-25 22:08 ` B. Atticus Grobe
2024-07-26 0:34 ` Stanley Lieber
2024-07-25 22:10 ` Jacob Moody
2024-07-25 22:33 ` Steve Simon
2 siblings, 1 reply; 27+ messages in thread
From: B. Atticus Grobe @ 2024-07-25 22:08 UTC (permalink / raw)
To: 9front; +Cc: sl
[-- Attachment #1: Type: text/plain, Size: 454 bytes --]
On Thu Jul 25, 2024 at 4:56 PM CDT, Stanley Lieber wrote:
> ai crawlers have discovered one of my servers.
>
> smtpd has the -k flag, which i use to manually block especially egregious spammers, but ip(3) and listen(8) seem to offer nothing generic to bar aggressive customers from entry.
>
> am i missing something?
>
> sl
see ipmux in ip(3).
example: aux/dial 'ipmux!vers=4;src=1.2.3.4' >/dev/null
to drop incoming traffic from 1.2.3.4.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-25 22:08 ` B. Atticus Grobe
@ 2024-07-26 0:34 ` Stanley Lieber
2024-07-26 0:47 ` Jacob Moody
0 siblings, 1 reply; 27+ messages in thread
From: Stanley Lieber @ 2024-07-26 0:34 UTC (permalink / raw)
To: 9front
On July 25, 2024 6:08:59 PM EDT, "B. Atticus Grobe" <grobe0ba@tcp80.org> wrote:
>On Thu Jul 25, 2024 at 4:56 PM CDT, Stanley Lieber wrote:
>> ai crawlers have discovered one of my servers.
>>
>> smtpd has the -k flag, which i use to manually block especially egregious spammers, but ip(3) and listen(8) seem to offer nothing generic to bar aggressive customers from entry.
>>
>> am i missing something?
>>
>> sl
>
>see ipmux in ip(3).
>
>example: aux/dial 'ipmux!vers=4;src=1.2.3.4' >/dev/null
>to drop incoming traffic from 1.2.3.4.
thanks!
it seems dial(1) dies when backgrounded with &.
sl
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 0:34 ` Stanley Lieber
@ 2024-07-26 0:47 ` Jacob Moody
2024-07-26 1:55 ` sl
0 siblings, 1 reply; 27+ messages in thread
From: Jacob Moody @ 2024-07-26 0:47 UTC (permalink / raw)
To: 9front
On 7/25/24 19:34, Stanley Lieber wrote:
> On July 25, 2024 6:08:59 PM EDT, "B. Atticus Grobe" <grobe0ba@tcp80.org> wrote:
>> On Thu Jul 25, 2024 at 4:56 PM CDT, Stanley Lieber wrote:
>>> ai crawlers have discovered one of my servers.
>>>
>>> smtpd has the -k flag, which i use to manually block especially egregious spammers, but ip(3) and listen(8) seem to offer nothing generic to bar aggressive customers from entry.
>>>
>>> am i missing something?
>>>
>>> sl
>>
>> see ipmux in ip(3).
>>
>> example: aux/dial 'ipmux!vers=4;src=1.2.3.4' >/dev/null
>> to drop incoming traffic from 1.2.3.4.
>
> thanks!
>
> it seems dial(1) dies when backgrounded with &.
>
> sl
You need to run it in a loop I think, it exits after it catches a connection.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 0:47 ` Jacob Moody
@ 2024-07-26 1:55 ` sl
2024-07-26 1:58 ` Jacob Moody
0 siblings, 1 reply; 27+ messages in thread
From: sl @ 2024-07-26 1:55 UTC (permalink / raw)
To: 9front
> You need to run it in a loop I think, it exits after it catches a connection.
thanks everyone, ipmux has deflected the worst offenders:
; cat nipmux
#!/bin/rc
rfork e
# grep $ip /sys/log/www | awk -F '::' '{print $7;}' | sort | uniq
#
# AMAZON-SIN
# 47.128.0.0&255.252.0.0
#
# crawlers
# 85.208.96.0&255.255.255.0
while(){
aux/dial 'ipmux!vers=4;src=47.128.0.0&255.252.0.0|85.208.96.0&255.255.255.0' >/dev/null
}
sl
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 1:55 ` sl
@ 2024-07-26 1:58 ` Jacob Moody
2024-07-26 2:00 ` sl
2024-07-26 3:36 ` sl
0 siblings, 2 replies; 27+ messages in thread
From: Jacob Moody @ 2024-07-26 1:58 UTC (permalink / raw)
To: 9front
On 7/25/24 20:55, sl@stanleylieber.com wrote:
>> You need to run it in a loop I think, it exits after it catches a connection.
>
> thanks everyone, ipmux has deflected the worst offenders:
>
> ; cat nipmux
> #!/bin/rc
> rfork e
> # grep $ip /sys/log/www | awk -F '::' '{print $7;}' | sort | uniq
> #
> # AMAZON-SIN
> # 47.128.0.0&255.252.0.0
> #
> # crawlers
> # 85.208.96.0&255.255.255.0
>
> while(){
> aux/dial 'ipmux!vers=4;src=47.128.0.0&255.252.0.0|85.208.96.0&255.255.255.0' >/dev/null
> }
>
> sl
Since it's come up at least twice on the mailing list perhaps that qualifies as frequent enough
to put something in the FQA.
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 1:58 ` Jacob Moody
@ 2024-07-26 2:00 ` sl
2024-07-26 3:36 ` sl
1 sibling, 0 replies; 27+ messages in thread
From: sl @ 2024-07-26 2:00 UTC (permalink / raw)
To: 9front
> Since it's come up at least twice on the mailing list perhaps that qualifies as frequent enough
> to put something in the FQA.
yes, i will document this once i verify nothing insane is going on.
sl
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 1:58 ` Jacob Moody
2024-07-26 2:00 ` sl
@ 2024-07-26 3:36 ` sl
2024-07-26 3:43 ` Jacob Moody
2024-07-26 3:54 ` Romano
1 sibling, 2 replies; 27+ messages in thread
From: sl @ 2024-07-26 3:36 UTC (permalink / raw)
To: 9front
> Since it's come up at least twice on the mailing list perhaps that qualifies as frequent enough
> to put something in the FQA.
apologies for the noise, but i've just verified the following doesn't actually work:
---
#!/bin/rc
rfork e
# fn nip{ grep $1 /sys/log/www | awk -F '::' '{print $NF;}' | sort | uniq }
#
# AMAZON-SIN (bytedance)
# 47.128.0.0&255.252.0.0
#
# MSFT (openai)
# 52.230.152.0&255.255.255.0
#
# GOOGLE (semrush.com)
# 64.249.68.0&255.255.255.0
# 64.249.79.0&255.255.255.0
# 64.249.83.0&255.255.255.0
# 85.208.96.0&255.255.255.0
#
# ZEN-SG (bytedance)
# 156.59.198.0&255.255.255.0
while(){
aux/dial 'ipmux!vers=4;src=47.128.0.0&255.252.0.0|52.230.152.0&255.255.255.0|64.249.68.0&255.255.255.0|64.249.79.0&255.255.255.0|64.249.83.0&255.255.255.0|85.208.96.0&255.255.255.0|156.59.198.0&255.255.255.0' >/dev/null
}
---
connections still succeed, pages are still served, and the requests
still show up in /sys/log/www.
what am i doing wrong?
sl
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 3:36 ` sl
@ 2024-07-26 3:43 ` Jacob Moody
2024-07-26 3:47 ` sl
2024-07-26 3:54 ` Romano
1 sibling, 1 reply; 27+ messages in thread
From: Jacob Moody @ 2024-07-26 3:43 UTC (permalink / raw)
To: 9front
On 7/25/24 22:36, sl@stanleylieber.com wrote:
>> Since it's come up at least twice on the mailing list perhaps that qualifies as frequent enough
>> to put something in the FQA.
>
> apologies for the noise, but i've just verified the following doesn't actually work:
>
> ---
>
> #!/bin/rc
> rfork e
> # fn nip{ grep $1 /sys/log/www | awk -F '::' '{print $NF;}' | sort | uniq }
> #
> # AMAZON-SIN (bytedance)
> # 47.128.0.0&255.252.0.0
> #
> # MSFT (openai)
> # 52.230.152.0&255.255.255.0
> #
> # GOOGLE (semrush.com)
> # 64.249.68.0&255.255.255.0
> # 64.249.79.0&255.255.255.0
> # 64.249.83.0&255.255.255.0
> # 85.208.96.0&255.255.255.0
> #
> # ZEN-SG (bytedance)
> # 156.59.198.0&255.255.255.0
>
> while(){
> aux/dial 'ipmux!vers=4;src=47.128.0.0&255.252.0.0|52.230.152.0&255.255.255.0|64.249.68.0&255.255.255.0|64.249.79.0&255.255.255.0|64.249.83.0&255.255.255.0|85.208.96.0&255.255.255.0|156.59.198.0&255.255.255.0' >/dev/null
> }
>
> ---
>
> connections still succeed, pages are still served, and the requests
> still show up in /sys/log/www.
>
> what am i doing wrong?
Did you verify it was working with just a single ip address or two? I am thinking perhaps you ran in to some arbitrary buffer limit.
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 3:43 ` Jacob Moody
@ 2024-07-26 3:47 ` sl
2024-07-26 3:57 ` Jacob Moody
2024-07-26 3:57 ` sl
0 siblings, 2 replies; 27+ messages in thread
From: sl @ 2024-07-26 3:47 UTC (permalink / raw)
To: 9front
> Did you verify it was working with just a single ip address or two? I
> am thinking perhaps you ran in to some arbitrary buffer limit.
even with only one ip address it has no effect.
sl
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 3:47 ` sl
@ 2024-07-26 3:57 ` Jacob Moody
2024-07-26 3:57 ` sl
1 sibling, 0 replies; 27+ messages in thread
From: Jacob Moody @ 2024-07-26 3:57 UTC (permalink / raw)
To: 9front
On 7/25/24 22:47, sl@stanleylieber.com wrote:
>> Did you verify it was working with just a single ip address or two? I
>> am thinking perhaps you ran in to some arbitrary buffer limit.
>
> even with only one ip address it has no effect.
>
> sl
Are you sure it's being bound to the right ip interface?
In my first example I included the details to bind it to a specific interface by its assigned ip address.
Run it on it's one, once, and direct the output to a file. If something gets written at all it has munched that attempted connection.
The problem is that it has to be sitting there attempting to dial the ipmux when the connection gets established, if for example you're
in the middle of writing one out to /dev/null and you get another request it'll go through because there is nothing currently blocked.
I've never tried to use this against some spammy spider, so its possible our little rc loop with aux/dial is not going to cut it.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 3:47 ` sl
2024-07-26 3:57 ` Jacob Moody
@ 2024-07-26 3:57 ` sl
2024-07-26 4:17 ` Jacob Moody
1 sibling, 1 reply; 27+ messages in thread
From: sl @ 2024-07-26 3:57 UTC (permalink / raw)
To: 9front
>> Did you verify it was working with just a single ip address or two? I
>> am thinking perhaps you ran in to some arbitrary buffer limit.
>
> even with only one ip address it has no effect.
the while loop seems useless. if i run this on the command line and never
interrupt it, it just keeps going, and continues to block connections from
this one ip:
; aux/dial 'ipmux!vers=4;src=168.235.81.125&255.255.255.255' >/dev/null
but the original problem i reported still holds true: if i fork it to the
background by placing an & at the end of the line, it exist immediately.
and you're right, even just running it on the command line and not
interrupting it, with a longer list of ip addresses, it has no effect:
; aux/dial 'ipmux!vers=4;src=47.128.0.0&255.252.0.0|52.230.152.0&255.255.255.0|64.249.68.0&255.255.255.0|64.249.79.0&255.255.255.0|64.249.83.0&255.255.255.0|85.208.96.0&255.255.255.0|156.59.198.0&255.255.255.0|168.235.81.125&255.255.255.255' >/dev/null
it never exits, it just doesn't seem to do anything.
sl
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 3:57 ` sl
@ 2024-07-26 4:17 ` Jacob Moody
0 siblings, 0 replies; 27+ messages in thread
From: Jacob Moody @ 2024-07-26 4:17 UTC (permalink / raw)
To: 9front
On 7/25/24 22:57, sl@stanleylieber.com wrote:
>>> Did you verify it was working with just a single ip address or two? I
>>> am thinking perhaps you ran in to some arbitrary buffer limit.
>>
>> even with only one ip address it has no effect.
>
> the while loop seems useless. if i run this on the command line and never
> interrupt it, it just keeps going, and continues to block connections from
> this one ip:
>
> ; aux/dial 'ipmux!vers=4;src=168.235.81.125&255.255.255.255' >/dev/null
>
> but the original problem i reported still holds true: if i fork it to the
> background by placing an & at the end of the line, it exist immediately.
>
> and you're right, even just running it on the command line and not
> interrupting it, with a longer list of ip addresses, it has no effect:
>
> ; aux/dial 'ipmux!vers=4;src=47.128.0.0&255.252.0.0|52.230.152.0&255.255.255.0|64.249.68.0&255.255.255.0|64.249.79.0&255.255.255.0|64.249.83.0&255.255.255.0|85.208.96.0&255.255.255.0|156.59.198.0&255.255.255.0|168.235.81.125&255.255.255.255' >/dev/null
>
> it never exits, it just doesn't seem to do anything.
>
> sl
Sorry, my memory betrayed me here and I got all sorts of things wrong.
Testing things myself I see the same behavior you see, so forget the rc loop.
The issue with dial exiting immediately when backgrounded is because it reads stdin,
if you pass dial a -e flag it will ignore stdin and & will work as intended.
As for the large lines not working, /sys/src/libc/9sys/dial.c has some hard coded
limits and a quick scan makes me think we're capped at Maxstring (128).
Sorry,
moody
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 3:36 ` sl
2024-07-26 3:43 ` Jacob Moody
@ 2024-07-26 3:54 ` Romano
2024-07-26 4:02 ` sl
1 sibling, 1 reply; 27+ messages in thread
From: Romano @ 2024-07-26 3:54 UTC (permalink / raw)
To: 9front
On Thu Jul 25 20:37:59 -0700 2024, sl@stanleylieber.com wrote:
> …
> apologies for the noise, but i've just verified the following doesn't actually work:
> …
> aux/dial 'ipmux!vers=4;src=47.128.0.0&255.252.0.0|52.230.152.0&255.255.255.0|64.249.68.0&255.255.255.0|64.249.79.0&255.255.255.0|64.249.83.0&255.255.255.0|85.208.96.0&255.255.255.0|156.59.198.0&255.255.255.0' >/dev/null
From ip(3), it describes the parameter for ipmux should be ver,
not vers. Might it be as simple as that?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 3:54 ` Romano
@ 2024-07-26 4:02 ` sl
2024-07-26 4:13 ` Romano
0 siblings, 1 reply; 27+ messages in thread
From: sl @ 2024-07-26 4:02 UTC (permalink / raw)
To: 9front
>> apologies for the noise, but i've just verified the following doesn't actually work:
>> …
>> aux/dial 'ipmux!vers=4;src=47.128.0.0&255.252.0.0|52.230.152.0&255.255.255.0|64.249.68.0&255.255.255.0|64.249.79.0&255.255.255.0|64.249.83.0&255.255.255.0|85.208.96.0&255.255.255.0|156.59.198.0&255.255.255.0' >/dev/null
>
> From ip(3), it describes the parameter for ipmux should be ver,
> not vers. Might it be as simple as that?
seems to have just ignored the invalid argument vers. it did work (even with the
invalid argument) when i only specified one ip address to block.
sl
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 4:02 ` sl
@ 2024-07-26 4:13 ` Romano
2024-07-26 4:20 ` Romano
0 siblings, 1 reply; 27+ messages in thread
From: Romano @ 2024-07-26 4:13 UTC (permalink / raw)
To: 9front
On Thu Jul 25 21:04:30 -0700 2024, sl@stanleylieber.com wrote:
> >> apologies for the noise, but i've just verified the following doesn't actually work:
> >> …
> >> aux/dial 'ipmux!vers=4;src=47.128.0.0&255.252.0.0|52.230.152.0&255.255.255.0|64.249.68.0&255.255.255.0|64.249.79.0&255.255.255.0|64.249.83.0&255.255.255.0|85.208.96.0&255.255.255.0|156.59.198.0&255.255.255.0' >/dev/null
> >
> > From ip(3), it describes the parameter for ipmux should be ver,
> > not vers. Might it be as simple as that?
>
> seems to have just ignored the invalid argument vers. it did work (even with the
> invalid argument) when i only specified one ip address to block.
The man page ip(3) shows the possible values for src to be:
Expr is of the form:
value
value|value|...
value&mask
value|value&mask
If a mask is given, the relevant field is first ANDed with
the mask. The result is compared against the value or list
of values for a match.
From the code in /sys/src/9/ip/ipmux.c (lines 214 ff.), it looks
to only use the mask at the very end of a list of values, which
aligns with the docs: the mask can't be interleaved with a value.
So, it processes '&' for the entirety of the 'src' field, and then the
individual ip addresses (without a mask) separated by '|'. So
perhaps change the 'src=' to use 255.255.255.0 and see if that helps?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 4:13 ` Romano
@ 2024-07-26 4:20 ` Romano
2024-07-26 4:44 ` Stanley Lieber
0 siblings, 1 reply; 27+ messages in thread
From: Romano @ 2024-07-26 4:20 UTC (permalink / raw)
To: 9front
Explicitly, I mean this:
aux/dial 'ipmux!ver=4;src=47.128.0.0|52.230.152.0|64.249.68.0|64.249.79.0|64.249.83.0|85.208.96.0|156.59.198.0&255.255.255.0' >/dev/null
The first ip used a mask of 255.255.252.0, so don't know if this
will work for your current problem entirely.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 4:20 ` Romano
@ 2024-07-26 4:44 ` Stanley Lieber
2024-07-26 5:14 ` Romano
0 siblings, 1 reply; 27+ messages in thread
From: Stanley Lieber @ 2024-07-26 4:44 UTC (permalink / raw)
To: 9front
On July 26, 2024 12:20:31 AM EDT, Romano <me+unobe@fallglow.com> wrote:
>Explicitly, I mean this:
>
> aux/dial 'ipmux!ver=4;src=47.128.0.0|52.230.152.0|64.249.68.0|64.249.79.0|64.249.83.0|85.208.96.0|156.59.198.0&255.255.255.0' >/dev/null
>
>The first ip used a mask of 255.255.252.0, so don't know if this
>will work for your current problem entirely.
>
ranges just don't seem to work at all:
; aux/dial 'ipmux!ver=4;src=47.128.0.0&255.252.0.0' >/dev/null
has no effect.
sl
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 4:44 ` Stanley Lieber
@ 2024-07-26 5:14 ` Romano
2024-07-26 23:15 ` Jacob Moody
0 siblings, 1 reply; 27+ messages in thread
From: Romano @ 2024-07-26 5:14 UTC (permalink / raw)
To: 9front
On Thu Jul 25 21:48:02 -0700 2024, sl@stanleylieber.com wrote:
> ranges just don't seem to work at all:
>
> ; aux/dial 'ipmux!ver=4;src=47.128.0.0&255.252.0.0' >/dev/null
>
> has no effect.
I think I'm seeing the same thing. Altho' not documented, I
checked /net/ipmux/stats when filtering 8.8.8.8 with
255.255.255.255, 255.255.255.0, and 255.255.0.0; all return
the same content:
% cat /net/ipmux/stats
iph[0:0]&f0=40|
iph[12:15]=08080808|
%
the iph[12:15]=08080808| I think should have changed to
iph[12:15]=08080800| for 255.255.255.0 and
iph[12:15]=08080000| for 255.255.0.0 .
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 5:14 ` Romano
@ 2024-07-26 23:15 ` Jacob Moody
2024-07-26 23:47 ` sl
0 siblings, 1 reply; 27+ messages in thread
From: Jacob Moody @ 2024-07-26 23:15 UTC (permalink / raw)
To: 9front
On 7/26/24 00:14, Romano wrote:
> On Thu Jul 25 21:48:02 -0700 2024, sl@stanleylieber.com wrote:
>> ranges just don't seem to work at all:
>>
>> ; aux/dial 'ipmux!ver=4;src=47.128.0.0&255.252.0.0' >/dev/null
>>
>> has no effect.
>
> I think I'm seeing the same thing. Altho' not documented, I
> checked /net/ipmux/stats when filtering 8.8.8.8 with
> 255.255.255.255, 255.255.255.0, and 255.255.0.0; all return
> the same content:
> % cat /net/ipmux/stats
> iph[0:0]&f0=40|
>
> iph[12:15]=08080808|
>
>
> %
>
> the iph[12:15]=08080808| I think should have changed to
> iph[12:15]=08080800| for 255.255.255.0 and
> iph[12:15]=08080000| for 255.255.0.0 .
For anyone following along at home, this has now been fixed in commit 605bed312a0a24db6cce2f7170353351cbddbd2d.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 23:15 ` Jacob Moody
@ 2024-07-26 23:47 ` sl
2024-07-27 0:20 ` sl
0 siblings, 1 reply; 27+ messages in thread
From: sl @ 2024-07-26 23:47 UTC (permalink / raw)
To: 9front
> For anyone following along at home, this has now been fixed in commit 605bed312a0a24db6cce2f7170353351cbddbd2d.
i can now successfully block an individual ip:
168.235.81.125&255.255.255.255
or a /24:
168.235.81.0&255.255.255.0
but not a /14:
47.128.0.0&255.252.0.0
sl
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-26 23:47 ` sl
@ 2024-07-27 0:20 ` sl
2024-07-27 0:34 ` Jacob Moody
0 siblings, 1 reply; 27+ messages in thread
From: sl @ 2024-07-27 0:20 UTC (permalink / raw)
To: 9front
>> For anyone following along at home, this has now been fixed in commit 605bed312a0a24db6cce2f7170353351cbddbd2d.
>
> i can now successfully block an individual ip:
>
> 168.235.81.125&255.255.255.255
>
> or a /24:
>
> 168.235.81.0&255.255.255.0
>
> but not a /14:
>
> 47.128.0.0&255.252.0.0
use of the | separator seems to break filtering for the entire line:
aux/dial -e 'ipmux!ver=4;src=85.208.96.0&255.255.255.0|85.208.98.0&255.255.255.0' >/dev/null &
list one ip and it works, list two and it doesn't work.
sl
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-27 0:20 ` sl
@ 2024-07-27 0:34 ` Jacob Moody
2024-07-27 0:49 ` sl
0 siblings, 1 reply; 27+ messages in thread
From: Jacob Moody @ 2024-07-27 0:34 UTC (permalink / raw)
To: 9front
On 7/26/24 19:20, sl@stanleylieber.com wrote:
>>> For anyone following along at home, this has now been fixed in commit 605bed312a0a24db6cce2f7170353351cbddbd2d.
>>
>> i can now successfully block an individual ip:
>>
>> 168.235.81.125&255.255.255.255
>>
>> or a /24:
>>
>> 168.235.81.0&255.255.255.0
>>
>> but not a /14:
>>
>> 47.128.0.0&255.252.0.0
>
> use of the | separator seems to break filtering for the entire line:
>
> aux/dial -e 'ipmux!ver=4;src=85.208.96.0&255.255.255.0|85.208.98.0&255.255.255.0' >/dev/null &
>
This is a bit tricky the interface does not quite work how you want it to.
From the man page:
Expr is of the form:
value
value|value|...
value&mask
value|value&mask
You are only allowed a single mask, not a mask per value.
So we take the input, AND it just once and then check if it matches any of the given values.
This is a bit strange, but it does seem to be intentional.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-27 0:34 ` Jacob Moody
@ 2024-07-27 0:49 ` sl
2024-07-27 1:18 ` sl
0 siblings, 1 reply; 27+ messages in thread
From: sl @ 2024-07-27 0:49 UTC (permalink / raw)
To: 9front
> You are only allowed a single mask, not a mask per value.
> So we take the input, AND it just once and then check if it matches any of the given values.
> This is a bit strange, but it does seem to be intentional.
ah... someone even already tried to explain this to me in this very thread.
thanks!
sl
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-27 0:49 ` sl
@ 2024-07-27 1:18 ` sl
0 siblings, 0 replies; 27+ messages in thread
From: sl @ 2024-07-27 1:18 UTC (permalink / raw)
To: 9front
>> You are only allowed a single mask, not a mask per value.
>> So we take the input, AND it just once and then check if it matches any of the given values.
>> This is a bit strange, but it does seem to be intentional.
>
> ah... someone even already tried to explain this to me in this very thread.
however:
aux/dial -e 'ipmux!ver=4;src=47.128.0.0&255.255.0.0' >/dev/null &
still doesn't block traffic from ips such as 47.128.119.4.
my server has only received around 96,000 requests since midnight last night,
but a substantial amount of them were from a huge range of ip blocks from
useragents self-identifying as ai companies (anthropic, openai, etc.).
currently, i've tried ranges /32, /24, /16, and /14. only /32 and /24 work.
sl
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-25 21:56 [9front] WANTED: ip based filtering of incoming connections Stanley Lieber
2024-07-25 22:08 ` B. Atticus Grobe
@ 2024-07-25 22:10 ` Jacob Moody
2024-07-25 22:33 ` Steve Simon
2 siblings, 0 replies; 27+ messages in thread
From: Jacob Moody @ 2024-07-25 22:10 UTC (permalink / raw)
To: 9front
On 7/25/24 16:56, Stanley Lieber wrote:
> ai crawlers have discovered one of my servers.
>
> smtpd has the -k flag, which i use to manually block especially egregious spammers, but ip(3) and listen(8) seem to offer nothing generic to bar aggressive customers from entry.
>
> am i missing something?
>
> sl
There is a somewhat well kept secret but you can use ipmux to blackhole incoming connections:
; aux/dial 'ipmux!ifc=my.external.ip;dst=192.168.0.0&255.255.0.0|10.0.0.0&255.0.0.0' > /dev/null
There is probably room for something better but this should get the AI grifters off your case for now.
Thanks,
moody
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9front] WANTED: ip based filtering of incoming connections
2024-07-25 21:56 [9front] WANTED: ip based filtering of incoming connections Stanley Lieber
2024-07-25 22:08 ` B. Atticus Grobe
2024-07-25 22:10 ` Jacob Moody
@ 2024-07-25 22:33 ` Steve Simon
2 siblings, 0 replies; 27+ messages in thread
From: Steve Simon @ 2024-07-25 22:33 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
i took a different approach.
i made some local changes to listen, secstored, and httpd.
i have a directory /lib/ndb/banished
when these apps accept a network connection they check for a file in /lib/ndb/banished/<ip>. if the file is too big (more than say 16bytes) then the connection is rejected.
if the app accepts the connection, and detects a failed login it adds one character to /lib/ndb/banished/<ip>
if the login is successful then i delete the /lib/ndb/banished/<ip> file
this makes people who try and brute force the door lock themselves out.
the idea came from log2ban from linux, but in (i feel) a more plan9 style way.
-Steve
> On 25 Jul 2024, at 10:56 pm, Stanley Lieber <sl@stanleylieber.com> wrote:
>
> ai crawlers have discovered one of my servers.
>
> smtpd has the -k flag, which i use to manually block especially egregious spammers, but ip(3) and listen(8) seem to offer nothing generic to bar aggressive customers from entry.
>
> am i missing something?
>
> sl
[-- Attachment #2: Type: text/html, Size: 2594 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2024-07-27 1:20 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-07-25 21:56 [9front] WANTED: ip based filtering of incoming connections Stanley Lieber
2024-07-25 22:08 ` B. Atticus Grobe
2024-07-26 0:34 ` Stanley Lieber
2024-07-26 0:47 ` Jacob Moody
2024-07-26 1:55 ` sl
2024-07-26 1:58 ` Jacob Moody
2024-07-26 2:00 ` sl
2024-07-26 3:36 ` sl
2024-07-26 3:43 ` Jacob Moody
2024-07-26 3:47 ` sl
2024-07-26 3:57 ` Jacob Moody
2024-07-26 3:57 ` sl
2024-07-26 4:17 ` Jacob Moody
2024-07-26 3:54 ` Romano
2024-07-26 4:02 ` sl
2024-07-26 4:13 ` Romano
2024-07-26 4:20 ` Romano
2024-07-26 4:44 ` Stanley Lieber
2024-07-26 5:14 ` Romano
2024-07-26 23:15 ` Jacob Moody
2024-07-26 23:47 ` sl
2024-07-27 0:20 ` sl
2024-07-27 0:34 ` Jacob Moody
2024-07-27 0:49 ` sl
2024-07-27 1:18 ` sl
2024-07-25 22:10 ` Jacob Moody
2024-07-25 22:33 ` Steve Simon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).