Enhancement request: Fail2ban

App_rpt-users
1

Suggestion: Add fail2ban into core ASL3 image.

I just noticed lots of hacking attempts on my ASL3 Pi, from multiple miscreants. They use high numbered ports to bypass most firewalls, but still need to access ssh.

I happen to use a rather long and complicated password, so the odds are small they would ever crack my Pi, but… nothing is guaranteed…

Putting Fail2ban on the system takes less than 5 minutes. And if you, the ASL3 developers, do some script-smything it can be painless as you can either ask questions or just make default entires (see below).

Until then:

apt update
apt upgrade -y
apt install rsyslog
apt install fail2ban

Rsyslog will create additional logs, including auth.log which is needed for fail2ban to run. Additional logrotate entries will be created in /etc/logrotate.d.

Then edit the defaults-debian.conf and add or make sure these lines are there:

nano /etc/fail2ban/jail.d/defaults-debian.conf

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log

# banaction will block the offending ip address from your machine, period for the given time based on bantime
#  * `bantime`: The default value of 600 is set to ban an IP for a 10-minute duration. If set to a negative then the ban is permanment.
# change retries to your flavor, people do mistype.  
# ignoreip should be your internal network.  /24 is the entire class C address space xxx.xxx.xxx.1 - 254.

banaction = %(banaction_allports)s
maxretry = 3 
bantime = 600
ignoreip = 192.168.1.0/24

Restart fail2ban:

systemctl restart fail2ban

Immediately my fail2ban log showed:

root@Allstar:/etc/fail2ban/jail.d# cat /var/log/fail2ban.log
2024-11-10 07:18:04,470 fail2ban.server [1813723]: INFO --------------------------------------------------
2024-11-10 07:18:04,470 fail2ban.server [1813723]: INFO Starting Fail2ban v1.0.2
2024-11-10 07:18:04,471 fail2ban.observer [1813723]: INFO Observer start…
2024-11-10 07:18:04,478 fail2ban.database [1813723]: INFO Connected to fail2ban persistent database ‘/var/lib/fail2ban/fail2ban.sqlite3’
2024-11-10 07:18:04,480 fail2ban.database [1813723]: WARNING New database created. Version ‘4’
2024-11-10 07:18:04,480 fail2ban.jail [1813723]: INFO Creating new jail ‘sshd’
2024-11-10 07:18:04,807 fail2ban.jail [1813723]: INFO Jail ‘sshd’ uses pyinotify {}
2024-11-10 07:18:04,808 fail2ban.jail [1813723]: INFO Initiated ‘pyinotify’ backend
2024-11-10 07:18:04,810 fail2ban.filter [1813723]: INFO maxLines: 1
2024-11-10 07:18:04,821 fail2ban.filter [1813723]: INFO maxRetry: 2
2024-11-10 07:18:04,822 fail2ban.filter [1813723]: INFO findtime: 600
2024-11-10 07:18:04,822 fail2ban.actions [1813723]: INFO banTime: 432000
2024-11-10 07:18:04,822 fail2ban.filter [1813723]: INFO encoding: UTF-8
2024-11-10 07:18:04,822 fail2ban.filter [1813723]: INFO Added logfile: ‘/var/log/auth.log’ (pos = 0, hash = 99518ecc17128336c6c4ba4e26c41405356122f4)
2024-11-10 07:18:04,824 fail2ban.jail [1813723]: INFO Jail ‘sshd’ started
2024-11-10 07:18:11,466 fail2ban.filter [1813723]: INFO [sshd] Found 152.53.32.62 - 2024-11-10 07:18:11
2024-11-10 07:18:52,046 fail2ban.filter [1813723]: INFO [sshd] Found 152.53.32.62 - 2024-11-10 07:18:51
2024-11-10 07:18:52,053 fail2ban.actions [1813723]: NOTICE [sshd] Ban 152.53.32.62

152.53.32.62, a German ip address is now banned for 10 minutes. Should the person (probably a bot) come back, it will be banned for another 10 minutes and so on.

Secondary Suggeston:

Change your sshd port from 22 to some other unused port number.

Add the new port to the firewall on the Pi and possibly your router if you want to log in when you are not connected to the internal network.

cd /etc/ssh
nano sshd_config
Change Port = 22 to another number

restart sshd

systemctl restart sshd

DO NOT LOG OUT OF YOUR CURRENT SSH SESSION UNTIL YOU TEST THE NEW CONFIGURATION!!

Open another ssh session and log in using a) the old port (you can't) and b) the new port (you should be successful).

Then delete from the firewall(s) the entry for ssh port 22.

You are now much more secure (nothing is guaranteed)

2

While I agree and have used it on my servers since the beginning of this software or even asterisk systems, it should not be installed by default. It is hard enough to get newbies started understanding this and they are most likely to get themselves banned from improper password and the like, creating even more issues in the near term than hacking.

It requires a higher level of understanding firewalls in general + fail2ban.
If we did not tinker and change our systems often, it may be less of a deal.

However, placing it in the asl-menu is not a bad idea for as long as there is some explanation or warning to wait till everything works well before the install.Changes to port config will require changes to fail2ban and perhaps iptables/ufw

But I just hate looking for issues with asl and find that fail2ban was installed and the cause even the user who installed it denies it was installed.
It complicates troubleshooting by far.
I wish there was a website with simple explanation of what it does and how it works so newbies can digest it. Most do not understand firewall and ports. Some may disagree because they are already versed in it.
But I have lived through the horror of troubleshooting when users have it installed and don’t know or think about the implications of how it works.

Personally I have developed some pretty good methods just using IPTables.
I can keep ssh and sip locked down very well, and iax is open but limited by the nodeslist.

When a asterisk system is discovered, it will continuously have hack attempts. Normally by a few that appear more numerous by IP, but same culprit…
Got one that returns yearly on 2 servers with a new set of about a dozen IP’s.
I permanently block them for 2 years and roll off the 3rd year. All tracked in my iptables by comments in the file. I just don’t like loosing the bandwidth when the hits are more frequent.

Doing the same with 2 web servers, but I use CSF on them. The target there though is wordpress sites.
I can only say there is value in not doing things in a cookie cutter fashion. They know what to expect and are prepared for just that. I throw plenty of curve balls. They know it’s not standard but can’t figure it out. Some obviously are not even looking at where they are going wrong and keep doing the same over and over. Likely using scripts they got on the internet.

Anyway, I think there is a place to submit that and it is not here and I’m not sure where it is, likely on github. Perhaps someone will chime in with a link.

3

@Mike Obviously we don’t exactly agree, but having run fail2ban on Fedora since version 17 (just upgraded to 41), it works quite well.

If you look at my Fedora fail2ban, and you are a newbie, you’d walk away, but we’re doing baby steps here…

Since most people use “passw0rd” or some other easy to crack password, like their name, then at a minimum the port should be changed. Obviously a complex 12+ character alphanumeric + special letters (i.e., #$%^) would go a long way for security, but people don’t or can’t remember them…

For fail2ban, we’re talking just locking down sshd, for now. That, along with a port change is a great start.

As for where to suggest, I like you don’t know, so I picked this venue.

Again, thanks for the help on my Pi issue.

W

4

You misunderstand.
It works very well. I use it on all my asterisk systems.

But are you going to be the one that provides the support for it ? explains how it works to a user ? or even troubleshoot them when they got themselves banned for a fat fingered password and complain they can’t connect to their node/server even after changing the password correctly ?

They can install it themselves knowing or not knowing how it works and receive proper reward for what results. Just like you just did.

Hacks are not 1/10000 of issues bad passwords are on this board and that will lock them out after several attempts on their own systems.
We had this issue when it was a menu item install in asl1.01

5

I did, but didn’t…

Ahhh.no, but then again if you ignore your internal network, you can fat finger all you want.

And then again, if you are logged in, you can use the “unban” command :slight_smile: Yes, that is another issue and you covered that in your first post :slight_smile: :slight_smile:

Let’s call it an additional option… You did mention some of the other services you block, and that’s a discussion we should have … offline

However, with password stores (in browsers and standalone products) remembering passwords become easier. Then again, a PostIt on your screen always works…

W

6

I’m speaking to ssh, iaxrpt and dvswitch mobile and sip phones, AMI and that kinda stuff.

As I said, those that disagree are already versed in it. Don’t have to learn it. Don’t have to teach it either, not going to have to support it.
Easy for you to say force everyone to have it.

Most newbies don’t understand ports or linux. And there is much to learn about ASL, Linux an Asterisk already. It takes most 2 years to get a grip on just that. But if any want it, they can install it.
You did. Hacks are not in the top 500 list of common issues here and are rare.
It’s not a function of ASL.
Security is your responsibility.

7
8

@Mike

That’s why we call this a forum and we have discussions… differing POV, and help in solving issues (where there are times where there are multiple solutions)…

Enjoy your day…

9

As the primary creator of the ASL3 Pi Image, I’ve thought about this a lot. I contemplated fail2ban, SSH-cert-only access, and other items to make the Pis more secure. I make extensive personal use of fail2ban along with custom blocklists build from firehol data feeds.

However @Mike is right that explaining any of this to many consumers of the ASL3 Pi Appliance would be hard to impossible. Getting the AllStarLink world onto a stable, modern platform that “just works” is the top priority on almost every usability decision. Fortunately most users of the ASL3 Pi Appliance won’t be exposing SSH to the Internet anyway.

What I would suggest @KC2NJV is to help contribute to the ASL community by converting your forum post about installing fail2ban into contributed documentation for those that could benefit from it.

As an aside, changing the SSH port to a random different port number is just security-through-obscurity. Many scanners poll ALL ports on a host so your SSH service will be found and poked at. It’s Internet noise for all the people “just discovering” hacking to run Metasploit against trivial account troves against SSH port 22. However the real threats out there aren’t doing that.

10

In reality for an overwhelming majority of us, no one will be purposely hacked to gain info. We will be victims of wide-spread attempts at finding holes in either security of servers or people who just willy-nilly click links or open attachments.

However, there is a second group of hackers that more likely to attack your Pi if it is open to the internet. These are as @N8EI the newbies to hacking. It would be one thing to look, but not touch, but who are we kidding, they look, touch and laugh about it.

And they don’t just try port 22, if you look the attempts, use:

journalctl _SYSTEMD_UNIT=ssh.service | egrep "Failed|Failure"

you’ll probably see entries such as this:

Nov 10 07:40:24 Allstar sshd[1904346]: Failed password for invalid user javi from 152.53.32.62 port 39734 ssh2
Nov 10 07:41:04 Allstar sshd[1907019]: Failed password for root from 152.53.32.62 port 35852 ssh2
Nov 10 07:41:44 Allstar sshd[1909770]: Failed password for root from 152.53.32.62 port 47444 ssh2
Nov 10 07:42:25 Allstar sshd[1912505]: Failed password for root from 152.53.32.62 port 38712 ssh2

Note: I turned my fail2ban on at 07:43…

From a buddy’s Pi, who doesn’t have fail2ban, these of the last entries as I write this post:

Nov 10 19:05:46 erliham sshd[93032]: Failed password for invalid user pchuquimia from 185.74.5.177 port 50356 ssh2
Nov 10 19:05:48 erliham sshd[93017]: Failed password for root from 218.92.0.198 port 48890 ssh2
Nov 10 19:05:51 erliham sshd[93017]: Failed password for root from 218.92.0.198 port 48890 ssh2
Nov 10 19:05:55 erliham sshd[93034]: Failed password for root from 218.92.0.134 port 10879 ssh2
Nov 10 19:05:59 erliham sshd[93034]: Failed password for root from 218.92.0.134 port 10879 ssh2
Nov 10 19:06:01 erliham sshd[93034]: Failed password for root from 218.92.0.134 port 10879 ssh2

You’ll note none of the attempts are for port 22, but different ports looking to execute ssh2.

So, making it just a triffle harder for the bots to find success and report back, keeps our lives a little simpler, especially if we take 10 minutes to “harden” our Pi’s.

If someone who is a “professional” hacker wants to get into your Pi, they will, but why would a professional bother??? A “kid”, absolutely and that’s who you need to protect yourself from!

11

Why are people still exposing things like this directly to the public internet in 2024? It is awful practice and unnecessary. VPNs are easy to set up (PiVPN, etc), and you don’t even have to host them yourself anymore if you don’t want to (Tailscale, etc).

Forwarding ports was for kids running Minecraft servers in their moms basement back in 2014. It’s time to modernize!

1 Like