Slashdot Mirror

OS doesn't matter if someone wants to target it. In fact it can even be good thing - it's a lot easier to rootkit and hide in Linux based systems than Windows, and most people don't know how to get rid of them too. Hell, in Linux a simple rootkit can work just by editing the system commands like ls.

Then use http://www.chkrootkit.org/

Oh, and apparently it is GPL software, too. http://www.net-security.org/software.php?id=210

i wouldn't be surprised to find that linux actually outnumbers windows quite considerably

WOW. Live in your own little make believe world do you?

Supercomputers - 80-90% running linux is still high, but seriously, it's easier to grab computing cycles from many desktop computers, turning them into a "supercomputer" with more computing power than all the top500 supercomputers combined than trying to infect one and keep it infected while you steal all those cpu cycles.
Linux servers get hacked all the time, but you would know that if you actually ran one. See: http://www.chkrootkit.org/
Phones get malware: http://mobile.slashdot.org/story/11/03/06/202208/Google-Finally-Uses-Remote-Kill-Switch-On-Malware?from=rss
Embedded Linux: Nope, not safe here either: http://www.mcafee.com/threat-intelligence/malware/default.aspx?id=154392

Ahem. Rootkit. It's not called that because Windows got 'em first.

Heck, there are even tools that deal with *NIX rootkits and the like. Several of them, in fact.

http://www.chkrootkit.org/

Except that Linux and Mac users aren't immune to viruses, they just aren't the big target. {...} As those OS's {...} gain position in large targets (corporate servers), they too will become larger targets.

Given the huge proportion of *servers* already running some flavour of Unix or another, POSIX-compatible environment *are indeed* a pretty juicy target for evil-doers since a long time.
Even more so because they are *servers* (thus run mostly unattended, are connected to the interweb with a "phat pipe", and might contain a lot more interesting private data).

And indeed there are efforts to attack machines running Linux and other unices. Lots of efforts.

The only problem is that the standard way unix-like OSes are organised makes them much more difficult to attack.
- For one nobody runs everything as root, unlike Windows where 99.99% of the machines only have 1 single "administrator" account.
- Files aren't executable by default, but require further step to be validated as such (except for the recent exploit of shortcut formats featured on /.)
- The unix-like world is much more diverse than the Windows world. People are complaining of the byzantine complexity of Vista flavours. But technically, under the hood they are the same beast, with a different set of limitations put on by the marketing department. The same exploit would work against any of them. Whereas, in the OSS world only, you have countless different distributions of Linux (*several* of which are widespread) and multiple versions in the *BSD family. Next to that you have also big variations in the commercial unices. You can't just have "one kernel exploit to rule them all".
- And in addition to that, most of the users happen to be a lot more technically educated (although *that* is something that can get diluted once Linux gets popular).

Thus to be able to gain access to juicy bits requires much more complicated and contrived means, in a territory which offers a lot less exploitable bits.

A widespread virus outbreak on windows is something really simple and sometime entirely automatic, like Code Red.
Pwning a unix machine often requires a multi-staged approach and is most of the time something done by hand, trying to adapt the steps to the peculiar combination of factors found on the target.

In fact, if you are working in a secure environment, *every machine* must have antivirus software installed, if it's available for the OS.

Well, someone has still to be able to detect and notify which of the other bozos has an infected machine.

Most of the servers at your ISP will probably run Linux or some other unix-like OS. Nonetheless these machine will have at least one antivirus software (and sometimes several) in order to be able to stop infected e-mails, or be able to detect if you start to send contamined mails.

Norton AV for Mac. {...} McAfee offers Linux/Solaris as well as Windows too.

Well, if you want to give example of AV running on Linux, then you should have kept with the opensource spirit and also cited ClamAV which is quite widespread on email servers, has a very fast response time in case of new threat (and also a couple of handy plug-ins for desktop use).
And is entirely free and open-source.

In addition to detecting viruses (mostly other OS'), a proper shielding of an unix box should also comprise good root-kit detection softwares, such as rkhunter and chkrootkit.

there are rootkit detectors, like http://www.chkrootkit.org/ which is in the synaptic's database, but not the adept one, because the adept installer is still beta quality. at least syanptic is in the adept db because it would be a pain to get software in linux if i had to use adept from kde4... *cough* i was forced to go kubuntu 6.10 beta by the 8.04.1 patch that hosed my x.org config.

as far as credit card theft goes, there are some major issues now, because for 2 some years, 'debian' and thus ubuntu, had a nasty flaw in the 'secure' connection software, so bad they made a wireshark plug in that lets you decrypt secure transmission to any affected debian/ubuntu system. the flaw is patched in debian an ubuntu, but there are still could be compromised servers running on the net. especially if a server wasn't hardened but was feature frozen based on the effected versions. if the company that had the servers set up as a one time deal, they might not even know they're affected.

In addition to the other tools mentionned by /.ers, there are 2 root-kit checking tools that are worth mentioning :
- chkrootkit
- rkhunter

They are scripts that scan the system for known root kits, weird behaviours and hidden files in unusual places.
They can both be used to scan an offline system (booted from a live-cd and the system mounted under some directory),
and a live online system (they check the system for suspicious behaviour that may reveal a root-kit trying to hide it self - for example the "ps" command doesn't show the same processes as the "/proc" directory could mean a root-kitted "ps").

They are available in a lot of distributions (Debian Etch has them in the repository - probably the corresponding Ubuntu has them too) and the packages usually come with "cron" entries that can automatically scan the system and email a report to the administrator.
They are also downloadable and installable from their websites and feature configuration files that cover the most frequent distributions.

You should install them, run some initially check, (eventually edit the script to remove some false positive, i.e.: hidden files about which the script complains but which are normal part of the system), and add crontab entries to do daily checks and e-mail you positive results.
This will help you against having your server rootkited.

-----------------------

Another tool worth mentioning is ClamAV.
That's an open-source signature-based virus scanner, whose maker have been praised for their very fast response time in case of new emerging threats.
You could set it up to periodically check files in the directories that are served. (/srv/www, /srv/ftp, etc.)
The scanner is not very fast, but supports some specialized-hardware acceleration (it might be worth considering it if the server is rather important, and gets significant mail-traffic too). Some teams are also working on GPGPU hardware acceleration (mentioned in nVidia's book "CPUGems 3").

This will help you get some protection against website that you're hosting that may have been hacked into (with bugs in PHP pages, for exemple) and are now serving malwares.

-----------------------

Because the way malware evolve, you may have to upgrade the above softwares to later versions than those shipped with your OS.
Some distribution propose it in their security updates.
For Debian, keep in mind that this kind of "later version requirement" packages go in the "volatile" repository and not the "security" one, modify your sources accordingly.
("security" : we keep the exact same version for stability reasons and only patch critical errors.
"volatile" : for security reasons, some packages (mostly various scan engines) may require updating to a later versions.
"volatile-sloppy" : warning, the packages are really different. b0rkage of config files may ensure (mostly software like gaim/pidgin).

This is a page with a top 100 of various security tools which may also inspire you (for example they mention a webserver scanner called Nikto).

Also, always keep in mind that a compromised machine is not a machine that you can trust. Thus in addition to creating new entries in you crontab, you should also test your machine offline as part of the security checks.
For example, occasionnaly, when you have to take your server offline for planned updates (rebooting to newer kernel version or non hot-plugable hardware upgrades) you may want to scan your system while booting on a LiveCD in case the root-kit are efficient enough to go undetected once they are active.
(That is, if the conditions allow you to perform such a scan : the machine is physically accessible, you can plan in the

I'm not sure why it hasn't been mentioned already, but an astute admin would be running and checking the output of chkrootkit in a cron job.

Probably because the article was talking about Windows rootkit detectors, might be a good reason that you didn't see ones for OSX (I could see through your thinly-veiled attempt at a windows vs mac dig, but I'll play along). For OSX you might try http://www.chkrootkit.org/ as there are OSX rootkits in the wild, they've had a version out for quite some time now.

apt-get install chkrootkit rkhunter

and there are no "automatic" tools to sweep it clean

A quick ps auwx will show me if there are evil deeds afoot.

Unless, of course, you've been rooted. It's very common for rootkits to copy hacked versions of ps, ls and other system tools that hide themselves.

A couple of years ago, I got a little behind on upgrading ssh on one of our servers. It got a rootkit installed, and ps did not show anything. It was discovered when the system rebooted (so we caught it RIGHT AWAY).

chkrootkit is your friend in the Linux world.

That's funny, I could have sworn there was something called chkrootkit that had its last update 3 days ago, and is shipped with every Linux distro that has ViM (that is, all the ones I know).

• Snort (Network packet sniffer)
  Enough is said about this. Absolutely needed, but useless without intervention. Oinkmaster is nice to use for automatic downloading of new rules.
  
  
• Narc Firewall
  Perl script for iptables/ipchains. Fast and easy to set up, however any decent firewall will do. Narc allows for user-customization/hacking, which is a plus for those who wants to learn ipchains/iptables and do more advanced stuff than a GUI can offer. I like to fiddle with the rules myself for outgoing packets, which very few firewalls supports. It's nice to know your computer is not sending out traffic you don't know what is. By blocking everything outgoing by default, I will catch stuff in the logs and adjust the rules when I know what it is (not recommended while in production).
  
  
• BlockIt (Perl script for reactive firewalling)
  Blocks hosts temporarily and permanently based on SSH-logs, snort-alerts and firewall-logs. Nice and easy to extend even if you don't know perl, but have patience to test alot. The maintainer is cool about accepting patches. Yes, you need a list of hosts to never block, and yes a dedicated cracker can spoof IP addresses to DOS you. However, I'll deal with that when somebody does just that. It depends how important your service is I guess.
  
  
• Samhain (Rootkit and file change detection)
  I set up Samhain to email me of EVERY change in the root filesystem. However, I run Samhain with the silent option just after every upgrade at night. So upgrades are done automatically and silently without alerting me (Debian Stable - Sarge).
  
  
• chkrootkit (Another rootkit checker)
  It's in the Debian-tree. Can't hurt to use more than one checker. This one is less spammy than Samhain and checks for other kinds of signatures in the system.
  
  

CHRootKit.

If you run linux you can use chkrootkit

That is sort of what I figured. Do you know the name of it, and/or if chkrootkit is able to detect it?

Here's a couple of things you could do:

Download and build chkrootkit. This will detect a lot (most?) stealthed kits on Linux systems, and it is always my first port of call when I'm invited in to clean up after a breakin.

Plug in a hub (so all traffic can be seen by multiple machines - a switch ain't as good, unless it has a monitoring port) in front of the machine(s) and run tcpdump or ethereal on another system to watch traffic from the machine. This will let you watch exactly what traffic is happening on those weird ports, or watch outbound SMTP traffic for spammer activity.

We don't put Windows-based systems on the internet, partly for security reasons, and partly because we don't have any Windows specialists, so I can't help for on-the-box detection there, although I would expect a commercial virus scanner should find everything.

...in those attacks, like they have in the numerous Microsoft leaks. Imagine the strife we'd be in if they stole the source to Debian!

But seriously, how shall I put this? ChkRootKit, TripWire, AIDE, FICC, ProSum, Toby, msec, Nessus, LSAT, Saint, LIDS and of course if you want totally proactive, try SELinux, Medusa DS9 or OpenWall. That's hardly an exhaustive list, but it does hit many of the highlights. Boy, youse bin livin in a monoculture too damn long!

This and firefox cookie management enable you to check a box for weird stuff. But it should be pretty hard work to get hostile stuff inplace anyway in a automated way. Chkrootkit should be run from a liveCD of cause ...

slips and provides accurate results and unbiased comments. The reporting on Mi2 seems to be that they did their best to compare Windows and Linux by comparing the best numbers they could find for Windows with anything at all that could be dredged up "against" Linux. The fact is there are only something like two Linux viruses. These aren't serious as long as you are running as root all the time. There are quite a few root kits and worms though, which is what chkrootkit is for.

I think they'd better run chkrootkit just in case...

For admins that'd like a way to check for rootkits I'd recommend looking at chkrootkit. While it's not a 100% reliable method (and there may be restrictions: for instance, compiling it on a compromised remote box from uploaded source isn't secure*), it's good as a quick 'n' dirty check. Worth a look at the links at the bottom of the above site too for more info on rootkits, there're some excellent articles listed.

Also of interest would be Nessus - a vulnerability scanner which uses NMAP and other tools that may identify potential points of ingress on a suspect box.

*In this case you'd be best off running pre-compiled trusted binaries off a read-only source such as a CD, or mounting the suspect drive on another machine - though this depends on whether you can get physical access to the box to do either, or if you have truly awesome datacenter techs that can help!

I've been in a similar situation: contractor (military, no less) wrongly accused, had to leave the site, wasn't sure if I'd have a job, etc...

The advice I can give you is:
1) Cooperate fully. Be honest. Be forthcoming.
2) Deny clearly, forcefully, politely wrongdoing
3) Remind them that the world is full of black hat hackers, some of whom have tremendous skill.
4) Ask them how to clear your name and how you can help achieve that.
5) Remind them of your benefit to the organziation -- acomplishments etc.
6) Tell them you understand this needs a full investigation. Tell them you have confidence in them to gather the evidence that will clear you.
7) Remind them that a false positive might be them next time.

Some advice on your specific question:

1) Do you know what you were doing at that particular time? Where you in a meeting? On the phone? Using another machine? Find proof: coworkers at the same meeting, phone records. Look at file timestamps. If one of the offending timestamps occurs in a period where you can prove you weren't using the computer, you are cleared.

2) Ask for network logs connecting to your machine. If this is a normal PC, there should be any from strange places. If there are, that was the bad guy, not you. If they don't have such logs, point out that keeping logs is critical for clearing the innocent and exposing the criminal.

3) If you are on a Unix box, ask that chkrootkit be run to identify if you've been hacked and had a rootkit installed. Hackers often install rootkits to avoid detection and this program finds them.

I hope they have ckhrootkit run via cron.daily... I'd hate to see what a rooted robot could do.

Oh, and imagine a beowulf cluster of these.

Doesn't help much though if the user has developed something of their own that flies below the radar. Chkrootkit doesn't hurt for a bit of peace of mind.

http://www.chkrootkit.org

Now all we need is for someone to hurry up and port some spyware to the Mac, so this product will have something useful to do.

It is not so funny as it may sound. This is exactly my attitude when I installed Debian stable release few years ago and never minded checking security updates. I laughed at my Windows-using friends every time there was a new worm or virus, telling them that it's not fair that GNU/Linux is not supported by all of this malware, until someone exploited my old bind buffer overflow and installed a kernel level rootkit.

Remember that Darwin, the base of Mac OS X, is based on FreeBSD. chkrootkit, a tool to locally check for signs of a rootkit, is constantly tested on FreeBSD 2.2.x, 3.x and 4.x, not without a reason.

Read the paper Attacking FreeBSD with Kernel Modules: The System Call Approach written by pragmatic/THC on June 1999 to have some idea on how well those issues were understood three and a half years ago. This is only one paper, the first thing about FreeBSD rootkits I just found.

So, of course it's funny what you said, of course your Mac is indeed much more secure than an average Wintel box out there, but it doesn't mean there's no spyware. Your Mac is not a toy, it's a powerful Unix box under the hood, which may mean that it's harder to exploit than Windows box, but it also means that when it's exploited, it's probably easier to write and install spyware there (like a simple kernel module which would intercept read syscall, for example). Never forget about that.

I like this utility. It's pretty handy, although probably not as effective as this database, unless you're running slackware, or another popular, but undatabased distro. :-)

• Australian Mirror (Thanks to Grant Bayley)
  
• German Mirror (Thanks to Tom Fischer)
  
• Polish Mirror (Thanks to Rafal Maszkowski)
  
• US Mirror (Thanks to Aj Effin ReznoR)
  
• US Mirror (Thanks to Tim Lyons)
  
• US Mirror (Thanks to Gareth Bromley)
  
• UK Mirror (Thanks to Gareth Bromley)
  

• Australian Mirror (Thanks to Grant Bayley)
  
• German Mirror (Thanks to Tom Fischer)
  
• Polish Mirror (Thanks to Rafal Maszkowski)
  
• US Mirror (Thanks to Aj Effin ReznoR)
  
• US Mirror (Thanks to Tim Lyons)
  
• US Mirror (Thanks to Gareth Bromley)
  
• UK Mirror (Thanks to Gareth Bromley)
  

• Operating System: Although OpenBSD is generally regarded as the best Freenix in terms of security, GNU/Linux is under more active development, faster, more user friendly and supports far more software packages and types of hardware than OpenBSD (sorry Theo, much respect...). I, along with most of the other admins and users are more familiar with a GNU environment. The distribution we use is Debian. I chose Debian for several reasons: free (libre and gratis), strong package system and reliability. It hasn't let me down. I do prefer Slackware on my personal box, since the -current tree is more stable than Debian's unstable. However, Debian's package system is nicer and provides many things that Slackware lacks (I may abandon Slackware as soon as Debian supports XF4 and kernel 2.4 by default in stable). Debian also keeps up to date on security issues.
• Kernel: We now run a Linux 2.4 kernel. Although most security tools/patches are 2.2 only, the mature (READ: usable) ones have been ported to kernel 2.4. I'm confident that more will follow. 2.2 is dead. We have disabled modules entirely in our kernel to prevent hax0ring and to avoid using modules (does anyone else hate them?). We only have a few drivers enabled. Besides helping performance, this protects against hostile code injection into the kernel. It is possible for a clever coder to inject code into a non-modular kernel, but most rootkits use kernel modules. Not allowing kernel modules and using 2.4, prevents us from using some really cool security tools like LOMAC. However, I found that LOMAC did not play nicely with OpenWall's Secure Linux patch (or cron, or init or getty ...). When Lomac behaves nicer, it will be added (I'd also like to see it as a patch rather than a module). Currently, we are using the GetRewted.net patch which provides lots of security enhancements. We may be adding more secure kernel additions such as the NSA's Security Enhanced Linux. However, at this time, we feel that the current kernel security model is both secure and usable. If you have any neat kernel goodies we might like, tell us.
• Firewall: Note that we are NOT running any sort of real firewall. We feel that the extra kernel overhead of the firewall hurts performance and adds needless complexity to the server. Since we are NOT trusting local (ie: users with shell access) anyway, we feel that a firewall is basically useless since Linux's TCP/IP stack is already fault-tolerant, mature and robust. We augmented the TCP/IP stack with this shell script to limit our vulnerability to DoS attacks. Firewalling services should not be needed if your services are secure (run with minimal priviliges and SECURE by design and condiguration). Eventually we may drop an OpenBSD or Linux 2.4 firewall in front of the server as a measure for restricting local users ability to portscan, DoS and exploit remote hosts.
• Authentication / Login: Remote interactive sessions are only supported over ssh (and we run OpenSSH). Telnet is not allowed. Rhosts authentication is not allowed. I've looked at forcing people to use S/Keys, but it is a real pain in the ass on both ends. We are currently allowing FTP in. When I'm confident that all the users can get a good graphical scp/sftp client for their platform, I'll kill FTP. Since I'm not relying on trusting local users anyway, this is more a security concern for individual users. I'm considering locking some users who don't use their shells out of real shell access.
• Users: I only make accounts for people I know personally. I also monitor user login s and their activity using whowatch and process accounting. I'm suspicious of logins from weird hosts. I also use PAM to set resource limits.
• Monitoring: We watch out for network nastiness with Snort which is an AWESOME IDS. We monitor its logs and other system activity with Psionic's LogCheck. Occasionally, I'll audit the machines for weird ports using nmap and Nessus, both of which are REALLY nice. I'll also routinely verify system integrity using a combination of Tripwire and chkrootkit, on a system booted from a known CLEAN floppy containing the tools.