Integrate Linux Malware Detection

I

IT_Architect

Verified User
Joined
Feb 27, 2006
Messages
1,094
I've set up scripts that use ClamAV to scan the server daily, and hourly. However, while ClamAV and other AV programs do a good job of catching OS intended malware, most of the time it misses malware in web pages, which serve as an attack platform. This is where LMD fits. It could warn admins early on when we have a bad guy who knows a user's credentials, and where the problem pages are located, before the site gets blacklisted as an attack site.

For more information see:
http://www.rfxn.com/projects/linux-malware-detect/
http://plugins-da.net/info/linux-malware-detect-on-directadmin#.UQ-4GGe4vCk

Edit: BTW, I have not tried this yet.
 
Last edited:
Very cool! People have NO idea if they are hacked or not without running something like this.
 
I doubt DirectAdmin staff could just integrate this into DirectAdmin if it's a product (even a free product) of another company, without permission.

Someone please watch this on their server for a few days or so and then bring it up again in this thread, letting us know about any issues with server load, strange errors, etc.

Thanks.

Jeff
 
Im using this since months, the script check just the diff, so just the first scan will take more time.

No problem, since i did not set the quarantene to on no file are edited but an email arrive to me once he detect something with the list of file and relative command to quarantene (if cant the script fix it) that report.

Regards
 
So in your opinion, would many of us probably benefit from installing it?

Jeff
 
Maybe it would be useful to add a scan to /tmp/ too? Since many may be still running the vanilla php-cli/mod_php.
 
Well if you secure /tmp should not be necessary, but should not be that hard to add to the script too, so, why not.

Yes Jeff, i think should be pretty useful.

Regards
 
nobaloney said:
So in your opinion, would many of us probably benefit from installing it?Jeff
Click to expand...
I'm going to. I've had two instances where someone got too easy on a password and it was cracked. It was quite awhile before anyone detected it. By that time they didn't have clean backups. Fortunately, I could work with them with some old backups and accidentally had a 9-month-old copy of a VM from before I updated to the new PHP. It took some coordination with their web developer to ascertain the last time he was in there so we could check by file dates. There were new files that followed the naming convention of the old files, which made it a bit of a challenge to determine if they belonged there or not. There was one directory where files were generated dynamically. Then I had to work with Google's Webmaster Tools and StopBadware.org to get them cleared. It would have pretty useful to nip those in the bud. Using a script to run ClamAV through the server does a fine job of finding infected E-mails, but I proved it to be ineffective at detecting the web page exploits.
 
Last edited:
That's another thing, updating old scripts... Some fail to realise they need to update, therefore old scripts get found out by scanners, then the clients become bewildered as to why their account is disabled.
 
SeLLeRoNe said:
Well if you secure /tmp should not be necessary, but should not be that hard to add to the script too, so, why not.
Click to expand...
Isn't it common knowledge that perl can still be executed in /tmp/ some other way? (I know changing permissions of the perl binary to 705 prevents this)
 
Peter Laws said:
Isn't it common knowledge that perl can still be executed in /tmp/ some other way? (I know changing permissions of the perl binary to 705 prevents this)
Click to expand...
Not if your /tmp directories are separate partitions set to no-execute.
 
IT_Architect said:
Not if your /tmp directories are separate partitions set to no-execute.
Click to expand...
I believe even with a no-execute /tmp partition you can still execute with this:
Code: 
perl /tmp/badscript.pl
or even
Code: 
perl /tmp/badscript
Jeff
 
Well so just add this line:
Code: 
/usr/local/maldetect/maldet -b -r /tmp/ 2 >> /dev/null 2>&1

Just before last "fi" statement.

Regards
 
nobaloney said:
I believe even with a no-execute /tmp partition you can still execute with this:
Click to expand...
I'm going to have to concede that without even trying it. It's simply a text file that gets fed to an interpreter so it isn't executing. The only thing no execute would stop would be an executable.

Experiences with Maldet and ClamScan:
- Linux Malware Detect (LMD) is a great concept. Their page states that instead of being focused on PC viruses, it's focused on web page exploits, and makes its signatures based on exploits discovered by edge routers, as well as conventional sources. That's perfect! Maildet and it's signatures are designed to find these types of threats. It uses its own scan engine, unless the more efficient ClamAV engine is available, which in my case it is.
- To test I placed pages out there with known exploits and ran maldet. I watched the progress from the event log as recommended. it found newer signatures available, downloaded them, updated them, found ClamAV, and scanned the files. It didn't find any of them. A couple days later, I still couldn't believe it, that there had to be something wrong, so I checked everything over again and repeated the test. Same thing. It didn't find the files. If you look at them with a text editor, they are plain as day, and Google and Bing had no problem finding them. I sent them the malware in their submission area, and never received a response.
- Before I found LMD, I ran across a post where I guy was using some scripts with ClamAV. One of the ClamAV scripts runs clamscan at night and does the entire server, and the other every hour, and only checks the structures I tell it to, and only files that have been modified within the last hour. I modified these scripts to work with FreeBSD and cleaned them up. When I ran the daily one, it found every web malware file I put out there, plus showed me that I had 667 more viruses in e-mail files in e-mail accounts that were connected directly to web site forms on the server, and no viruses in the mailboxes where the traffic comes in through conventional e-mail, alerting me to something else that I didn't know was going on.

Summary: This is not at all how I expected this to play out. Initially, as you can tell by my earlier posts, I was pretty pumped about LMD based on its focus on catching compromised web pages. Afterward I was thinking about running both. Now I'm starting to think that running LMD may just be an "exercise". My post on the LMD forum about what happened was never posted. The newest post is a glowing one from 3 months ago. My submission with examples of what was not caught still comes back 3 days with SMTP delivery errors. (They are encrypted in an attachement with the password in the e-mail.) I think I'll just use my scripts that use clamscan. It found an iframe + javascript exploit on one site that had been around since 2007.
 
Last edited:
To test I placed pages out there with known exploits and ran maldet. I watched the progress from the event log as recommended. it found newer signatures available, downloaded them, updated them, found ClamAV, and scanned the files. It didn't find any of them. A couple days later, I still couldn't believe it, that there had to be something wrong, so I checked everything over again and repeated the test. Same thing. It didn't find the files.
Click to expand...

How did you run maldet? Did you specify -a there?
 
zEitEr said:
OK, I'm not trying to persuade you to use the software. Though it might find not all malware, but it helps a lot to find PHP shells, just before an attacker (hacker) starts to use them actively. If to a miss such a malware we get a spamming account. And yes, they seem to not approve comments, but still I believe they update malware signatures base.
Click to expand...
Perhaps, I'm certainly not the last word on this subject LOL! I do know it missed php and html + javascript on pages on hacked sites on our servers, which I didn't expect, and that ClamAV did find them, which I also didn't expect. The LMD concept is sound. I would have felt better if it had found some of them at least. I'll think about what you said. I'm going to refine ClamAV first because that has an amazing track record with me.

zEitEr said:
How did you run maldet? Did you specify -a there?
Click to expand...
Here's the script:
Code: 
#!/bin/bash

# clear quarantine/session/tmp data every 14 days
/usr/sbin/tmpwatch 336 /usr/local/maldetect/tmp >> /dev/null 2>&1
/usr/sbin/tmpwatch 336 /usr/local/maldetect/sess >> /dev/null 2>&1
/usr/sbin/tmpwatch 336 /usr/local/maldetect/quarantine >> /dev/null 2>&1
/usr/sbin/tmpwatch 336 /usr/local/maldetect/pub/*/ >> /dev/null 2>&1

# check for new release version
/usr/local/maldetect/maldet -d >> /dev/null 2>&1

# check for new definition set
/usr/local/maldetect/maldet -u >> /dev/null 2>&1

# if were running inotify monitoring, send daily hit summary
if [ "$(ps -A --user root -o "comm" | grep inotifywait)" ]; then
        /usr/local/maldetect/maldet --alert-daily >> /dev/null 2>&1
else
	# scan the last 2 days of file changes
	if [ -d "/home/virtual" ] && [ -d "/usr/lib/opcenter" ]; then
		# ensim
	        /usr/local/maldetect/maldet -b -r /home/virtual/?/fst/var/www/html 2 >> /dev/null 2>&1
	        /usr/local/maldetect/maldet -b -r /home/virtual/?/fst/home/?/public_html 2 >> /dev/null 2>&1
	elif [ -d "/etc/psa" ] && [ -d "/var/lib/psa" ]; then
		# psa
		/usr/local/maldetect/maldet -b -r /var/www/vhosts/?/httpdocs 2 >> /dev/null 2>&1
		/usr/local/maldetect/maldet -b -r /var/www/vhosts/?/subdomains/?/httpdocs 2 >> /dev/null 2>&1
       elif [ -d "/usr/local/directadmin" ]; then
                # DirectAdmin
                /usr/local/maldetect/maldet -b -r /var/www/html/?/ 60 >> /dev/null 2>&1
                /usr/local/maldetect/maldet -b -r /home?/?/domains/?/public_html 60 >> /dev/null 2>&1
                /usr/local/maldetect/maldet -b -r /home?/?/domains/?/private_html 60 >> /dev/null 2>&1
	else
		# cpanel, interworx and other standard home/user/public_html setups
	        /usr/local/maldetect/maldet -b -r /home?/?/public_html 2 >> /dev/null 2>&1
	fi

	# scan default apache docroot paths
	if [ -d "/var/www/html" ]; then
		/usr/local/maldetect/maldet -b -r /var/www/html 2
	fi
	if [ -d "/usr/local/apache/htdocs" ]; then
		/usr/local/maldetect/maldet -b -r /usr/local/apache/htdocs 2
	fi
fi
 
From the cron script maldet checks only files modified during the last 2 days. In some cases I'd suggest changing it 7 days, and running at least one full scan weekly. In case a malware was uploaded and mdate was in a deep past or faked you might miss them when scanning with the default settings.
 
zEitEr said:
From the cron script, maldet checks only files modified during the last 2 days.
Click to expand...
Actually, if you check the code, I made it 60 days, and I copied the malware files about without the -p so they had a new creation and modification date just before I scanned.

Thanks!
 
Right you are, I've missed that part of the script. Anyway just to be sure did you ran maldet with -a? Your arguments seem to be correct, but what if -a has a greater impact. Or you could give me an example of malware which maldet missed in your case. Please do not post here any code, just a link if possible.
 
You must log in or register to reply here.
Back
Top