My First Brush With Linux Malware
 

I never had any trouble with malware in Linux until the other day when I caught my Slackware box trying to download a number of files from dgnfd564sdf.com. A little Google searching revealed that this is a known malware site located in Beijing. Apparently they crack your root password and use ssh to modify your crontab to download the files. I never use ssh for anything so I was a little disconcerted to learn that I had this big security hole that somebody was trying to exploit.

One file that did get downloaded was sfewfesfs which showed up in my /etc directory. When I tried to delete it I discovered that, even as root, I couldn't delete it. Even worse the sticky bit was set. I did a Google search on the file name and discovered a page full of sinister looking crontab entries that somebody had posted on Pastebin.

I had been planning to upgrade the box to Slackware 13.37 anyway so I reformatted the hard drive and installed Slack with a tougher root password. Then, after doing a little reading up on the subject, I configured ssh to ban root logins altogether. Before I did the install I noticed that my computer was spawning a bunch of sendmail jobs that didn't go anywhere because I had my internet connection shutdown. Apparently the whole idea of this thing is to turn your computer into a spambot. Has anyone else had trouble with this?

Immutable bit strikes again
 

The reason that you could not remove the file as root likely was that the hacker set the "immutable" bit on it. This is one of several additional permission bits outside of the normal *nix bits.

To see if the immutable bit is set on "foo" do:

lsattr foo

The "i" below indicates that the immutable bit is set:
----i---------- foo

Turn off the immutable bit as root thusly:

chattr -i foo

Then you can remove the file.


There are other solutions to prevent a brute-force attack against ssh passwords. The best is to use a private key for ssh access. You can generate one with:

ssh-keygen -b 1024 -t dsa [-C comment] -f outputfile

Then a read of "man ssh" shows how to use it.

Alternatively, use a password of at least 12 characters which cannot be guessed. E.g., don't use "root1234", "my favorite sports team", etc.


Using a private key (with a strong passphrase) or a strong password, it is safe to allow root access.

Looks like it is call the BillGates botnet:
https://isc.sans.edu/forums/diary/Un...ditions/17282/

If you don't use a service, turn it off, that's part of basic security.

1. Insecure root password
2. Remote root login allowed
3. SSH server running, though not used
You couldn't make it much easier for those crackers.

You might also take a look at fail2ban. After a configurable number (three is a popular setting) of failed login attempts, it blocks the originating IP address for a configurable amount of time.

I have it on my one public facing machine.

Wikipedia has a nice article about it: https://en.wikipedia.org/wiki/Fail2ban

I think this topic is better suited for the Linux - Security section of LQ.org. The people there will likely know more than us about these things.

Is there even a reason to have Sendmail service on a Desktop box?

...some of the people there tend to be lured in easily by including words like "cracked", "hacked", "malware", etc, etc in thread titles :-]


Allowing root and not using pubkey auth and allowing remote root access, exactly! Shame people still have to learn things the hard way.


Reinstalling the OS was a good choice given evidence elsewhere suggests both script-based as well as manual modifications as root. (Note crontab-based tricks aren't something new, its been around for ages, and depending on purposes may not even require root access. If one is stupid enough to allow say the web server user a crontab then, given a vuln in popular software in the web stack, that may be enough.) Do ensure all passwords are changed (not only root), ensure you implement the advice given, harden your machine basically, and if you have any 'net facing services do ensure you not only have active response (like fail2ban) but also regularly audit the box (say Samhain + Logwatch?) to be able to investigate any anomalies before they become a problem.

My First Brush With Linux Malware
 

You should be using shared keys.

Actually, the real shame is that remote root login is allowed by default.

Regarding fail2ban, I prefer a more proactive approach: Using /etc/hosts.{allow,deny} and/or iptables to restrict who can connect to sshd in the first place. I also disable password authentication and root login. These settings are effective on Slackware. On other systems, it is also necessary to disable PAM, or else PAM will "override" the sshd configuration. Ideally, sshd wouldn't even be listening on the Internet. It would all be done over a VPN instead. This would help guard against undiscovered security bugs and 0-days.

The interesting question for me here is, what did you notice? How did you catch it?

Having just stumbled on this thread, I thought I'd better check this out. Looking at my sshd_config file I find:

#PermitRootLogin yes

which implies (to me!) that the default is not to allow a root login. My system is 14.0 (haven't got around to updating to 14.1 yet!). Am I reading this correctly? And does this mean that at some point between the OPs system and mine, this loophole was closed? I am no security expert!

--
Pete

It is commented out, so it is NOT allowed by default. I have also checked the 14.1 package.

That's unfortunately an incorrect analysis.

@pchristy: I agree with you the line, as written, suggests the default is to not allow root logins. However, the default does
allow them. Sound practice (unless you have special needs and know what you're doing) is to set "PermitRootLogin no" in
/etc/ssh/sshd_config. Maybe Slackware should ship that as default.

--mancha

Mancha: Thanks for clearing that up! For someone who isn't expert in these matters, that line is very misleading. Mine is being amended forthwith!

;)

--
Pete

the standard is to allow root login at install.

This is for the big amount of remote users that actually need ssh to connect to their remote server after it is installed.
After that you should make modification to your system to reject root logins over ssh, etc.

The main problem here is that the OP never uses SSH for anything, but left it installed and running. Maybe allowing root login should not be the default, but then people who actually do use SSH every day would complain.

Debian recently switched to a default of "PermitRootLogin without-password" which allows only key-based root logins.
The change will likely trickle down to Debian derivatives soon.

--mancha

Small thread from 10/2013 discussing the topic of what PermitRootLogin setting to ship in sshd_config:
http://marc.info/?t=138102353700001&r=1&w=3.

It didn't get much upstream play possibly because they might feel this is a decision best suited for the
vendor level (a sentiment I would agree with).

--mancha

If I remember correctly, when installing slackware the ssh service is checked by default. So for a newer user it is quite forgiveable to have the service running but not realise it. I think that given this is the case, a change to default sshd configuration to (say) not permit root logins using passwords, but only public/private keys as seems to have happened in Debian, would be very wise.

Right, thanks for pointing that out. I have fixed that then.

Yesterday I noticed sshd service starting at startup. I was WTF because I remember I disabled it at installation. rc,sshd was executable, so I chmod u-x it. Some dates on files pointed to 31st march, which is way closer than I installed slackware, I know I did not touch them myself.

I went to http://mirrors.slackware.com/slackwa...ches/packages/ and checked maybe some package touched sshd configuration.

I downloaded openssh-6.6p1-i486-2_slack14.1.txz and dived into directory structure with mc. It seems this package ships with an executable attribute of rc.sshd, so my old file got overwritten with this one and executed at start.

Many Slackware installation scripts (install/doinst.sh inside the package, saved to /var/log/scripts/<package> after installation) are careful to preserve the permissions on existing rc scripts. (Often there is a little function named 'preserve_perms'). But, in the case of openssh, the script does not appear to do this. So yes, you are right, the ssh daemon was re-enabled on your system when you applied the recent openssh patch, which is perhaps not ideal. You did the right thing when you changed the permissions again.

You know what, I went and did installpkg openssh-6.6p1-i486-2_slack14.1.txz to see if rc.sshd will become an executable again, and it did not. So I am still confused how it became an executable initially, or I forgot to unselect it at slackware installation. I dont know.

Yes. If you want an email server. :)

It seems this is only missing from the 14.1 openssh patch, the 14.0 patch done on the same date has the correct preserve_perms, as does current. The missing preserve-perms happened probably at 14.1 release as the same problem occurs in the original script for 14.1, but there is no problem in current. I guess I'm glad I always make updates do .new files and then manually go through them.

mancha,
new default will break remote installation of Slackware, because now setup doesn't create regular user and if we skip chroot to /mnt and do not create regular user manually at setup phase, this installation will be unaccessable for first remote login.
As for me, mention this potential security problem in documentation is still enough.

Well, I assume that most desktop users create a regular user just after installation, and doing that in setup doesn't look like a daunting task. Maybe we could offer that possibility in Slint, as Salix does? More or less, that'd be just running adduser.

main problem I see is this was posted on the 14th and the OP has not come back to respond to his own thread. So I usually take it with a grain of salt .

after this long. Or he figured out his fix hit the forum and left.

Isn't Slackware supposed to ship the upstream default configuration in line with OpenSSH documentation? Do we need this sort of distro-based handholding?

This option is configured the same way in the OpenSSH tarball from their website, so actually this is the upstream default.

I don't see why Pat is bound by anything other than his own judgment in terms of what Slackware ships.

As for OpenSSH upstream, they're not prescriptive:

"The default configuration should be instantly usable, though you should review it
to ensure that it matches your security requirements." [emphasis mine]

--mancha

I don't have a server and just use slackware web-surfing, email, and watching amazon prime and hulu plus videos... I try to disable ssh and anything thing else I can for security purposes. I try to be security conscious without being security paranoid... if that makes any sense...

I do the same

I have similar problem. I found out that there is an executable file .SSH2 in the /etc/ folder. Delete it. It probably cause the creation of another executable file .sshdd1401029612 in the /tmp/ directory that cause all the troubles. I checked it using htop. The file is big. The other files sfewfesfs, sfewfesfshgfhddsfew, sdmfdsfhjfe, gfhjrtfyhuf, dsfrefr, ferwfrre were just probably dummy files.

Note deleting files without listing (volatile) details, investigating how it got there and ensuring it can't happen again is bad.


See https://www.linuxquestions.org/quest...1/#post5167596 and https://www.linuxquestions.org/quest...1/#post5169774