This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


CLI Magic: Trojan Scan

By Joe Barr on October 17, 2005 (8:00:00 AM)

Share    Print    Comments   

We're all about security this week. Not the security you get from being all wrapped up in a baby-blanket, coddling, gratuitous GUI, but the kind that comes from knowing who is connected to your machine, and why. Trojan Scan is a simple but effective tool that monitors connections and alerts you to unauthorized activity of the sort that a rootkit, trojan, or other bad-to-the-bone-ware might engage in. Jump down out of that hi-tech hammock you're in and let's take a look.
Trojan Scan is crafted in the finest Unix tradition, building on and combining existing tools to scratch a particular itch. Most of the work is done by the lsof command, which lists open files. What good is that, you ask, when checking for connections? Remember, in Unix, everything is a file, so the answer is that it's plenty good. Trojan Scan invokes lsof like this:

lsof -Pni

Those options tell lsof to list the actual port numbers and Internet addresses -- not the service names or host names -- of all Internet connections, or files, as lsof sees them. That's the starting point, but Trojan Scan adds a couple of nice wrinkles: verification that your lsof executable has not been hacked, and email notification whenever any connections are found which are not on your approved list.

Installation requires just a little work on your part. First, download the tarball from the Trojan Scan Website. The current version is 1.2.

Create a trojanscan subdirectory and enter it, then decompress the tarball. You'll see a CHANGELOG, LICENSE, and README documentation files, and also the script and the trojan-scan.conf configuration file. As root, copy the script to /usr/sbin -- or another location you prefer in your root PATH -- and create a new subdirectory called /etc/trojan-scan. That's where you'll copy the edited version of the config file once you're done with it.

But before we get to the config, we need to create an MD5 checksum of the existing lsof executable. That's as easy as entering:

md5sum /usr/bin/lsof

On my machine, the command yields this:

1cd5182da58305c4519c02a927984c70 /usr/bin/lsof

With your favorite text editor, open trojan-scan.conf and replace the zeros in the following line with the actual MD5 checksum:

#       LSOF_MD5        - MD5 checksum of lsof program for integrity checking

And while you're still in the config file, insert the user name you want notifications to go to when trojan-scan finds something amiss. Put the user name in the line beginning with RECIPIENTS. I left mine with the default value, so it looks like this:


Now we're ready to test. We're not finished, mind you, we still have to add and prune entries from the ALLOWED lines in the config file, but we have gone far enough to give it a whirl, so copy the config file into the /etc/trojan-scan directory you created earlier, and enter the following at the command line:

/usr/local/sbin/ -n

The -n argument tells Trojan Scan not to actually send an email. Here's the report I got from Trojan Scan on the console, you should get something similar if you've installed it correctly:

The following (probable) trojans where found:

============================================================================== UNKNOWN: /opt/gnome/bin/evolution-2.2 (evolution:37275:warthawg) ------------------------------------------------------------------------------ ls: -rwxr-xr-x 1 root root 149292 2005-09-13 09:34 /opt/gnome/bin/evolution-2 .2* ps: warthawg 24437 1 0 09:10 ? 00:00:23 evolution-2.2

============================================================================== UNKNOWN: /opt/gnome/bin/xchat (xchat:58388:warthawg) ------------------------------------------------------------------------------ ls: -rwxr-xr-x 1 root root 431368 2005-03-23 09:38 /opt/gnome/bin/xchat* ps: warthawg 21652 1 0 07:10 ? 00:00:06 xchat

-- This email was automagically generated on at Fri Oct 14 10:17:41 CDT 2005 by 1.2

Since both the "trojans" reported are actually valid connections, the next step is to add them to the config file. Those two would look like this:

ALLOWED="$ALLOWED evolution:37274:warthawg" ALLOWED="$ALLOWED xchat:58388:warthawg"

Notice that Trojan Scan provided the opportunity to copy and paste the process, port, and user -- formatted exactly as needed in the config file -- on each of the UNKNOWN lines in the report.

With that final bit of tweaking to the config file done, all that's left is to create a cron job to run Trojan Scan as often as you like. I'm down with the suggested very 5 minutes, so I entered this:

*/5 * * * * /usr/local/sbin/ -F

in /etc/crontab. Note that there are other runtime options for Trojan Scan given in the README, so you might want to experiment with what works best for you.

A little bit precaution goes a long way towards maintaining a secure environment. The sleazy virus protection industry is never going to get rich off Linux -- in spite of their howls of protest -- but that doesn't mean Linux is immune from or invulnerable to other types of attacks.

Share    Print    Comments   


on CLI Magic: Trojan Scan

Note: Comments are owned by the poster. We are not responsible for their content.

hash stored in file

Posted by: Anonymous Coward on October 17, 2005 10:03 PM
If a trojan could replace lsof, why couldn't it modify trojanscan.conf to have the MD5 of the hacked lsof? Or just modify trojanscan? Is the idea that intruders won't expect trojanscan to be there (security through obscurity)?


Good point

Posted by: Anonymous Coward on October 17, 2005 10:47 PM
Good point, you could always run it from a CD though...

Article author needs to close the CODE tag.



Posted by: Anonymous Coward on October 18, 2005 01:20 AM
An intruder could still change the crontab not to run it.

If someone has root on your machine, software solutions like this only work if the intruder doesn't know about them. Bad bet.



Posted by: Joe Barr on October 18, 2005 02:40 AM

Simply renaming the app takes care of someone looking for a particular security tool.


Re:Good point

Posted by: Joe Barr on October 17, 2005 11:02 PM

Thanks, got it.


Re:hash stored in file

Posted by: Anonymous Coward on October 18, 2005 09:53 AM
What about making the trojan-scan shell-script read-only? Though, as somebody has already said (though not in these terms), if someon has hacked root access to your box,then you're already hosed. Later,

                      -David Chipman


Re:hash stored in file

Posted by: Anonymous Coward on October 18, 2005 10:13 PM
Well, it should already be read-only for non-root. And if the cracker has root, they can chmod u+w.<nobr> <wbr></nobr>;-)



Posted by: Anonymous Coward on October 19, 2005 07:26 AM
perhaps a coral cache link to the homepage. all ive gotten is 503 errors since the article was posted.



Posted by: Joe Barr on October 19, 2005 08:33 AM

Maybe the story put too much demand on the Trojan Scan site's server. It seems to be fine now, however, no 503 for me.



Posted by: Anonymous Coward on October 20, 2005 01:46 AM
then evidentally he just doesnt like comcast users.



Posted by: Administrator on October 18, 2005 04:30 AM
Yes, or even storing them on a CD, as someone else suggested.

It's still likely a useful program for at least certain types of attacks. It's no cure-all solution, but anyone looking for such a thing likely doesn't even know enough about security to know not to open those pictures of Angelina Jolie in that zip that came with that email.


fedora 4 and new applications

Posted by: Administrator on October 19, 2005 01:21 AM
lsof is included in<nobr> <wbr></nobr>/usr/sbin/lsof. Being a dial up user I ran the command and I appear ok.

One thing about fedora is selinux and I am still struggling to understand how to add and secure new applications using selinux. I have read through the red hat available documentation and can read the audit messages but dont feel confident yet about updating selinux yet.

I would really like to see some very simple tutorials oriented to fedora on this topic.


Too early...

Posted by: Administrator on October 19, 2005 06:31 PM
Just a quick note from the author of this tool:
Please remember the tool is still in alpha, I need to improve the tool since it will generate a lot of false positives. I was thinking about defining separate inbound and outbound rules, that would allow one to setup a rule for e.g. Apache to allow DNS lookups (currently this is not really possible).
Suggestions are welcome.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya