Network Attacks. UFW is Working, but More is Needed.

More attacks on the server. Of course. UFW (UFW -Uncomplicated Firewall) is running, which is a must.

Unfortunately, the logs are still full of assholes trying to break in. Shit like this:

Jun 25 20:16:17 vbox sshd[38237]: Invalid user guest from 91.214.130.248
Jun 25 20:16:17 vbox sshd[38237]: input_userauth_request: invalid user guest [preauth]
Jun 25 20:16:17 vbox sshd[38237]: Received disconnect from 91.214.130.248: 11: Bye Bye [preauth]
Jun 25 20:16:18 vbox sshd[38239]: reverse mapping checking getaddrinfo for host-91.214.130.248.ardinvest.net [91.214.130.2
48] failed - POSSIBLE BREAK-IN ATTEMPT!

and...

Jun 25 21:57:32 vbox sshd[38342]: Received disconnect from 95.39.39.5: 11: disconnected by user [preauth]
Jun 25 22:02:43 vbox sshd[38345]: Received disconnect from 116.31.116.7: 11:  [preauth]
Jun 25 22:09:01 vbox CRON[38349]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 25 22:09:01 vbox CRON[38349]: pam_unix(cron:session): session closed for user root
Jun 25 22:09:51 vbox sshd[38371]: reverse mapping checking getaddrinfo for static.customer-201-116-53-85.uninet-ide.com.mx
[201.116.53.85] failed - POSSIBLE BREAK-IN ATTEMPT!

There is more of course. Time to use another tool to make things a bit easier.

After some research, it appears that fail2ban comes highly recommended.

My amazing web writing skill enables me to simply regurgitate words from the fail2ban website:

"Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs -- too many password failures, seeking for exploits, etc. Generally Fail2Ban is then used to update firewall rules to reject the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email) could also be configured. Out of the box Fail2Ban comes with filters for various services (apache, courier, ssh, etc).

Fail2Ban is able to reduce the rate of incorrect authentications attempts however it cannot eliminate the risk that weak authentication presents. Configure services to use only two factor or public/private authentication mechanisms if you really want to protect services."

Setting it up is easy enough. Plenty of tutorials for numerous Linux/OSS distributions out there. If you need a link, just ask. I will try and find a decent one for you.

I have set findtime to 480 seconds,
maxretry to 3,
and offenders are blocked for 6000 seconds (100 minutes)

So if I understand it correctly, if some prick tries 3 times within 480 seconds, he/she gets banned for 100 minutes.

Let's see how that works after a couple days.

Hello Manjaro

Using Debian, or any one of it's derivatives such as Linux Mint or Ubuntu is fine. Multiple systems let me enjoy some of those, but I felt that I wasn't exploring enough of the Linux goodness out there.

Maybe something different would be educational and more fun.

Ladies and gentlemen, my new friend Manjaro.
Note: Blogger offers me the choice of forcing you to leave my page when you click that link, or open it it in a new window. I dislike both choices. Opening this link in a new tab instead would be nice.

I won't go into details about Manjaro, as there are plenty of reviews and related sites out there. I doubt the world needs another one. The fact that is Arch based is important. The change is a challenge.

I grabbed the a recent Xfce edition only because I have never tried that desktop environment. Manjaro has lots of desktop choices. I could have picked KDE, BspWM, Budgie, Cinnamon, Deepin, Enlightenment, Fluxbox, Gnome, i3, JWM, LXDE, LXQT, MATE, Netbook, Openbox and PekWM.

Since my install, just days ago, they have another offering using JWM (Joe’s Window Manager), it is a lightweight stacking window manager for the X Window System written by Joe Wingbermuehle. Incredibly,the system boots up with less than 111MB of RAM usage. Not too shabby considering how powerful Manjaro is.

For me, I like Manjaro a lot. I was concerned with Xfce, having been used to stuff like KDE and MATE, but I am really digging the lighter interface.

That's it! No lengthy review or any of that. Go try Manjaro.

Tenacious Attackers. Network Exploiters Abound.

Hit already.

No surprise, it's just how much the server is attacked that is surprising to me. This is probably typical to the veterans out there.

Tenacious; adjective: persistent in maintaining, adhering to, or seeking something valued or desired
That sounds about right for our network visitors today. Here are just some examples of the activity so far:

Jun 19 03:09:18 vbox sshd[10716]: Invalid user git from 69.10.58.155
Jun 19 03:09:18 vbox sshd[10716]: input_userauth_request: invalid user git [preauth]
Jun 19 03:09:18 vbox sshd[10716]: error: Received disconnect from 69.10.58.155: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jun 19 03:09:19 vbox sshd[10718]: Address 69.10.58.155 maps to server.peopleshosting.in, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT

This little pick (69.10.58.155) tried over and over again, likely as fast as the script he/she was using dictated. Tries with all sorts of possible users were employed, such as tomcat, unbuntu, ubtn, test, ftpuser, and many more. One interesting attempt was for user PlcmSpIp.

Jun 19 07:58:39 vbox sshd[11341]: Received disconnect from 195.20.3.210: 11: disconnected by user [preauth]

It's a party...

Jun 19 11:01:49 vbox sshd[11540]: Protocol major versions differ for 46.105.123.28: SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u2 vs. SSH-1.5-NmapNSE_1.0

Another dickhead...

Jun 19 12:33:10 vbox sshd[11636]: Invalid user admin from 23.247.97.147
Jun 19 12:33:10 vbox sshd[11636]: input_userauth_request: invalid user admin [preauth]
Jun 19 12:33:10 vbox sshd[11636]: fatal: Read from socket failed: Connection reset by peer [preauth]
Jun 19 12:33:11 vbox sshd[11638]: Address 23.247.97.147 maps to mail6.xdem067.cc, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!

That IP hammered me for quite a while. "POSSIBLE BREAK-IN ATTEMPT!" is server generated. I didn't place it here for effect. :-)

Jun 19 13:43:01 vbox CRON[12111]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 19 13:43:20 vbox sshd[12114]: Connection closed by 71.6.146.185 [preauth]
Jun 19 13:43:20 vbox sshd[12116]: Connection closed by 71.6.146.185 [preauth]

Far too many others to list here. This is just a sample of one day.

Of course none of those IP addresses are anything I typically use. They're all outsiders. sadly, this activity is probably normal for most servers out there.
Is it bad that I am enjoying this? I definitely have to see where this is going, and consider my security options. More to follow.
Feel free to leave a comment and offer suggestions. Should i change the ssh port? Fail2ban? Am I on the right track?

I am Running an Experimental Server

I have an interest in network security. so I set up a dynamic server testing environment.

It is basically an experiment to learn more about how a typical server is approached by outsiders, specifically those with bad intentions. Really, how bad could it be? Will I be attacked?

Absolutely, no doubt about it.

As time progresses I will occasionally share some of the external hacking attempts and door-knocking the server encounters. The server is set up to log practically everything, but since that data will be enormous, it will be far too much to provide as updates here. Frankly, updates containing anything more than a few periodic examples would be a tedious read and snooze fest.

I am a complete amateur in all network security. Besides me researching a lot, experience is needed. This is not a hacking invitation, especially since I won't need to invite prowling network jackasses anyways. I am fairly good at manipulating a server, but am truthfully just learning the security side of it.

I know some of the risks.

My server is virtual, and hosted nowhere near me. It can be wiped and reinstall all fresh and sparkly after a successful attack. But ... it risks being compromised and used to attack others. This a major concern. As a precaution, as soon as I detect that (and I will if need be), the server will go on complete lockdown and reset.

That said, I do have some security and tightening measures in place. I was tempted to run the server naked and see what happens, but expect it wouldn't last long before it got completely fucked by outsiders. Presently there some protections up, and a way for me to securely access the server to check logs and make changes as needed.

Stay tuned. It could be like watching a car wreck.