TCLUG Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [TCLUG:12807] bad day (more details)



This begs the age-old equation:

Security = 1/Convenience

That said, it is possible for you to architect your network to meet the
needs of your users while maintaining a level of reasonable security.
Careful monitoring, access control and strong user authentication
practices can be used to enable this type of access.  

Of course, all of this depends on whatever you determine to be your
"security policy" for your network and the available resources you have to
carry that policy out.

* You can harden network access with ipchains, ipfwadm or iptables.  
* You can limit and monitor remote access with tcp_wrappers, xinetd, etc.
* You can monitor machine access, intrusion attempts or successes with
  tripwire, NFR, cops, portsentry, even RPM.
* You can enforce decent password practice / maintenance with shadow and
  PAM.
* You can test your vulnerabilities with NESSUS or SATAN or nmap.
* You can limit the exposeure by dispersing network services to multiple
  machines or a to a DMZ.
* You can subscribe to chatty security mailing lists to stay up-to-date on
  the latest attack trends.
* You can make a daily/weekly visit to your vendor to stay current with
  security patches, updates and bugfixes.
* You can reduce the impact an intrusion success has on your network by
  reducing the trust in the machines, and by keeping hot standbys.
* You can almost always rely on the experiences or advice of other members
  in your LUG. :-)

Most of the above can be managed by a single "coffeed-up" sysadmin with
some automation practices.

Peter Lukas

On Mon, 24 Jan 2000, Timothy Wilson wrote:

> On Mon, 24 Jan 2000, Eric Hillman wrote:
> 
> > On the other hand, from the way your system was trashed, I doubt this was
> > the work of a competent individual...  Not that that's probably any
> > consolation.
> 
> I've looked at the logs, and the only host I don't recognize is
> chmls10.mediaone.net (24.128.1.118). Every other mention of an external
> host in the logs were from me or some other domainname that I recognize
> and can reasonable assume to be innocent.
> 
> > However, in case it hasn't been mentioned already, don't, don't, DON'T try
> > to repair the damage on this server.  The only way you'll be sure your
> > unwelcome guest hasn't left behind some trapdoor into the system is to
> > totally wipe the hard drive and start over (backups of non-system files may
> > be OK, like your website, or the contents of your FTP site, but you'll want
> > to make *very* sure those haven't been tampered with either).  Or, if you
> > prefer, get a new set of drives and keep the old ones as evidence.  Changing
> > the passwords is *not* enough.  Even restoring from backup may not work if
> > the backup was taken after the system was first entered.
> 
> I wouldn't dream of trying to repair it, but I do have to restore my
> users' data. That's on a tape that was made a couple weeks ago. It seems
> my only alternative is to restore those files. Of course, everything else
> will be replaced from scratch.
> 
> I was actually in the middle of planning to change some things around to
> reduce my vulnerability to this. I have an old DEC server that I'd been
> using as a print server. I've been planning to move things like DNS and
> DHCP to it for awhile.
> 
> But let's say I go all the way and completely separate services so that
> internal ones (DHCP, print, DNS, etc.) are completely separate from
> external (ftp, http). Wouldn't that make it impossible to access my files
> on the fileserver from home? That's something that I do now rather
> frequently and is a great benefit to me and the rest of the users on the
> network. Is it a security/utility tradeoff here?
> 
> -Tim
> 
> --
> Tim Wilson        | Visit Sibley online:         | Check out:
> Henry Sibley H.S. | http://www.isd197.k12.mn.us/ | http://www.zope.org/
> W. St. Paul, MN   |                              | http://slashdot.org/
> wilson@visi.com   |   <dtml-var pithy_quote>     | http://linux.com/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tclug-list-unsubscribe@mn-linux.org
> For additional commands, e-mail: tclug-list-help@mn-linux.org
> 
>