Am I experiencing a brute force attack?
Yes it looks like you are experiencing a brute force attack. The attacker is in on a class B private address, so it is likely to be someone with access to your organization's network that is conducting the attack. From the usernames it looks like they are running though a dictionary of common usernames.
Have a look at 'How to stop/prevent SSH bruteforce' (Serverfault) and 'Preventing brute force SSH attacks' (Rimu Hosting) on how to take measures to mitigate some of the risk relating to SSH bruteforce attacks.
Yes, this looks exactly like a brute-force attack and after googling admins phoenix piglet rainbow it looks like this is the wordlist the attacker is using: https://github.com/hydrogen18/kojoney/blob/master/fake_users
Check out line 116 onwards. The wordlist is being used in the exact same order.
This appears to be a generic wordlist as it also present on other sites. e.g. http://src.gnu-darwin.org/ports/net/kojoney/work/kojoney/fake_users
@TheJulyPlot has provided some good information on what to do to mitigate this attack.
Quick note added about fail2ban, as a lot of people have been mentioning it: The front-end is a corporate firewall, the back-end only sees the redirection/proxy/internal address that comes from the firewall.
So no, 172.25.1.1 is not an internal machine compromised (and both the comment in the answer, and other answer here stating it is an internal machine are wrong when commenting that). It is one of the internal IP addresses of the firewall.
Fail2ban in the back-end would only block all possibility to use SSH for stretches at a time as it only sees failed attempts from 172.25.1.1. So please, read on for my answer.
There are no doubts, as other posts mention, it is painfully obvious you are under a brute force attack.
However, that does not mean at all you are compromised in any way from the logs you have shown us. Alas, these days ssh brute force attacks are all too common. Most of the time they are really automated, and you are not necessarily being targeted.
As an anecdotal warning tale, some years ago the first day I set up new servers in an ISP provider, the ssh one open to the Internet got 200k+ ssh scanning probes on a single night.
As for the "internal IP address," either you are using SNAT or a 22/TCP proxy redirect at best, and the source Internet IPs do not show (which is not the best practice), or at worst your router/cable modem is compromised.
If you do really are having a SNAT/proxy SSH configuration, I do recommend you to think it over. You want logs of the real IP addresses, and not of your network.
As for measures, I do recommend some:
- Do not allow passwords in SSH; only logins using RSA certificates;
- Do not open ssh for the outside; restrict it to your internal network;
- For accessing from the outside, access via a VPN; do not expose SSH to the Internet at large;
- rate-limiting SYNs from the outside.
If you absolutely insist in still having the SSH Internet open to the outside, be aware that changing the default SSH port gives only a fake sense of security, and blocking temporarily IP addresses only slows the attack down as often we are talking about coordinated farms of zombie machines.
You may want to have a look at fail2ban if you do change your configuration to receive directly public IP addresses connecting to you; however take into account that if indeed any external IP arrives with the IP address of your gateway, you are effectively locking out all external SSH access using it.
There are also other caveats; please do note that nowadays zombies/malware take fail2ban into account, and will return after the default timeout period or take turns with different IP addresses. (I have seen it happen.) Even if you use mandatory RSA certificate authentication, the password attacks will still be logged and will burn I/O, disk space, and CPU cycles.
As for the VPN, you do not need dedicated hardware; it is trivial to configure a VPN in a Linux or FreeBSD server.
If you do not feel comfortable setting one up from scratch, I do recommend a VM with pfSense. for FreeBSD; strongSwan for setting up a VPN in a Linux server.
If your front-end server is Linux, another alternative is port knocking. However due to its inherent working, I only recommend it for domestic settings. As correctly pointed out by @GroundZero, "port knocking is security by obscurity and an attacker can actively monitor your network traffic to discover the knocking sequence."
How To Use Port Knocking to Hide your SSH Daemon from Attackers on Ubuntu
As an additional measure, you can also rate-limit with firewall/iptables rules SYNs in port 22. In this way, you won't rate limit your legitimate connections, and either iptables in linux, or most commercial firewalls allow that configuration. I have seen nasty tricks as bots attacking some daemons as fast as possible before security rules kick-in. However I do believe actually ssh has built-in defenses against that.
To answer you about the rampant scanning, yes indeed. You have a lot of bad actors, zombie networks and malware constantly scanning the IP address space to find servers with compromised versions of sshd, vulnerable/old sshd versions, servers with default/bad passwords/known backdoors, and simply servers with openssh to gain a foothold in a non-privileged user either via brute force or dual pronged attacks via phishing.
After three successful attacks via phishing (in separate events) in my bastion host in my current work, I decided to do a dual ssh configuration in that all users are asked for a RSA certificate in sshd_config, and only the internal network allows password authentication, adding to the end of the configuration file as such:
# sshd configuration allowing only RSA certificates
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/24
PasswordAuthentication yes
As another anecdotal scary tale, before I changed to mandatory RSA certificates, one of the phishing compromises was done in the exact week there were two kernel updates for vulnerabilities that allowed privilege escalation to root, and had I not updated on the spot, I would have been root compromised. (and if my memory does not fail me, it was around the 4th of July... hackers love to save those nasty attacks for holiday times)
As for graphs of actual live attacks real-time, have a look at:
- The graphical interface of the Norse project. It is very educational.
- A map of DDOS attacks.
- A free view of Checkpoint's central security monitoring network, where the agents are their customers.
For finishing the answer:
No, you probably are not compromised in any way.
Yes, you have to take measures to increase your security level. I would advise a VPN tunnel/client from the outside to your corporate VPN server. It is what I am doing actually.
I have also a last and important piece of advice: to make sure a regular account isn't compromised, check your /var/log/auth.log authentication logs for a successful authentication. There are ways of logging into openssh with any account without it being registered in /var/log/wtmp and consequently not appearing in the last command.
It goes without saying that if a regular account is compromised in an old machine without updates, all bets are off. And in the unfortunate case of privilege escalation to root, even the logs can be compromised.