SELinux threads, cynicism, one-upmanship, etc.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Friday 18 November 2005 21:59, Les Mikesell wrote:
> On Fri, 2005-11-18 at 20:30, Lamar Owen wrote:
> > What is the most critical injury on academic networks today?  Think about
> > it a while, as it's not what you think; but rooting a box has a lot to do
> > with it, and it's on the inside network typically.

> Unless its different than every other network, it's windows boxes
> loaded with spyware and spam-sending zombies.

Yes, this is correct.  What are the lessons a Linux admin can learn from the 
Windows malware scourges, some of which don't require you to be running as an 
administrator-equivalent?

If anything, the spyware/zombie scourge should be the driving force behind 
SELinux adoption to prevent the same thing from happening to the Linux boxes 
(a well-place root hole and a linux-aware Windows spyware/worm, and your 
Linux box is owned from the inside).  Is it too far of a leap to want to nip 
the coming scourge in the bud?  Linux boxes are not immune as long as root 
holes exist that can leverage root's superuser powers, unfettered by role 
based and mandatory access controls.  If there is no superuser in the 
traditional sense, the root hole is useless.  Completely useless.

Firewalls are of no use, either.  All it takes is a root hole in a program 
that is visible to the inside network with all the spyware laden Windows 
boxes (samba or cups, perhaps); rootkit the apache httpd installation with a 
fragrouting daemon which uses IP over HTTP tunneling (or a rootkitted bind 
and IP over DNS tunneling) and you are owned, ready to become another zombie, 
but this time from your server.  With the typical wide-open outbound firewall 
rules, you're even ready to become a DDoS zombie.

You might think I'm paranoid; the black hats are indeed this devious and are 
indeed using devices like this today.  If SELinux can help plug a few cracks, 
then it's worth learning and using.

I have had the experience of having a box get a rootkit; it is not a pleasant 
experience, and taught me a valuable lesson.  Yes, the box had a firewall in 
front of it.  No, it didn't help.  While it was back in 1998, it is a lesson 
I will never forget.

The investigators who contacted me afterwards told me that this particular 
incident involved over 20,000 hosts, all compromised in the space of 14 
hours.  Scripted, using a BIND root hole.  Hit my public DNS server; used 
carefully crafted packets on TCP port 53 for remote root shell.  Happened 
before the patch was available for BIND.  Happened before chrooted BIND was 
commonly available.  The first file they transferred out was /etc/shadow.  

The only common advice used today that would have thwarted that exploit was 
running BIND chrooted.  It was a necessary service, and only necessary 
services were running.  Patches were up to date; it was exploited prior to 
the vulnerability being publicly disclosed.  Firewall was in place; hit on 
and used port 53 for all communication.  Did not require a reboot.  Rootkit 
installed replaced many (but not all) system utilities and covered tracks in 
the system logs.  SELinux would have thwarted the vulnerability as surely as 
chroot would.

I found the rootkit by simple visual inspection about 25 minutes after the 
hack; I had just come to work, and had hit the SHIFT key to deactivate the 
console screen saver.  On that virtual console, I always left an instance of 
'top' running; the display was customized to show the data I was interested 
in.  I caught the rootkit because the rootkit version of top didn't honor my 
customizations. 

I was alerted by CERT of the hack two weeks later.  They had traced the ftp 
transfer of the rootkit from a known compromised server to mine.  I replied 
that I had already contained the problem, and had rebuilt the server from 
distribution media, and had upgraded the version of BIND.  This was when I 
found out the extent of the attack.

I have had the 'rare' exploit used against my servers; everything that helps 
security without being too cumbersome is a big win in my book.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux