Re: [linux-security] Re: Checking remote servers

["Michael H. Warfield" <mhw wittsend com>]

Leigh Porter enscribed thusly:

> Scott Venier wrote:

>        If the machine was sitting in front of you, you'd just reboot

> > > it with a boot floppy, and run a known-good version of RPM from the
> > > floppy, but that's not an option when the machine's on the other side
> > > of the country; someone local would have to reboot the machine every
> > > so often, run the verification, and then reboot again.
> > >
> > >       (Hmm... a cracker could modify the shutdown scripts to restore
> > > the original versions of binaries, so the verify would report nothing.
> > > Perhaps even the check from floppy is no guarantee of anything.)

	Hmmm...  Including the shutdown / startup scripts?  Those would
be some of the first things I would check.  If he restores everything
back, then he would cut himself off from running again.  :-)

> > >       Any suggestions?

	What you do really depends on how secure you want that remote system.
You need some form of physical security one way or the other.  Given that,
you can take the extreme approach of building a system image on CD-R and
keeping it in the system.  Boot from the CD-R and validate the system from
CD-R at boot.  Rebuild, log, and/or alarm any anonmolies.  Then also use
periodic programs to validate the running system.  Tripwire does a good
job there.  Liberal use of "append only" and "immutable" flags on all
critical files and logs.  Alarm all "append only" and "immutable" violations
attempts and log them.  Log all events off to another autonomous system
whose sole job is life is to log.

	No loadable modules in the kernel!

	Is any of this 100% fool proof.  No.  It doesn't have to be.  You
should understand more about your system than the person trying to break into
it.  If your preventative measure slow him down enough that he eventually
trips over some of your alarm measures, changes are very good that you will
catch anyone attempting to tamper with the system.  You can layer on enough
security perimeters, check points, auditing, alarms, etc, etc, etc to
make a system a pretty tough nut to crack even if they KNEW what you had
on the system.

> mke2fs /dev/xxxx :(

> Seems like having an OS with a publicly available kernel source could
> be a serious security hazard! Saying that, once they are in then I
> think your basically done, apart from a complete re-install there is
> no way to be completely sure that you have gotten rid of everything.

	Having an OS with a publicly available kernel source is a
security advantage.  When the ping of death appeared, they measured
the Linux patch time in hours.  The author of "teardrop" announced it
to the general world when he saw the fix go into the Linux source
database.  If you don't have publicly available sources, the only ones
with the sources with be stuborn uncooperative manufacturers and the
crackers.  The only way the individual who published the three "getadmin"
Windows NT exploits could have known about those three archane tricks
(one was writing to a peculiar offset off of a global structure) was to
have some sort of sources (not that anyone would admit that).  As soon as
one was fixed, he posted the next.  They were just a little too "peculiar"
in what they exploited.

	Just because YOU, Joe Blow public, doesn't have sources, it doesn't
mean those same sources are not available to the crackers.  Ever take a peek
at some the the hacker/cracker "toolz" CD's.  Don't believe that they don't
have sources to a lot of this stuff...

> Only way to win is not to play (Shut up all the holes so nothing can
> get in!).

> I'll obviously not share our security measures on the list, but the
> more routers and firewalls and knots you tie in the Ethernet cable the
> better, then a simple hole in something that just about anybody with a
> serious presence on the net runs can let the world in!

	Security through obscurity is no security.  I share my security
techniques.  I'm a strong advocate of a layered approach to security
with combinations of firewalls, filtering routers, and host based security
along with detection software mining the gaps between the security
perimeters.  You don't have to divulge IP addresses, host names, or
locations of security perimeters to help others understand good security
techniques.

	BTW...  Anytime someone uses the word "obviously" its not.  Lot's
of security people share techniques and information.  That's how we improve
security.  We learn from each other.

> It is also apparent that many people who run Linux systems do not
> really know much about security or where to keep track of bugs and
> updates which makes Linux a prime target not to mention it's
> popularity!

	To make this statement about Linux and not say it about everyone
is totally bogus.  I'm sorry, but we run into people who have not patched
Solaris, SunOS, AIX, HP/UX, and IRIX systems with patches from years ago.
That DNS problem affected everyone running those versions of bind.  Sun
Microsystems sat on the socket bug that Alan Cox reported to them for over
a year!  We are just finally getting some of these companies conditioned
to NOT bury security problems and hope no one else finds out.  We still
have a long way to go with the end users.  How do you EXPLAIN to these
people that FINGER is a security hole that needs to be plugged!  Even
if they are not using it, people using all walks of UNIX leave it turned
on, just because it's there out of the box.  Most flavors of UNIX (and
Windows, it turns out) are pretty much vulnerable to sequence number
prediction.  That can be great fun if you want to forge stuff (let's
hope the spammers don't figure that trick out).  Or how about ftp bounce
attacks.  Yeah buddy.  That one's a fun one on lots of systems (other than
newer distributions of Linux).  Think those sysadmins rush right out and
patch those systems?  Not.  It's really quite discusting to see some of them
get upset when they get hit by a security scan and all of these violations
show up.  Like a child caught with his hand in the cookie jar, it's the
fault of the scanner that he got his butt in trouble for not keeping his
system up to date.

> Saying that though, if a DNS was behind a firewall that let ONLY DNS
> though and nothing else except from maybe specified IP addresses then
> the chance of being done would be substantially reduced.

	Oh oh...  Someone's forgetting about spoofing...  :-)

> [mod: Not this time. A cracker having root-access (through the DNS
> bug) will not be stopped by a few firewall rules saying only DNS is
> going to go in. Sure having access to "telnet" into the machine is a
> bit more comfortable, but root-access through DNS is good enough to
> subvert the whole machien. --REW]

	Sorry about the rant.  It just raises the hair on the back of my
neck when I hear some "hide it!  hide it!  hide it!" individual complains
that publicly available sources were somehow a security risk.  A security
professional should know better (assuming that's what this person is).

> [mod: Whole article reformatted. -REW]

> --
> Leigh Porter

> -- 
> ----------------------------------------------------------------------
> Please refer to the information about this list as well as general
> information about Linux security at http://www.aoy.com/Linux/Security.
> ----------------------------------------------------------------------
> 
> To unsubscribe:
>   mail -s unsubscribe linux-security-request redhat com < /dev/null

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw WittsEnd com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!