Re: security? ? ?

From: James T. Dennis (jadestar_at_idiom.com)
Date: 07/11/03 

Date: Fri, 11 Jul 2003 01:37:20 -0000

Peter <cmk128@hotmail.com> wrote:
> Hi all
> which linux command can help me to encrypt file? I want to perform
> 128bit encryption.

 Someone suggested GnuPG (gpg). That's sufficient. There are many other
 options but gpg -c (symmetric encryption) is probably the easiest and is
 the best we can suggest until you learn out to be more specific.

> Which website can tell me the security hole of linux? My boss is
> asking me to write a program that detect linux security hole
> automatically...

> from Peter (cmk128@hotmail.com)

 Your boss is an idiot; or is testing to see if you are. Consider
 a system and a set of vulnerabilities (security holes). As soon
 as one writes a way to detect the full set of known vulnerabilities
 then software maintainers fix those holes. Meanwhile other
 programmers and maintainers add new features (and some of the fixes
 have bugs of their own). This gives us a new (unknown) set of
 vulnerabilities. Ergo it is impossible to automatically detect all
 security holes. It is quite likely that we've never found all of them
 at any given time (even before coding new upgrades and features into
 the system).

 Asking for "the security hole of linux" is akin to asking for "the
 winning sequence of moves in chess." If such a thing was known, the
 game would be over.

 Testing for known vulnerabilities can be useful --- even after they've
 been fixed. This can become part of the regresssion suites for each
 package; and can be used as part of the system's administration regression
 testing.

 Now, the easiest way to test for a large number of known network
 vulnerabilities is to run Nessus (http://www.nessus.org/ ). That has
 NASL (Nessus Attack Scripting Language) for coding up new vulnerability
 tests. The NASL Reference PDF on their site is about 45 pages long.

 Another tool you can use is a NIDS (network intrusion detection system)
 Snort (http://www.snort.org/ or http://www.sourcefire.com/ for the
 commercially supported products by Snort's creator, Marty Roesch)

 Normally you'd run the NIDS on a dedicated system with no other service
 installed on it. It acts as a silent sniffer (so it should be on an
 unswitched hub with the machines to be monitored --- or on a diagnostics
 "spanning" port on your switch --- details are on the documentation page at
 the Snort home site under "Deployment Guides").

 You could just use Snort with the many rules (known exploit signatures) that
 are available for download. This will generally tell you that these attacks
 have been attempted (possibly if they've succeeded). However, then we're
 back to the problem of *unknown* exploits again.

 You could also write a custom set of rules. You could describe a set of
 policies for legitimate traffic to and from your web for example. Then
 the ruleset would raise an alert for ANY traffic that didn't comform to
 this policy. Thus a web server might have a policy something like:

        HTTP and HTTPS from anywhere
        Database access just to the MySQL or PostgreSQL server
        SSH traffic just from your internal administrative hosts or gateways
        DNS traffic only from your DNS forwarders
        NTP traffic to/from your NTP peers
        Syslog traffic to our log host
        

 ... thus any FTP to or from the machine, any ssh access from anywhere other
 than our administrator workstations, even a web fetch initiated *from* the
 web server --- any of these would raise alarms. Snort would detect these
 and scream for us.

 Of course you could also implement these policies in your packet filters,
 actually prevent any abberrent traffic. Doing both is fine, to detect
 the failure of your packet filters, if it should occur.

 Doing this doesn't make your box invulnerable. Someone might still
 compromise your administrator workstations, or some router in some way to
 source route or tunnel traffic to look *like* it's coming from and going
 to one of the allowed systems. Similarly any of the other trusted hosts
 could be compromised and your web server could be attacked via the service
 you've trusted. However NTP, SSH, and db attacks can't emanate successfully
 from your DNS forwarders, etc. Each of these other systems can be similarly
 locked down.

 That would leave the HTTP daemon itself as the biggest risk --- it's the
 only thing that allows access from anywhere. Worse you probably have
 large, complex, and probably poorly written CGI and dynamic server side
 code running on your web server. This, of course, is your achilles heel.

 Luckily most run-of-the-mill script kiddies would still get trapped and
 detected by this arrangement. Once they've compromised the web account
 they'll generally attempt to have it fetch a rootkit to the system (a
 suite of tools and scripts to try to elevate their privileges to super
 user -- root; to use those privileges to install a collection of back
 doors, and to help them cover their tracks).

 Some of the better exploit scripts are clever enough to keep their
 traffic (rootkit file transfers and other traffic) tunneled via the same
 port as they successfully slipped in their toes. Some of them might also
 use DNS tunneling (your forwarders would simply forward the tunneled
 DNS responses back to the compromised process unless it was so poorly
 formed as to be automatically detectable. They might use steganographic
 techniques to make this HTTP or DNS traffic look valid to their respective
 protocols.

 So, you want to harden your CGI and other server-side dynamic content to
 reduce the risk of compromising your web account (web server processes)
 there. You want to harden the rest of the system to limit the risk of
 a compromised UID on the system from getting root and/or breaking out of
 you chroot jail or other sandboxing. You want a way to minimize the
 ability of a compromised web user UID or process on the web server to
 attack your database server, DNS forwards and other systems (the trust
 relationships over these protocols should be one way --- non-commutative
 and intransitive --- wherever possible), you want these other daemons
 (server processes) to locked into their own jails wherever possible.
 You want any private data being transmitted into your CGI processes
 to be relayed into more secure storage (like the database) so that *all*
 of your confidential data isn't compromised just because one process has
 been subverted.
 
 And you want a way to detect if your web server has been compromised and
 especially if your web site has been defaced.

 If you had a static index page; a naive approach would be a simple
 script on a nearby system that did a wget and comparison or checksum
 to alert you to a defacement. Of cours a clever attacker might
 deface your page such that *outside* requests got the defaced
 version and internal addresses were given the uncompromised version.
 So you might have to have your checker script running from a system
 outside your domain (perhaps a simple cron job or daemon at a
 random ISP that offers shell accounts, or one of the admins home
 machines, or just a buddy system with some other company). The
 defacement might not be on the "home" (index) page. So you have
 to spot check other pages. But many of your pages are or need to be
 dynamic, not static so maybe you need a way to filter the dynamic
 content out from the templates and validate *those*.

 ARE YOU STARTING TO GET THE FUCKING CLUE, HERE?

 Attack. Parry. Lunch. Dodge. Thrust. Evade. ...

 I could go on like this damn near forever, and I'm not even a security
 professional --- just and armchair dilettante.

 Yes, all of what I described can be effective. If you did all of this
 competantly you'd've locked down your systems better than 98% of the rest
 of the 'net.

 Even then you have a bigger problem. All that I describe here are purely
 technical measures to defend against software exploits and vulnerabilities.
 You also have to address the social engineering and disgruntled insider
 threats. 

-- 
Jim Dennis,
Starshine: Signed, Sealed, Delivered