[9front] WANTED: ip based filtering of incoming connections

[9front] WANTED: ip based filtering of incoming connections

[Stanley Lieber]

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

Re: [9front] WANTED: ip based filtering of incoming connections

[B. Atticus Grobe]

[-- 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 --]

Re: [9front] WANTED: ip based filtering of incoming connections

[Jacob Moody]

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

Re: [9front] WANTED: ip based filtering of incoming connections

[Steve Simon]

[-- 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 --]

Re: [9front] WANTED: ip based filtering of incoming connections

[Stanley Lieber]

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

Re: [9front] WANTED: ip based filtering of incoming connections

[Jacob Moody]

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.

Re: [9front] WANTED: ip based filtering of incoming connections

[sl]

> 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

Re: [9front] WANTED: ip based filtering of incoming connections

[Jacob Moody]

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.

Re: [9front] WANTED: ip based filtering of incoming connections

[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.

yes, i will document this once i verify nothing insane is going on.

sl

Re: [9front] WANTED: ip based filtering of incoming connections

[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.

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

Re: [9front] WANTED: ip based filtering of incoming connections

[Jacob Moody]

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.

Re: [9front] WANTED: ip based filtering of incoming connections

[sl]

> 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

Re: [9front] WANTED: ip based filtering of incoming connections

[Romano]

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?

Re: [9front] WANTED: ip based filtering of incoming connections

[Jacob Moody]

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.

Re: [9front] WANTED: ip based filtering of incoming connections

[sl]

>> 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

Re: [9front] WANTED: ip based filtering of incoming connections

[sl]

>> 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

Re: [9front] WANTED: ip based filtering of incoming connections

[Romano]

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?

Re: [9front] WANTED: ip based filtering of incoming connections

[Jacob Moody]

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

Re: [9front] WANTED: ip based filtering of incoming connections

[Romano]

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.

Re: [9front] WANTED: ip based filtering of incoming connections

[Stanley Lieber]

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

Re: [9front] WANTED: ip based filtering of incoming connections

[Romano]

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 .

Re: [9front] WANTED: ip based filtering of incoming connections

[Jacob Moody]

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.

Re: [9front] WANTED: ip based filtering of incoming connections

[sl]

> 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

Re: [9front] WANTED: ip based filtering of incoming connections

[sl]

>> 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

Re: [9front] WANTED: ip based filtering of incoming connections

[Jacob Moody]

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.

Re: [9front] WANTED: ip based filtering of incoming connections

[sl]

> 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

Re: [9front] WANTED: ip based filtering of incoming connections

[sl]

>> 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