Hackers uncork experimental Linux-targeting malware Hackers have unleashed a new malware strain that targets Linux-based systems. The Linux/Shishiga malware uses four different protocols (SSH, Telnet, HTTP and BitTorrent) and Lua scripts for modularity, according to an analysis of the nasty by security researchers at ESET. Shishiga relies on the use of weak, default …
Whenever cheap embedded IOT crap is driven by OS of choice, or is installed by users who don't know they are setting a popular password, OS of choice becomes botware. Yesterday Microsoft, today Linux, tomorrow who knows ? It's not the OS so much as it's the attitude and security nous of the embedder, vendor, repackager or installer.
yes, but the default sshd.conf for FreeBSD disallows root logins. OK I think most Linux distros do that too, nowadays...
also another plus for FreeBSD is that a non-wheel user cannot su to root. You have to su to a wheel-group user (GID 0) and THEN you can su to root. One more layer to frustrate system-crackers that want to pwn you.
/me typically allows only specific cryptically named "guest level" users with very strong passwords to ssh in from "teh intarwebs" and 'fail2ban' is always on for the dictionary attackers.
This post has been deleted by its author
How did you know mine? Is it in the list of passwords?
That reminds me of a true story. Some years back, I worked for a large company, and it was decided to run password cracking tools against all 20,000 or so users accounts.
Any user who had been compromised was sent a warning email explaining the situation, and that their accounts would be locked in X days if not remedied.
As you can imagine, we had many email responses and call logged. The one that stands out read:
"How do you know my password is "6inches"? - Have you, or any of your staff, ever slept with me?"
(It turned out he had moved department and site a few years prior, and his old account was still active, using the actual guessed weak password and email forwarding.)
This post has been deleted by its author
@Alistair, don't think you get the j0ke ... their advice is simply stup1d, why credentials ? Why telnet????????????????????????????
Eset advises that to prevent your devices from being infected by Shishiga and similar worms, you should not use default Telnet and SSH credentials. ®
Now you know that you can ignore any and all advice from Eset ...
Hans1 advises that to prevent your devices from being infected by Shishiga and similar worms, you should use certificate authentication, implement solutions such as fail2ban, slow queues, and/or knocking harder. Don't use insecure services such as telnet, ever!
http://bsdly.blogspot.fr/2017/04/forcing-password-gropers-through.html
These solutions are better than fail2ban, imho, could be used in combination with fail2ban if you really wanna use that as well ...
The main blog discusses using slow queues for miscreants, with OpenBSD examples ... then you have a comment on there from Pete for knocking harder, Linux implementation ... interesting read, I think ...
"you should not use default Telnet and SSH credentials." Lol well nooo duh. I agree with many other comments, SSH without RSA keys is unsafe. SSH should be configured to not accept connections without keys and a connection attempt limit imposed either with fail2ban or firewall rules
The one thing you failed to mention...
1) Disallow root to ssh.
2) Only allow a limited set of users to ssh and make sure none of them are system accounts.
3) Increase the fail2ban jail time by a factor of 10 or 100
Even with fail2ban running, I see a lot of attack attempts. The next step is to start banning net blocks from countries where you know you're not going to have traffic to or from.
Even with fail2ban running, I see a lot of attack attempts.
I briefly saw that the message below yours references this (after I'd clicked reply before the post page loaded).
I used to get up to hundreds of attacks an hour on SSH. I moved it away from the default port. Now I am lucky to see 5 attacks a day on SSH.
I see a number of tries on other services. No services there, or fail2ban/denyhosts take care of those. IIRC 5 hour ban time for fail2ban (instead of the default few minutes), and only 3 attempts.
But going away from the standard port actually makes a huge difference.
Ah yes, moving to a non-default port makes a hell of a difference.
And before anyone makes the comment, it's not security-by-obscurity, as all the other protections are still in place - but it means the attack attempt logs are a lot smaller. (which in itself could be considered a security benefit)
Just make sure that you are running sshd on a privileged port (either a port < 1024, or, on systems that allow it, a port specifically marked privileged by configured policy)
Even with fail2ban running, I see a lot of attack attempts. The next step is to start banning net blocks from countries
Indeed - I have one gateway server that allows ssh (and, as you say, disallows user login if not using a cert), doesn't allow root, uses fail2ban, still gets hundreds and hundreds of probes.
I blocked Russia, China & various other far-East countries at the firewall and the number of attacks dropped by 60%. If only I could block the US, I'd be able to block another 30%..
Serious Question:
Is there a site that lists the common/complete set of "Built in Passwords"?
I studiously avoid "password", "12345678" etc. however my carefully crafted but memorable passwords may not be as obscure as I think they are. Where can I check?
Please don't ask me to send them to you so that you can check them for me, no matter how many dollars are awaiting me in Nigeria.
Since there are no Linux distros that ship with default credentials. It is intended to hit stuff like wireless routers, CCTV cameras, and various IoT junk that often comes from the OEM with a simple default like 'admin/admin' or whatever. This malware will not affect a PC you installed Linux on.
Such an attack would work equally well no matter what OS it was running, if all it needs is an open telnet/SSH/HTTP with a known default login/password pair. Once it logs in it still needs to use some sort of exploit to do something bad, but since few upgrade the firmware on these embedded devices, the list only grows longer as the firmware gets more out of date...
"Since there are no Linux distros that ship with default credentials."
Embedded distros (including those for the Raspberry Pi) often do. The nature of these devices is that the device ships with a pre-built image rather than as an installation disk that requires a password to be entered at install time. In these situation of best practice should be to require the user to enter a password at first boot and again after a factory reset.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
