Score:-1

Ubuntu

blocking bot attacks ufw fail2ban

colic

12/20/23, 3:16 AM

Im doing something dumb, or missing something. Can anyone spot it please?

I have a tplink archer C7 set to port forward from an external port to port 22 on my internal server for ssh. But I still see external origin activity in auth.log for sshd ports other than 22. This puzzled me, but perhaps the tplink isnt doing port forwarding selectively.

So I added ufw and denied all access, then added

Added user rules (see 'ufw status' for running firewall):
ufw allow 22/tcp

ufw is running and correctly blocking and logging some internal traffic - but there's nothing in the logs blocking the externally originated traffic. I still see activity allegedly for other ports in auth.log.

So I blocked everything ssh in hosts.deny (here you also see entries from fail2ban)

sshd: ALL

sshd: 1.234.5.238
sshd: 101.255.158.25
sshd: 103.138.10.78
sshd: 103.147.119.16
sshd: 103.4.119.20
sshd: 104.236.230.184
sshd: 109.132.238.5
sshd: 111.118.140.250
sshd: 111.68.125.106
...

and used the ipfilter script to geoblock in hosts.allow

sshd: ALL: spawn /usr/local/bin/ipfilter.sh %a

In the auth.log I can see the hosts being denied by the ipfilter

Dec 20 14:00:11 BobsJob root: DENY sshd connection from 114.44.149.56 (TW)
Dec 20 14:00:11 BobsJob sshd[16088]: Invalid user emmmetje from 114.44.149.56 port 34820
Dec 20 14:00:12 BobsJob sshd[16088]: Received disconnect from 114.44.149.56 port 34820:11: Bye Bye [preauth]
Dec 20 14:00:12 BobsJob sshd[16088]: Disconnected from invalid user emmmetje 114.44.149.56 port 34820 [preauth]

But why am I even seeing any log activity in auth.log about port 34820? How is it even getting as far as sshd denying access for invalid user? It should be blocked by my router Failing that it should be blocked by ufw It is finally denied by the ipfilter script in hosts.allow, but it shouldnt even be getting that far.

Is it that the ports noted in auth.log arent real ie they are on the one external port I have open, which gets mapped to 22 internally? But then why does the log report a different port number?

What am I missing here?

181

1 + 0

ufw

fail2ban

sshd

Score:1

Ubuntu

dummyuser

12/20/23, 8:04 AM

A unique TCP session can be described with four parameter, source IP, destination IP source port and destination port.

In your case is the destination IP your local IP, and the destination Port 22. The parameter shown in the log are the source IP and source port. Means “someone” tries to access your ssh server from source IP 114.44.149.56 and source port 34820.

+ 6

colic

12/20/23, 12:10 PM

Thanks for the explanation. The point I was making is that TCP session should never have got past my router's firewall. And if it did, it should never have got past UFW. And certainly not into sshd. You see, in this example, port 34820 is not open either on my firewall nor UFW.

dummyuser

12/20/23, 12:29 PM

you never filter for source ports. the firewall filters for destination ports. in this case port tcp 22 (ssh) and this one is open in your firewall. Source ports are randomly chosen at connection setup from the range 1025-65536.

colic

12/20/23, 10:46 PM

There's something Im seriously misunderstanding, Apologies being slow to grasp it. suppose a legitimate user on 123.123.4.5 tries to connect to myserver.com using ssh on port 2000. My router's set up to accept port 2000 and forward to my server on port 22. The request is successful. A hacker on 114.44.149.56 attempts the same using port 34820. My router iisnt configured to forward that port. The request fails and my server never sees it. It should be rejected at my router? (apologies I cant seem to insert a newline in comments)

dummyuser

12/21/23, 6:32 AM

Nobody is connecting to your router on port 34820. There is ony a connection FROM port 34820 and IP 114.44.149.56. There are some niche articles about soure / destination ports. E.g. [source/destination ports](https://www.firewall.cx/networking-topics/protocols/tcp/133-tcp-source-destination-ports.html)

colic

12/22/23, 6:40 AM

Thankyou, great link. Now I get it, thankyou for educating me.

dummyuser

12/22/23, 6:57 PM

feel free to accept the answer.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: blocking bot attacks ufw fail2ban

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.