Basically, my mainframe has remote logs set up, and all of them are sent to the log center on the Synology NAS.
There is a Raspberry Pi that acts as a router, there will be a bunch of sshd verification attempts to log in,
Disconnected from invalid user slurm 128.199.177.36 port 60810 [preauth]
Basically, I only allow public key authentication,
So don’t even think about brute force cracking with account passwords, but a bunch of It's really annoying to read the Log of failed verification.
So I googled and saw this thing fail2ban, it looks very good, let's set it up.
The following are my installation steps, just write them down:
The first step: Install
apt-get install fail2ban
We You can switch the directory to /etc/fail2ban, and then take a look at the jail.conf file.
root@ptest:/etc/fail2ban# head jail.conf
#
# WARNING: heavily refactored in 0.9.0 release. Please review and
# customize settings for your setup.
#
# Changes: in most of the cases you should not modify this
# file, but provide customizations in jail.local file,
# or separate .conf files under jail.d/ directory, e.g.:
#
# HOW TO ACTIVATE JAILS:
#
As mentioned above, in most cases, we should not change this file, but provide a custom jail.local
Step two: In the /etc/fail2ban directory
cd /etc/fail2ban
cp jail.conf jail.local
Step 3: Modify jail.local
Find the place of sshd, other places in this file also have #[sshd], don’t Uncomment, that's just his explanation.
Add two lines, "Start" and "Action".
enabled = true
action = %(action_)s
In the above example, action_ uses the simplest setting
action_ : The simplest action to take: ban only
action_mw: ban & send an e-mail with whois report to the destemail.
action_mwl: ban & send an e-mail with whois report and relevant log lines
Complete as follows
[sshd]
# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
enabled = true
action = %(action_)s
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Step 4: Start
(systemctl is really easy to use, I thought the service command was good before, so why change this , I am used to it now😝)
#Automatically start when booting
systemctl enable fail2ban
#start up
systemctl start fail2ban
Step 5: Check the startup status, and actvie means it is running
Fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2022-12-11 10:38:59 CST; 1h 12min ago
Docs: man: fail2ban(1)
Main PID: 26761 (fail2ban-server)
Tasks: 3 (limit: 4915)
CGroup: /system.slice/fail2ban.service
└─26761 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
If it fails to start, you can check if there is any error
- -dp, --dump-pretty dump the configuration using more human readable representation
fail2ban-client --dp
Step 6: Check the status of <JAIL>, sshd is the name of <JAIL>
fail2ban-client status sshd< /code>
The result screen is as follows:
(The action = in the third step is very important, it must be set, otherwise the Baned IP list you see here is just for eyes The illusion of heavy karma)
root@ptest:/etc/fail2ban# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 12
| |- Total failed: 280
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 2
|- Total banned: 6
`- Banned IP list: 88.218.17.117 137.184.65.253
fail2ban-client has quite a lot of functions, which are too complicated to be loaded, please type the command yourself to view it
fail2ban-client
Example: Manually watch directly
root@ptest:~# fail2ban-client | grep banip
set <JAIL> banip <IP> manually Ban <IP> for <JAIL>
set <JAIL> unbanip <IP> manually Unban <IP> in <JAIL>
root@ptest:~#
Confirm whether it is useful, you can find a host to test to see if you can log in, if you manually ban the IP, you will not be able to log in.
fail2ban-client set sshd banip 34.81.227.39
fail2ban-client set sshd unbanip 34.81.227.39
After the test group is blocked, it is really impossible to connect. Below is a schematic diagram
~# ssh ptest
ssh: connect to host host port 22: Cannot assign requested address
Checked the log center on my Synology, it really is much less
No Comment
Post your comment