Re: Help: network abuse

[David Christensen]

On 12/23/23 22:16, Timothy M Butterworth wrote:

On Sat, Dec 23, 2023 at 8:58 PM David Christensen wrote:

I believe Debian includes packages for various intrusion detection
systems.  Does anyone have any comments or recommendations?


Debian has SNORT and Suricata. I use Suricata. It works well and does not
require paying the subscription for the SNORT oink account.

sudo apt install suricata suricata-update

You can configure Suricata via /etc/suricata/suricata.yaml. All that really
needs configured for a basic IDS/IPS is to change the interfaces from Eth0
to the actual interface. After that you can enable and start Suricata via
SystemD.



Thank you.  :-)


David

Re: Help: network abuse

[Timothy M Butterworth]

On Sat, Dec 23, 2023 at 8:58 PM David Christensen 
wrote:

> On 12/23/23 01:29, Tim Woodall wrote:
> > The fact that the OP is not sending a SYN+ACK (according to the
> > tcpdumps that I saw) means that this is already blackholed.[2]
> >
> > There are three options at this point:
> > 1. Ignore it - my "EVILSYN[1]" blacklist is right at the top of my
> iptables
> > rules and drops without logging before anything else.
> >
> > 2. Talk to their ISP and get it blocked there - that's the only surefire
> > way to stop it eating their quota if that's the problem.
> >
> > 3. Try and make them give up - that's why I suggested sending a RST.
> >
> >
> > [1] I have a set of rules that blacklist IPs that send too many SYN
> > packets that are not responded to with SYN+ACK.
> >
> > [2] This did look weird. I'm not sure how only some connections get a
> > SYN+ACK back - I wonder if their webserver is rate-limited and these are
> > "genuine" connection attempts that are failing - although the SPT=80
> > DPT=80 looks suspiciously like something crafted to get through naive
> > stateless firewall rules that rely on outgoing (allowed) connections to
> > have DPT=80 to the internet and SPT=80 from the internet.
>
>
> Thank you for your comments and explanations.
>
>
> Your [1] and [2] make me think of fail2ban(1).  Any similarities?
>
>
> STFW I found some informative articles:
>
> https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/14760-4.html
>
> https://heimdalsecurity.com/blog/syn-flood/
>
>
> Sending a RST to a falsified IP address would make the sending host into
> an attacker by proxy.  Why do you suggest it?
>
>
> Does Debian and/or Linux support SYN cookies?
>
>
> I believe Debian includes packages for various intrusion detection
> systems.  Does anyone have any comments or recommendations?
>

Debian has SNORT and Suricata. I use Suricata. It works well and does not
require paying the subscription for the SNORT oink account.

sudo apt install suricata suricata-update

You can configure Suricata via /etc/suricata/suricata.yaml. All that really
needs configured for a basic IDS/IPS is to change the interfaces from Eth0
to the actual interface. After that you can enable and start Suricata via
SystemD.



> Analyzing and correlating iptables and httpd logs should provide a
> better understanding of legitimate traffic versus attacker traffic.  We
> would need matching excerpts from the OP to try it.
>
>
> David
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Help: network abuse

[David Christensen]

On 12/23/23 16:15, Dan Ritter wrote:

David Christensen wrote:

Does Debian and/or Linux support SYN cookies?


Yes.

Put

net.ipv4.tcp_syncookies=1

in an appropriate sysctl.d/ file.

To check on current settings:

sysctl -n net.ipv4.tcp_syncookies



It looks like SYN cookies are enabled by default since 
debian-11.6.0-amd64-netinst (what I installed and have since tried to 
keep up to date):


2023-12-23 18:51:24 root@taz ~
# cat /etc/debian_version ; uname -a
11.8
Linux taz 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 
GNU/Linux


2023-12-23 18:51:57 root@taz ~
# sysctl -n net.ipv4.tcp_syncookies
1


Thank you for the incantations.  :-)


David

Re: Help: network abuse

[Dan Ritter]

David Christensen wrote: 
> Does Debian and/or Linux support SYN cookies?

Yes.

Put

net.ipv4.tcp_syncookies=1

in an appropriate sysctl.d/ file.

To check on current settings:

sysctl -n net.ipv4.tcp_syncookies

Re: Help: network abuse

[Pocket]

Sent from my iPhone

> On Dec 23, 2023, at 4:53 PM, Tim Woodall  wrote:
> 
> On Sat, 23 Dec 2023, David Christensen wrote:
>> Sending a RST to a falsified IP address would make the sending host into an 
>> attacker by proxy.  Why do you suggest it?
>> 
> Because the OP wants it to stop. And the OP is running a server on this
> port that is clearly not responding properly or we'd at least see the
> syn+ack. Perhaps it cannot keep up with the connections.
> 
> So the op needs to tell the problem clients to stop retrying.
> 
> If it's malicious traffic then there's nothing the op can do to stop it
> except get a new ip or get their ISP to drop it before it gets to them.
> 
> The op can try icmp port unreachable too. But that tells the client
> there's no server, rather than there's a tcp problem.
> 
> If it's not a bandwidth problem then the op should just ignore it.
> 
> Nobody, but nobody is going to send traffic to some random host with a
> fake source ip in the hopes someone will notice and start sending RST
> some tine later to that address instead of continuing to drop it.
> 

I have a web server on my network. 
I have a firewall on it that only accepts traffic from my internal network.  
Therefore no knows it exists from the outside.  That may not work for the op,  
but his complaint was port 80 traffic to his personal pc.  Which should not 
have a web server running on it.  
You can not do much about scans etc but you can restrict traffic to servers 
only to your internal traffic.   That was my one of my points in stating his 
firewall wasn’t setup properly,  the other is  the firewall blocking icmp and 
conpany.  I use to do that many years ago and it resulting in 1/2 connections.

Re: Help: network abuse

[Tim Woodall]

On Sat, 23 Dec 2023, David Christensen wrote:
Sending a RST to a falsified IP address would make the sending host into an 
attacker by proxy.  Why do you suggest it?



Because the OP wants it to stop. And the OP is running a server on this
port that is clearly not responding properly or we'd at least see the
syn+ack. Perhaps it cannot keep up with the connections.

So the op needs to tell the problem clients to stop retrying.

If it's malicious traffic then there's nothing the op can do to stop it
except get a new ip or get their ISP to drop it before it gets to them.

The op can try icmp port unreachable too. But that tells the client
there's no server, rather than there's a tcp problem.

If it's not a bandwidth problem then the op should just ignore it.

Nobody, but nobody is going to send traffic to some random host with a
fake source ip in the hopes someone will notice and start sending RST
some tine later to that address instead of continuing to drop it.

Re: Help: network abuse

[David Christensen]

On 12/23/23 01:29, Tim Woodall wrote:

The fact that the OP is not sending a SYN+ACK (according to the
tcpdumps that I saw) means that this is already blackholed.[2]

There are three options at this point:
1. Ignore it - my "EVILSYN[1]" blacklist is right at the top of my iptables
rules and drops without logging before anything else.

2. Talk to their ISP and get it blocked there - that's the only surefire
way to stop it eating their quota if that's the problem.

3. Try and make them give up - that's why I suggested sending a RST.


[1] I have a set of rules that blacklist IPs that send too many SYN
packets that are not responded to with SYN+ACK.

[2] This did look weird. I'm not sure how only some connections get a
SYN+ACK back - I wonder if their webserver is rate-limited and these are
"genuine" connection attempts that are failing - although the SPT=80
DPT=80 looks suspiciously like something crafted to get through naive
stateless firewall rules that rely on outgoing (allowed) connections to
have DPT=80 to the internet and SPT=80 from the internet.



Thank you for your comments and explanations.


Your [1] and [2] make me think of fail2ban(1).  Any similarities?


STFW I found some informative articles:

https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/14760-4.html

https://heimdalsecurity.com/blog/syn-flood/


Sending a RST to a falsified IP address would make the sending host into 
an attacker by proxy.  Why do you suggest it?



Does Debian and/or Linux support SYN cookies?


I believe Debian includes packages for various intrusion detection 
systems.  Does anyone have any comments or recommendations?



Analyzing and correlating iptables and httpd logs should provide a 
better understanding of legitimate traffic versus attacker traffic.  We 
would need matching excerpts from the OP to try it.



David

Re: Help: network abuse

[Tim Woodall]

On Thu, 21 Dec 2023, David Christensen wrote:



Perhaps you could set up a DMZ, move services into the DMZ,  and provide a 
VPN connection to the DMZ for your Internet users.  Then you could close all 
of the incoming WAN ports except VPN.



It might be possible to put the VPN endpoint into a VPS, create an SSH tunnel 
out from the httpd server to the VPS, and close all of the WAN incoming 
ports.




If the OP is worried about the bandwidth usage then none of that will
help. The fact that the OP is not sending a SYN+ACK (according to the
tcpdumps that I saw) means that this is already blackholed.[2]

There are three options at this point:
1. Ignore it - my "EVILSYN[1]" blacklist is right at the top of my iptables
rules and drops without logging before anything else.

2. Talk to their ISP and get it blocked there - that's the only surefire
way to stop it eating their quota if that's the problem.

3. Try and make them give up - that's why I suggested sending a RST.


[1] I have a set of rules that blacklist IPs that send too many SYN
packets that are not responded to with SYN+ACK.

[2] This did look weird. I'm not sure how only some connections get a
SYN+ACK back - I wonder if their webserver is rate-limited and these are
"genuine" connection attempts that are failing - although the SPT=80
DPT=80 looks suspiciously like something crafted to get through naive
stateless firewall rules that rely on outgoing (allowed) connections to
have DPT=80 to the internet and SPT=80 from the internet.

Re: Help: network abuse

[David Christensen]

On 12/21/23 04:00, Alain D D Williams wrote:

My home PC is receiving, for hours at a time, 12-30 kB/s input traffic. This is
unsolicited. I do not know what it is trying to achieve but suspect no good. It
is also eating my broadband allowance.

This does not show up in the Apache log files - the TCP connection does not 
succeed.

Sometimes my machine does send a packet in reply, there are 2 examples at the
foot of this email.

Questions:

• What is going on ?

• What can I do about it ?
   I do manually add some of the IPs to the f2b chain which will stop replies
   but that is about it.

My ISP refuses to do anything about it - I admit that I cannot see what they
could do, maybe filter packets with a source port of 80 or 443.

I also get attempts to break into ssh (port 22) - I am not worried about that.

I append a few lines of output of "tcpdump -n -i enp3s0" done today.
192.168.108.2 is the address of my desktop PC.

The connecting IPs below all belong to Amazon but this changes with time, China
is another common source of similar packets.

11:08:56.354303 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], seq 
19070976, win 51894, options [mss 1401,sackOK,TS val 1182532729 ecr 0,nop,wscale 
7], length 0
11:08:56.354700 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], seq 
3665362944, win 51894, options [mss 1402,sackOK,TS val 4179952761 ecr 0,nop,wscale 
7], length 0
11:08:56.360527 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 
479395840, win 51894, options [mss 1412,sackOK,TS val 3391683448 ecr 0,nop,wscale 
7], length 0
11:08:56.360696 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 
1622147072, win 51894, options [mss 1410,sackOK,TS val 2887711608 ecr 0,nop,wscale 
7], length 0
11:08:56.360950 IP 54.184.78.87.80 > 192.168.108.2.80: Flags [S], seq 
3168796672, win 51894, options [mss 1404,sackOK,TS val 535364985 ecr 0,nop,wscale 
7], length 0
11:08:56.364565 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 
132317184, win 51894, options [mss 1407,sackOK,TS val 2350122105 ecr 0,nop,wscale 
7], length 0
11:08:56.364708 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], seq 
1098776576, win 51894, options [mss 1405,sackOK,TS val 3426157689 ecr 0,nop,wscale 
7], length 0
11:08:56.367975 IP 13.231.232.88.80 > 192.168.108.2.80: Flags [S], seq 
3272540160, win 51894, options [mss 1413,sackOK,TS val 979961209 ecr 0,nop,wscale 
7], length 0

2 days ago a similar capture. Note that the source port is 443 not 80:

09:47:31.416452 IP 5.45.73.147.443 > 192.168.108.2.80: Flags [S], seq 
2724200448, win 51894, options [mss 1401,sackOK,TS val 862439534 ecr 0,nop,wscale 
7], length 0
09:47:31.417861 IP 27.124.10.200.443 > 192.168.108.2.80: Flags [S], seq 
925237248, win 51894, options [mss 1407,sackOK,TS val 756418658 ecr 0,nop,wscale 
7], length 0
09:47:31.440892 IP 27.124.10.197.443 > 192.168.108.2.80: Flags [S], seq 
3474063360, win 51894, options [mss 1404,sackOK,TS val 3970828642 ecr 0,nop,wscale 
7], length 0
09:47:31.449393 IP 27.124.10.200.443 > 192.168.108.2.80: Flags [S], seq 
2844721152, win 51894, options [mss 1407,sackOK,TS val 1831471202 ecr 0,nop,wscale 
7], length 0
09:47:31.451430 IP 154.39.104.67.443 > 192.168.108.2.80: Flags [S], seq 
2336358400, win 51894, options [mss 1415,sackOK,TS val 395513698 ecr 0,nop,wscale 
7], length 0
09:47:31.451610 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], seq 
808976384, win 51894, options [mss 1414,sackOK,TS val 1960250978 ecr 0,nop,wscale 
7], length 0
09:47:31.453372 IP 143.92.60.30.443 > 192.168.108.2.80: Flags [S], seq 
3177512960, win 51894, options [mss 1408,sackOK,TS val 4033677410 ecr 0,nop,wscale 
7], length 0
09:47:31.456937 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], seq 
1042087936, win 51894, options [mss 1415,sackOK,TS val 2011106914 ecr 0,nop,wscale 
7], length 0
09:47:31.461961 IP 27.124.10.226.443 > 192.168.108.2.80: Flags [S], seq 
3200516096, win 51894, options [mss 1403,sackOK,TS val 2314013026 ecr 0,nop,wscale 
7], length 0

Examples where my machine sends a reply:

09:47:31.658790 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], seq 
612564992, win 51894, options [mss 1415,sackOK,TS val 2011106914 ecr 0,nop,wscale 
7], length 0
09:47:31.659442 IP 192.168.108.2.80 > 154.39.104.67.443: Flags [S.], seq 
3770299450, ack 1858732033, win 65160, options [mss 1460,sackOK,TS val 164888251 
ecr 395513698,nop,wscale 7], length 0

09:47:31.756220 IP 5.45.73.147.443 > 192.168.108.2.80: Flags [S], seq 
2992898048, win 51894, options [mss 1401,sackOK,TS val 862439534 ecr 0,nop,wscale 
7], length 0
09:47:31.756272 IP 192.168.108.2.80 > 5.45.73.147.443: Flags [.], ack 
1226309633, win 509, options [nop,nop,TS val 2085784149 ecr 994101358], length 0



On 12/21/23 05:10, Alain D D Williams wrote:
> ... I do run a web server at home, but there is only a little/personal
> stuff, it does not receive much real traffic, I do not want it to.
> Most of my web presence is hosted elsewhere.


On 12/21/23 06:58, Alain D 

Re: Help: network abuse

[gene heskett]

On 12/21/23 07:45, Tim Woodall wrote:

On Thu, 21 Dec 2023, Alain D D Williams wrote:

My home PC is receiving, for hours at a time, 12-30 kB/s input 
traffic. This is
unsolicited. I do not know what it is trying to achieve but suspect no 
good. It

is also eating my broadband allowance.

This does not show up in the Apache log files - the TCP connection 
does not succeed.


Sometimes my machine does send a packet in reply, there are 2 examples 
at the

foot of this email.

Questions:

? What is going on ?

? What can I do about it ?
 I do manually add some of the IPs to the f2b chain which will stop 
replies

 but that is about it.

My ISP refuses to do anything about it - I admit that I cannot see 
what they

could do, maybe filter packets with a source port of 80 or 443.

I also get attempts to break into ssh (port 22) - I am not worried 
about that.


I append a few lines of output of "tcpdump -n -i enp3s0" done today.
192.168.108.2 is the address of my desktop PC.

The connecting IPs below all belong to Amazon but this changes with 
time, China

is another common source of similar packets.

11:08:56.354303 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], 
seq 19070976, win 51894, options [mss 1401,sackOK,TS val 1182532729 
ecr 0,nop,wscale 7], length 0
11:08:56.354700 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], 
seq 3665362944, win 51894, options [mss 1402,sackOK,TS val 4179952761 
ecr 0,nop,wscale 7], length 0
11:08:56.360527 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 
479395840, win 51894, options [mss 1412,sackOK,TS val 3391683448 ecr 
0,nop,wscale 7], length 0
11:08:56.360696 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 
1622147072, win 51894, options [mss 1410,sackOK,TS val 2887711608 ecr 
0,nop,wscale 7], length 0
11:08:56.360950 IP 54.184.78.87.80 > 192.168.108.2.80: Flags [S], seq 
3168796672, win 51894, options [mss 1404,sackOK,TS val 535364985 ecr 
0,nop,wscale 7], length 0
11:08:56.364565 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 
132317184, win 51894, options [mss 1407,sackOK,TS val 2350122105 ecr 
0,nop,wscale 7], length 0
11:08:56.364708 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], 
seq 1098776576, win 51894, options [mss 1405,sackOK,TS val 3426157689 
ecr 0,nop,wscale 7], length 0
11:08:56.367975 IP 13.231.232.88.80 > 192.168.108.2.80: Flags [S], seq 
3272540160, win 51894, options [mss 1413,sackOK,TS val 979961209 ecr 
0,nop,wscale 7], length 0


2 days ago a similar capture. Note that the source port is 443 not 80:

09:47:31.416452 IP 5.45.73.147.443 > 192.168.108.2.80: Flags [S], seq 
2724200448, win 51894, options [mss 1401,sackOK,TS val 862439534 ecr 
0,nop,wscale 7], length 0
09:47:31.417861 IP 27.124.10.200.443 > 192.168.108.2.80: Flags [S], 
seq 925237248, win 51894, options [mss 1407,sackOK,TS val 756418658 
ecr 0,nop,wscale 7], length 0
09:47:31.440892 IP 27.124.10.197.443 > 192.168.108.2.80: Flags [S], 
seq 3474063360, win 51894, options [mss 1404,sackOK,TS val 3970828642 
ecr 0,nop,wscale 7], length 0
09:47:31.449393 IP 27.124.10.200.443 > 192.168.108.2.80: Flags [S], 
seq 2844721152, win 51894, options [mss 1407,sackOK,TS val 1831471202 
ecr 0,nop,wscale 7], length 0
09:47:31.451430 IP 154.39.104.67.443 > 192.168.108.2.80: Flags [S], 
seq 2336358400, win 51894, options [mss 1415,sackOK,TS val 395513698 
ecr 0,nop,wscale 7], length 0
09:47:31.451610 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], 
seq 808976384, win 51894, options [mss 1414,sackOK,TS val 1960250978 
ecr 0,nop,wscale 7], length 0
09:47:31.453372 IP 143.92.60.30.443 > 192.168.108.2.80: Flags [S], seq 
3177512960, win 51894, options [mss 1408,sackOK,TS val 4033677410 ecr 
0,nop,wscale 7], length 0
09:47:31.456937 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], 
seq 1042087936, win 51894, options [mss 1415,sackOK,TS val 2011106914 
ecr 0,nop,wscale 7], length 0
09:47:31.461961 IP 27.124.10.226.443 > 192.168.108.2.80: Flags [S], 
seq 3200516096, win 51894, options [mss 1403,sackOK,TS val 2314013026 
ecr 0,nop,wscale 7], length 0


Examples where my machine sends a reply:

09:47:31.658790 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], 
seq 612564992, win 51894, options [mss 1415,sackOK,TS val 2011106914 
ecr 0,nop,wscale 7], length 0
09:47:31.659442 IP 192.168.108.2.80 > 154.39.104.67.443: Flags [S.], 
seq 3770299450, ack 1858732033, win 65160, options [mss 1460,sackOK,TS 
val 164888251 ecr 395513698,nop,wscale 7], length 0


09:47:31.756220 IP 5.45.73.147.443 > 192.168.108.2.80: Flags [S], seq 
2992898048, win 51894, options [mss 1401,sackOK,TS val 862439534 ecr 
0,nop,wscale 7], length 0
09:47:31.756272 IP 192.168.108.2.80 > 5.45.73.147.443: Flags [.], ack 
1226309633, win 509, options [nop,nop,TS val 2085784149 ecr 
994101358], length 0



You can try sending RST. That might make them give up.

There is not much else you can do.

I sometimes do a whois on a persistent offender and blacklist the entire
network. But I don't know if they stop as 

Re: Help: network abuse

[debian-user]

Alain D D Williams  wrote:
> On Thu, Dec 21, 2023 at 10:11:08AM -0500, Pocket wrote:
> 
> > Use a firewall and set it up correctly.  
> 
> That I have done.
> 
> The issue is broadband usage - ie before it hits the firewall.

IIUC you have a residential system with an ISP connection with a
download limit, and on that you are running a web server that you want
to expose so some of your contacts can access it.

You are concerned by scans run by potentially hostile actors against
your server. Particularly by the volume of data they send.

Is that correct?

As long as you have a web server exposed, you cannot stop anybody and
everybody sending packets to it, for good purposes or foul. You can
cause your outermost firewall to drop packets, either from a blacklist
of disallowed addresses or from all hosts except those on an allowed
whitelist of hosts. That should reduce the traffic you see
significantly.

You should in any case instruct your firewall to drop all incoming
packets on all ports except those you specifically need.

Alternatively, you can change your ISP to one that offers unlimited
service. I am happy with Zen, and would be happy to switch to Andrews &
Arnold if I needed to.

Re: Help: network abuse

[Peter Hillier-Brook]

On 21/12/2023 15:11, Pocket wrote:

On 12/21/23 09:58, Alain D D Williams wrote:

[cut]



Use a firewall and set it up correctly.

Assuming a residential environment.

Firewall the router and server(s) as well as all the client machines.

I have nginx, dovecot and exim4 and other daemons running on my network 
servers.


Most, (includes many of the ones here) don't have a firewall properly 
configured. Nor do they understand how to properly configure a firewall.


You will still get scanned but there is little you can do about that.

Are you still here? I thought that you had exited in a sulk because some 
of us on this list were fed up with your trolling.


You're black listed on my systems so don't bother responding.

Peter HB

Re: Help: network abuse

[Pocket]

On 12/21/23 13:04, Alain D D Williams wrote:

On Thu, Dec 21, 2023 at 11:39:40AM -0500, Pocket wrote:

On 12/21/23 10:50, Alain D D Williams wrote:

It is NOT a firewall issue.


If I am correct you don't want any thing from the outside to hit your web
server?

The words "web server" is ambiguous. It can mean my machine, ie can me the
Apache process. The packets are hitting the machine (evidence tcpdump) but not
the process (as the TCP startup does not complete).


If so your firewall is not configured correctly.

You have failed to understand what is happening.



Well yes, I guess so, that is why I don't have the issue you do and I 
don't have any unwanted traffic on my network to any system.





I shall stop after this.


--
Hindi madali ang maging ako

Re: Help: network abuse

[Alain D D Williams]

On Thu, Dec 21, 2023 at 11:39:40AM -0500, Pocket wrote:
> 
> On 12/21/23 10:50, Alain D D Williams wrote:
> > It is NOT a firewall issue.
> 
> 
> If I am correct you don't want any thing from the outside to hit your web
> server?

The words "web server" is ambiguous. It can mean my machine, ie can me the
Apache process. The packets are hitting the machine (evidence tcpdump) but not
the process (as the TCP startup does not complete).

> If so your firewall is not configured correctly.

You have failed to understand what is happening.

I shall stop after this.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Help: network abuse

[Pocket]

On 12/21/23 10:50, Alain D D Williams wrote:

On Thu, Dec 21, 2023 at 10:31:06AM -0500, Pocket wrote:


All you should be seeing is scans which you can not prevent.

I am looking at incoming packets with tcpdump. This sees packets *before* they
are filtered by iptables.


What are you using for a firewall?

Something hand rolled. Reasonably complicated (over 300 rules) as it deals
with: internet, VPN, DMZ, internal network for virtual machines.

It is NOT a firewall issue.



If I am correct you don't want any thing from the outside to hit your 
web server?


If so your firewall is not configured correctly.





It is my belief that your firewall is NOT setup correctly and that is why
you are seeing the traffic.

My firewall *cannot* deal with packets before they hit my machine. They only
hit my machine after they have arrived over broadband.

The only thing that I might be able to do is to somehow prevent discovery that 
my
machine is listening on port 80 -- that would mean somehow distinguishing
between a genuine visitor and one that is mapping the Internet to later pass
that map somewhere else which generates the unwanted traffic that I see.



Which points to your firewall not being correct.



Amazon AWS system. should not be able to hit your http server, unless you
want it to.

How do I distinguish between wanted & unwanted connections. The only thing that
I can think of is to DROP incoming packets if the source port is 80 or 443 -
which would disrupt the mapping process.

However: if the mapping process uses normal TCP (ie high/random port number)
this would do little.


What mapping process?


--
Hindi madali ang maging ako

Re: Help: network abuse

[Jeffrey Walton]

On Thu, Dec 21, 2023 at 10:51 AM Alain D D Williams  wrote:
>
> On Thu, Dec 21, 2023 at 10:31:06AM -0500, Pocket wrote:
> [...]
> > Amazon AWS system. should not be able to hit your http server, unless you
> > want it to.
>
> How do I distinguish between wanted & unwanted connections. The only thing 
> that
> I can think of is to DROP incoming packets if the source port is 80 or 443 -
> which would disrupt the mapping process.
>
> However: if the mapping process uses normal TCP (ie high/random port number)
> this would do little.

You may be able to use

to generate a blacklist.

On machines under my purview, I find Amazon is fairly well behaved.
Microsoft/Sharepoint/Teams, Digital Ocean, China, and other European
country netblocks are much more misbehaving.

Jeff

Re: Help: network abuse

[Alain D D Williams]

On Thu, Dec 21, 2023 at 10:31:06AM -0500, Pocket wrote:

> All you should be seeing is scans which you can not prevent.

I am looking at incoming packets with tcpdump. This sees packets *before* they
are filtered by iptables.

> What are you using for a firewall?

Something hand rolled. Reasonably complicated (over 300 rules) as it deals
with: internet, VPN, DMZ, internal network for virtual machines.

It is NOT a firewall issue.

> It is my belief that your firewall is NOT setup correctly and that is why
> you are seeing the traffic.

My firewall *cannot* deal with packets before they hit my machine. They only
hit my machine after they have arrived over broadband.

The only thing that I might be able to do is to somehow prevent discovery that 
my
machine is listening on port 80 -- that would mean somehow distinguishing
between a genuine visitor and one that is mapping the Internet to later pass
that map somewhere else which generates the unwanted traffic that I see.

> Amazon AWS system. should not be able to hit your http server, unless you
> want it to.

How do I distinguish between wanted & unwanted connections. The only thing that
I can think of is to DROP incoming packets if the source port is 80 or 443 -
which would disrupt the mapping process.

However: if the mapping process uses normal TCP (ie high/random port number)
this would do little.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Help: network abuse

[Pocket]

On 12/21/23 10:24, Alain D D Williams wrote:

On Thu, Dec 21, 2023 at 10:11:08AM -0500, Pocket wrote:


Use a firewall and set it up correctly.

That I have done.

The issue is broadband usage - ie before it hits the firewall.



All you should be seeing is scans which you can not prevent.

What are you using for a firewall?

Show your firewall setup

It is my belief that your firewall is NOT setup correctly and that is 
why you are seeing the traffic.


Amazon AWS system. should not be able to hit your http server, unless 
you want it to.






Assuming a residential environment.

Firewall the router and server(s) as well as all the client machines.

I have nginx, dovecot and exim4 and other daemons running on my network
servers.

Most, (includes many of the ones here) don't have a firewall properly
configured. Nor do they understand how to properly configure a firewall.

You will still get scanned but there is little you can do about that.

--

Hindi madali ang maging ako


--
Hindi madali ang maging ako

Re: Help: network abuse

[Alain D D Williams]

On Thu, Dec 21, 2023 at 10:11:08AM -0500, Pocket wrote:

> Use a firewall and set it up correctly.

That I have done.

The issue is broadband usage - ie before it hits the firewall.

> Assuming a residential environment.
> 
> Firewall the router and server(s) as well as all the client machines.
> 
> I have nginx, dovecot and exim4 and other daemons running on my network
> servers.
> 
> Most, (includes many of the ones here) don't have a firewall properly
> configured. Nor do they understand how to properly configure a firewall.
> 
> You will still get scanned but there is little you can do about that.
> 
> -- 
> 
> Hindi madali ang maging ako
> 

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Help: network abuse

[Pocket]

On 12/21/23 09:58, Alain D D Williams wrote:

On Thu, Dec 21, 2023 at 01:39:53PM +, Andy Smith wrote:


Okay well 30KiB/s is only about 78GiB/month which isn't really a
lot. I think we're both in UK and it's been hard to find a domestic
Internet connection that you'd run a web server on that can't cope
with 78G/mo. So ignoring it seems okay.

I have been with my ISP for 14 years (moved to get IPv6), for various reasons I
cannot change to a tariff that will give me anything like that (their support
has also fallen through the floor) - I need to change (& the landline) and then
I prolly would not care. Andrews & Arnold and Zen seem recommended.


You say these never complete a TCP handshake even though you do run
Apache on port 80? If so, it does make me wonder what they are
trying to do.

They might be trying to hijack an existing TCP connection or, even simpler,
cause my machine problems by having many, many 1/2 set up TCP connections
(which uses memory until they expire).



Use a firewall and set it up correctly.

Assuming a residential environment.

Firewall the router and server(s) as well as all the client machines.

I have nginx, dovecot and exim4 and other daemons running on my network 
servers.


Most, (includes many of the ones here) don't have a firewall properly 
configured. Nor do they understand how to properly configure a firewall.


You will still get scanned but there is little you can do about that.

--

Hindi madali ang maging ako

Re: Help: network abuse

[Alain D D Williams]

On Thu, Dec 21, 2023 at 01:39:53PM +, Andy Smith wrote:

> Okay well 30KiB/s is only about 78GiB/month which isn't really a
> lot. I think we're both in UK and it's been hard to find a domestic
> Internet connection that you'd run a web server on that can't cope
> with 78G/mo. So ignoring it seems okay.

I have been with my ISP for 14 years (moved to get IPv6), for various reasons I
cannot change to a tariff that will give me anything like that (their support
has also fallen through the floor) - I need to change (& the landline) and then
I prolly would not care. Andrews & Arnold and Zen seem recommended.

> You say these never complete a TCP handshake even though you do run
> Apache on port 80? If so, it does make me wonder what they are
> trying to do.

They might be trying to hijack an existing TCP connection or, even simpler,
cause my machine problems by having many, many 1/2 set up TCP connections
(which uses memory until they expire).

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Help: network abuse

[tomas]

On Thu, Dec 21, 2023 at 12:44:33PM +, Tim Woodall wrote:
> On Thu, 21 Dec 2023, Alain D D Williams wrote:

[...]

> You can try sending RST. That might make them give up.

And then, there's tarpit [1] . But then I'd make double-sure you aren't
hurting legitimate traffic.

Cheers

[1] https://manpages.debian.org/bullseye/firehol-doc/firehol-tarpit.5.en.html
-- 
t


signature.asc
Description: PGP signature

Re: Help: network abuse

[Michel Verdier]

On 2023-12-21, Alain D D Williams wrote:

> Yes: I do run a web server at home, but there is only a little/personal stuff,
> it does not receive much real traffic, I do not want it to. Most of my web
> presence is hosted elsewhere.

If you open a port (80 or something else), not on your server but on your
ISP, you will receive traffic from spammers/hackers and enterprises
scanning internet for telling you your security breaches. Even if you
block the traffic on your server, your ISP will transmit and count
it. You can do nothing for that except change your ISP for one who do not
limit your upload.

Re: Help: network abuse

[Andy Smith]

Hello,

On Thu, Dec 21, 2023 at 01:10:59PM +, Alain D D Williams wrote:
> Yes: I do run a web server at home, but there is only a little/personal stuff,
> it does not receive much real traffic, I do not want it to. Most of my web
> presence is hosted elsewhere.

Okay well 30KiB/s is only about 78GiB/month which isn't really a
lot. I think we're both in UK and it's been hard to find a domestic
Internet connection that you'd run a web server on that can't cope
with 78G/mo. So ignoring it seems okay.

You say these never complete a TCP handshake even though you do run
Apache on port 80? If so, it does make me wonder what they are
trying to do. I mean, I don't find surprising a constant stream of
connections to port 80 looking for typical exploitable scripts, but
if they don't even complete the TCP connection then that's a bit
strange.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Help: network abuse

[Alain D D Williams]

On Thu, Dec 21, 2023 at 07:50:42AM -0500, Greg Wooledge wrote:

> If your home Internet service has an "allowance", you probably shouldn't
> run a web server on it.

Yes: I do run a web server at home, but there is only a little/personal stuff,
it does not receive much real traffic, I do not want it to. Most of my web
presence is hosted elsewhere.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Help: network abuse

[Greg Wooledge]

On Thu, Dec 21, 2023 at 12:00:55PM +, Alain D D Williams wrote:
> My home PC is receiving, for hours at a time, 12-30 kB/s input traffic. This 
> is
> unsolicited. I do not know what it is trying to achieve but suspect no good. 
> It
> is also eating my broadband allowance.

> 11:08:56.354303 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], seq 
> 19070976, win 51894, options [mss 1401,sackOK,TS val 1182532729 ecr 
> 0,nop,wscale 7], length 0

34.217.144.104 appears to be an Amazon AWS system.

> 11:08:56.360527 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 
> 479395840, win 51894, options [mss 1412,sackOK,TS val 3391683448 ecr 
> 0,nop,wscale 7], length 0

As does 52.195.179.12.

> 11:08:56.367975 IP 13.231.232.88.80 > 192.168.108.2.80: Flags [S], seq 
> 3272540160, win 51894, options [mss 1413,sackOK,TS val 979961209 ecr 
> 0,nop,wscale 7], length 0

Same for 13.231.232.88.

I'm not 100% sure how to read these logs, but it looks like you're
running a web server on your local system...?  I see .80 after your
internal IP address, which I'm assuming means you have a service running
on port 80, which is normally HTTP.

If your home Internet service has an "allowance", you probably shouldn't
run a web server on it.  If your web site becomes popular all of a sudden
(these things happen -- one link posted in the right place can drive a ton
of traffic to you with no warning), your "allowance" could be completely
exhausted in a day.

You really should consider moving this web service to a provider with no
bandwidth limits.  There are many available, and they're cheap.

Re: Help: network abuse

[Dan Purgert]

On Dec 21, 2023, Alain D D Williams wrote:
> My home PC is receiving, for hours at a time, 12-30 kB/s input
> traffic. This is unsolicited. I do not know what it is trying to
> achieve but suspect no good. It is also eating my broadband
> allowance.
> 
> Questions:
> 
> • What is going on ?

Looks like bots.

> 
> • What can I do about it ?
 

Dropping the entirety of Asia/Africa has helped my logs (though, my ISP
doesn't track usage; and I imagine if they did, it wouldn't actually
HELP anything there, since the traffic already made it to me).  If it's
a reputable hosting company, contacting their abuse department may
possibly help them kill the account(s) running the bots.

-- 
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860


signature.asc
Description: PGP signature

Re: Help: network abuse

[Tim Woodall]

On Thu, 21 Dec 2023, Alain D D Williams wrote:


My home PC is receiving, for hours at a time, 12-30 kB/s input traffic. This is
unsolicited. I do not know what it is trying to achieve but suspect no good. It
is also eating my broadband allowance.

This does not show up in the Apache log files - the TCP connection does not 
succeed.

Sometimes my machine does send a packet in reply, there are 2 examples at the
foot of this email.

Questions:

? What is going on ?

? What can I do about it ?
 I do manually add some of the IPs to the f2b chain which will stop replies
 but that is about it.

My ISP refuses to do anything about it - I admit that I cannot see what they
could do, maybe filter packets with a source port of 80 or 443.

I also get attempts to break into ssh (port 22) - I am not worried about that.

I append a few lines of output of "tcpdump -n -i enp3s0" done today.
192.168.108.2 is the address of my desktop PC.

The connecting IPs below all belong to Amazon but this changes with time, China
is another common source of similar packets.

11:08:56.354303 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], seq 
19070976, win 51894, options [mss 1401,sackOK,TS val 1182532729 ecr 0,nop,wscale 
7], length 0
11:08:56.354700 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], seq 
3665362944, win 51894, options [mss 1402,sackOK,TS val 4179952761 ecr 0,nop,wscale 
7], length 0
11:08:56.360527 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 
479395840, win 51894, options [mss 1412,sackOK,TS val 3391683448 ecr 0,nop,wscale 
7], length 0
11:08:56.360696 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 
1622147072, win 51894, options [mss 1410,sackOK,TS val 2887711608 ecr 0,nop,wscale 
7], length 0
11:08:56.360950 IP 54.184.78.87.80 > 192.168.108.2.80: Flags [S], seq 
3168796672, win 51894, options [mss 1404,sackOK,TS val 535364985 ecr 0,nop,wscale 
7], length 0
11:08:56.364565 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 
132317184, win 51894, options [mss 1407,sackOK,TS val 2350122105 ecr 0,nop,wscale 
7], length 0
11:08:56.364708 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], seq 
1098776576, win 51894, options [mss 1405,sackOK,TS val 3426157689 ecr 0,nop,wscale 
7], length 0
11:08:56.367975 IP 13.231.232.88.80 > 192.168.108.2.80: Flags [S], seq 
3272540160, win 51894, options [mss 1413,sackOK,TS val 979961209 ecr 0,nop,wscale 
7], length 0

2 days ago a similar capture. Note that the source port is 443 not 80:

09:47:31.416452 IP 5.45.73.147.443 > 192.168.108.2.80: Flags [S], seq 
2724200448, win 51894, options [mss 1401,sackOK,TS val 862439534 ecr 0,nop,wscale 
7], length 0
09:47:31.417861 IP 27.124.10.200.443 > 192.168.108.2.80: Flags [S], seq 
925237248, win 51894, options [mss 1407,sackOK,TS val 756418658 ecr 0,nop,wscale 
7], length 0
09:47:31.440892 IP 27.124.10.197.443 > 192.168.108.2.80: Flags [S], seq 
3474063360, win 51894, options [mss 1404,sackOK,TS val 3970828642 ecr 0,nop,wscale 
7], length 0
09:47:31.449393 IP 27.124.10.200.443 > 192.168.108.2.80: Flags [S], seq 
2844721152, win 51894, options [mss 1407,sackOK,TS val 1831471202 ecr 0,nop,wscale 
7], length 0
09:47:31.451430 IP 154.39.104.67.443 > 192.168.108.2.80: Flags [S], seq 
2336358400, win 51894, options [mss 1415,sackOK,TS val 395513698 ecr 0,nop,wscale 
7], length 0
09:47:31.451610 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], seq 
808976384, win 51894, options [mss 1414,sackOK,TS val 1960250978 ecr 0,nop,wscale 
7], length 0
09:47:31.453372 IP 143.92.60.30.443 > 192.168.108.2.80: Flags [S], seq 
3177512960, win 51894, options [mss 1408,sackOK,TS val 4033677410 ecr 0,nop,wscale 
7], length 0
09:47:31.456937 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], seq 
1042087936, win 51894, options [mss 1415,sackOK,TS val 2011106914 ecr 0,nop,wscale 
7], length 0
09:47:31.461961 IP 27.124.10.226.443 > 192.168.108.2.80: Flags [S], seq 
3200516096, win 51894, options [mss 1403,sackOK,TS val 2314013026 ecr 0,nop,wscale 
7], length 0

Examples where my machine sends a reply:

09:47:31.658790 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], seq 
612564992, win 51894, options [mss 1415,sackOK,TS val 2011106914 ecr 0,nop,wscale 
7], length 0
09:47:31.659442 IP 192.168.108.2.80 > 154.39.104.67.443: Flags [S.], seq 
3770299450, ack 1858732033, win 65160, options [mss 1460,sackOK,TS val 164888251 
ecr 395513698,nop,wscale 7], length 0

09:47:31.756220 IP 5.45.73.147.443 > 192.168.108.2.80: Flags [S], seq 
2992898048, win 51894, options [mss 1401,sackOK,TS val 862439534 ecr 0,nop,wscale 
7], length 0
09:47:31.756272 IP 192.168.108.2.80 > 5.45.73.147.443: Flags [.], ack 
1226309633, win 509, options [nop,nop,TS val 2085784149 ecr 994101358], length 0


You can try sending RST. That might make them give up.

There is not much else you can do.

I sometimes do a whois on a persistent offender and blacklist the entire
network. But I don't know if they stop as this happens before any
logging.

I'd suggest sending RST