**/var/log/btmp` is a system security log that records all failed login attempts to your Linux server.**

Every time someone tries to log in via SSH, the terminal, or local console and enters an incorrect password or username, the system logs it here. Because it captures malicious activity, it is a vital tool for checking if your server is under a brute-force attack.

---

Key Characteristics of /var/log/btmp

- **It is a binary file:** You cannot read it using normal text commands like cat, nano, or less. If you try, your screen will fill with unreadable scrambled code. - **Strict Permissions:** Because it logs failed login details (which sometimes accidentally contain real passwords typed into the username field), only the root user can read it.

---

How to View It Safely

To read this binary file, Linux includes a specific tool called last with the -f flag. Run this command with sudo:

bash

Use code with caution.

**What the output looks like:**

text

Use code with caution.

- **Column 1:** The username attempted (e.g., root, admin, or completely fake usernames like invalid). - **Column 3:** The **IP address** of the machine or bot trying to break into your server.

---

Common Issues: Why is it growing large?

If your server has a public IP address and port 22 (SSH) is open to the internet, automated botnets will target it 24/7 trying thousands of common passwords. This can cause /var/log/btmp to swell to hundreds of megabytes or gigabytes very quickly.

To check how many failed login attempts have hit your server, you can count the lines in the parsed file:

bash

Use code with caution.

---

Even with SSH moved to a custom port like 2010, sophisticated automated bots will eventually scan your server, find the open port, and begin brute-forcing it.

You can use a few quick terminal commands to analyze your /var/log/btmp file and find out exactly who is attacking you and if **Fail2ban** is doing its job.

---

1. Find the Top Attacking IP Addresses

To see a ranked list of the specific IP addresses hitting your server with failed login attempts, parse the btmp file using this command:

bash

Use code with caution.

- **What this does:** It extracts the IP column, counts the duplicate entries, and displays the top 10 most aggressive IP addresses alongside the exact number of failed attempts they made.

2. Find the Most Targeted Usernames

Attackers usually guess common system accounts. Run this to see what usernames they are trying to use to break in:

bash

Use code with caution.

- **What to look for:** You will likely see root, admin, user, or ubuntu. If you see actual personal usernames that exist on your system, it means the attack is more targeted.

3. Verify if Fail2ban is Actually Blocking Them

Moving SSH to port 2010 means you need to ensure Fail2ban is actually listening to that custom port. Otherwise, it will ignore the attacks.

First, check the status of your SSH jail:

bash

Use code with caution.

- Look at the **"Banned IP list"** at the bottom of the output. If it shows active IP addresses, Fail2ban is successfully protecting your new port. - If the list is completely empty despite having thousands of entries in your btmp log, Fail2ban might still be looking for port 22.

4. Ensure Fail2ban Knows Your Custom Port

If Fail2ban isn't catching them, open your Fail2ban configuration file (usually /etc/fail2ban/jail.local):

ini

Use code with caution.

*Ensure port = 2010 is explicitly set.* If you make changes, restart the service:

bash

Use code with caution.

---

Your terminal output provides highly valuable security data.

**Yes, you are definitely being attacked by automated brute-force bots.** The IP address 103.137.184.170 alone has hammered your custom SSH port over **216,000 times**.

The good news is that **Fail2ban is working**. It actively monitors your custom port (as shown by Journal matches: _SYSTEMD_UNIT=sshd.service), has banned 427 IPs total, and currently has 7 IPs blocked—including 211.253.8.115, which is number 10 on your top attackers list.

However, because the attack numbers are so massive (hundreds of thousands of attempts), Fail2ban is letting too many retries through before trigger-banning, or your ban times are too short.

---

Recommended Hardening Steps

1. Make Fail2ban More Aggressive

Currently, bots are allowed to try thousands of times because your ban duration might be too short, or they reset after a few failures. Let's make it strict. Open your Fail2ban local configuration file:

bash

Use code with caution.

Find or create your [sshd] section and adjust these parameters:

ini

Use code with caution.

*Save the file (Ctrl+O, Enter, Ctrl+X) and restart Fail2ban:*

bash

Use code with caution.

2. Manually Ban the #1 Threat Right Now

The IP 103.137.184.170 has broken the threshold completely. You can force Fail2ban to ban it instantly without waiting for the next trigger:

bash

Use code with caution.

3. Disable Root Logins Over SSH

Your log shows **82,029** attempts trying to guess the password for the root user. If you haven't already, completely disable logging directly into the root account via SSH.

Open your SSH daemon configuration file:

bash

Use code with caution.

Find the line PermitRootLogin and change it to no:

text

Use code with caution.

*Save the file and restart your SSH service to apply:*

bash

Use code with caution.

*(Note: Ensure you have your normal meson user password or SSH key working before doing this, so you don't lock yourself out).*

4. Clean up /var/log/btmp

Now that you have analyzed the threat, you can safely clear out this binary log file to reclaim disk space, just like you did with the MariaDB log:

bash

Use code with caution.

---

To wrap up your server security checklist, let me know:

- Do you log in using a **password** or an **SSH Cryptographic Key**? (Switching to keys stops brute forces completely). - Would you like help configuring **UFW (the firewall)** to restrict SSH port 2010 access to only your specific home/office IP?

AI responses may include mistakes. [Learn more](https://support.google.com/websearch?p=aimode)

Using an **SSH key** is the absolute best security choice you could make. Even with 216,000 brute-force password guesses, it is mathematically impossible for those bots to break in because your server completely rejects password authentication for your key-based account.

Since you are already using **UFW**, you can easily block these relentless bots at the firewall layer. This is much more efficient because it drops their network traffic completely before it can even touch or slow down your SSH service.

Here is how to finalize and lock down your setup based on your configuration:

1. Close the Root Exploit Completely

In Ubuntu, if #PermitRootLogin prohibit-password is commented out, the system defaults to allowing root login attempts under certain conditions. Since you are using SSH keys for your user account, you should explicitly deny the root user from ever logging in.

Open your configuration file:

bash

Use code with caution.

Add or modify this exact line (make sure there is no # symbol in front of it):

text

Use code with caution.

Save the file (Ctrl+O, Enter, Ctrl+X) and restart SSH:

bash

Use code with caution.

2. Block the Worst Attacker in UFW Immediately

Fail2ban works dynamically, but for an IP address as aggressive as 103.137.184.170, you should block it permanently at the firewall level so it cannot access your Nextcloud instance or any other port:

bash

Use code with caution.

*(Using insert 1 ensures this rule sits at the very top of your firewall checklist, blocking the packet instantly).*

3. Ultimate Security: Restrict Port 2010 to Your IP Only

If you always connect to your server from the same location (like your home, office, or a static VPN IP), you can tell UFW to block the *entire world* from port 2010 except for you.

First, delete your generic open SSH rule:

bash

Use code with caution.

Next, allow **only your specific IP address** to see port 2010:

bash

Use code with caution.

*(Replace YOUR_HOME_IP with your actual public IP address, which you can find by searching "what is my IP" on your computer).*

Once you run this, the 216,000 automated bot attempts will instantly drop to zero because their network packets will be silently ignored by UFW.

---