LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 04-15-2014, 07:21 PM   #1
GVrooman
Member
 
Registered: May 2008
Distribution: Slackware
Posts: 38

Rep: Reputation: 11
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?
 
Old 04-15-2014, 08:39 PM   #2
ga_flyer
LQ Newbie
 
Registered: Apr 2014
Location: Atlanta, GA
Distribution: Slackware
Posts: 4

Rep: Reputation: Disabled
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.
 
2 members found this post helpful.
Old 04-15-2014, 08:40 PM   #3
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,542

Rep: Reputation: Disabled
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.
 
Old 04-15-2014, 08:55 PM   #4
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,653
Blog Entries: 2

Rep: Reputation: 4097Reputation: 4097Reputation: 4097Reputation: 4097Reputation: 4097Reputation: 4097Reputation: 4097Reputation: 4097Reputation: 4097Reputation: 4097Reputation: 4097
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.
 
3 members found this post helpful.
Old 04-15-2014, 08:57 PM   #5
frankbell
Guru
 
Registered: Jan 2006
Location: Virginia, USA
Distribution: Slackware, Mageia, Mint
Posts: 8,261

Rep: Reputation: 1570Reputation: 1570Reputation: 1570Reputation: 1570Reputation: 1570Reputation: 1570Reputation: 1570Reputation: 1570Reputation: 1570Reputation: 1570Reputation: 1570
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
 
1 members found this post helpful.
Old 04-15-2014, 09:31 PM   #6
TommyC7
Member
 
Registered: Mar 2012
Distribution: Slackware, CentOS, OpenBSD, FreeBSD
Posts: 439

Rep: Reputation: Disabled
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.
 
Old 04-17-2014, 01:21 AM   #7
enorbet
Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware 14 is Main OpSys on Main PC, 2ndary are OpenSuSe 13 and SolydK
Posts: 737

Rep: Reputation: 345Reputation: 345Reputation: 345Reputation: 345
Is there even a reason to have Sendmail service on a Desktop box?
 
Old 04-17-2014, 02:13 AM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,814
Blog Entries: 54

Rep: Reputation: 2990Reputation: 2990Reputation: 2990Reputation: 2990Reputation: 2990Reputation: 2990Reputation: 2990Reputation: 2990Reputation: 2990Reputation: 2990Reputation: 2990
Quote:
Originally Posted by TommyC7 View Post
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.
...some of the people there tend to be lured in easily by including words like "cracked", "hacked", "malware", etc, etc in thread titles :-]


Quote:
Originally Posted by TobiSGD View Post
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.
Allowing root and not using pubkey auth and allowing remote root access, exactly! Shame people still have to learn things the hard way.


Quote:
Originally Posted by GVrooman View Post
(..) 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. (..)
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.
 
2 members found this post helpful.
Old 04-17-2014, 09:13 AM   #9
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,808

Rep: Reputation: 234Reputation: 234Reputation: 234
My First Brush With Linux Malware

You should be using shared keys.
 
Old 04-17-2014, 09:27 AM   #10
smallpond
Senior Member
 
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: CentOS 6 (pre-systemd)
Posts: 1,773

Rep: Reputation: 454Reputation: 454Reputation: 454Reputation: 454Reputation: 454
Actually, the real shame is that remote root login is allowed by default.
 
1 members found this post helpful.
Old 04-17-2014, 11:04 AM   #11
BenCollver
Rogue Class
 
Registered: Sep 2006
Location: OR, USA
Distribution: Slackware 14.1
Posts: 164

Rep: Reputation: 57
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.
 
Old 04-17-2014, 11:08 AM   #12
mostlyharmless
Senior Member
 
Registered: Jan 2008
Distribution: Slackware -current (multilib) with kernel 3.16.2
Posts: 1,571
Blog Entries: 13

Rep: Reputation: 182Reputation: 182
Quote:
when I caught my Slackware box trying to download a number of files from dgnfd564sdf.com. A
The interesting question for me here is, what did you notice? How did you catch it?
 
Old 04-19-2014, 12:35 PM   #13
pchristy
Member
 
Registered: Oct 2012
Location: UK
Distribution: Slackware
Posts: 108

Rep: Reputation: Disabled
Quote:
Originally Posted by smallpond View Post
Actually, the real shame is that remote root login is allowed by default.
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
 
Old 04-19-2014, 12:38 PM   #14
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,542

Rep: Reputation: Disabled
It is commented out, so it is NOT allowed by default. I have also checked the 14.1 package.
 
Old 04-19-2014, 12:49 PM   #15
mancha
Member
 
Registered: Aug 2012
Posts: 362

Rep: Reputation: Disabled
Quote:
Originally Posted by metaschima View Post
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

Last edited by mancha; 04-19-2014 at 12:58 PM.
 
5 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
GIMP leaves 'brush droppings' on canvas. William (Dthdealer) Linux - Software 2 10-17-2009 07:13 AM
[SOLVED] May have contracted malware. Yes, malware. Firefox on Ubuntu Fiesty. Seeking a fix drachenchen Linux - Security 22 08-17-2008 02:05 PM
May have contracted malware. Yes, malware. Firefox on Ubuntu Fiesty. Seeking a fix drachenchen Linux - Security 1 06-12-2008 06:10 AM
Krita and duplicate brush The slayer Linux - Software 0 07-09-2006 04:10 AM


All times are GMT -5. The time now is 11:45 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration