[ubuntu-us-ut] Securing a Linux Server

Charles Curley charlescurley at charlescurley.com
Tue Oct 9 00:31:19 BST 2007


On Mon, Oct 08, 2007 at 04:52:50PM -0600, Daniel wrote:
> I have just been hacked.  I was vulnerable to an ssh brute force
> attack. The hacker got in using a weak username and password.

I wonder how you know this? Perhaps the cracker (not hacker) got in
some other way?

> This has raised the question in my department, "How do you secure a
> Linux box?"
> 
> Here are the requirements:
> publicly viewable via http protocol

I take it you mean your web server is so visible, not your SSH server.

> access to sftp from outside network
>     users would use dreamweaver or cyberduck, or winscp to upload webpages
> I need to get in from outside the network and administrate the server
> No one should be able to get in to the server except through a secure means
> Usernames and passwords should be hard to guess
> No program on the box should be listening except the apache2 server and ssh
> No one, once on the box should be able to find out anything about the
> OS (chmod ug+rw o-rwx /etc/*)

You do not want to deny read access to all files in /etc. Many
programs need to read files there, e.g. bash.

> I need people to trust this box with sensitive data.
> 
> This is just a list of requirements I pulled out of my head.  This is
> just to give an idea of the direction I am headed.
> 
> I need to know what to do with this box and what to do with the
> firewall it is behind or should be behind.  I am compiling a one page
> paper and need input.

To prevent this from happening again:

* Use a port other than the standard SSH port for SSH.

* Do not allow access by password. Instead use public key access. It's
  easier for the user as well as more secure. If password access is
  disallowed, password guessing programs and brute force are
  irrelevant.

* Look into hardening tools like
  Bastille. (http://www.bastille-linux.org/)

* Go buy a top-notch book on systems administration, like Essential
  System Administration, Third Edition by �leen Frisch, O'Reilly,
  2002. Study up on it and refer to it as needed. For SSH, get SSH,
  The Secure Shell: The Definitive Guide, Second Edition By Daniel
  J. Barrett, Robert G. Byrnes, Richard E. Silverman, O'Reilly, 2005.

As for what to do with the current machine:

* Export any databases to plain text files so you can re-install your
  data. Does anyone know of a live CD that would be useful here?

* Back the whole kazoo up so you can recover files as needed from it.

* Scrub the MBR and the whole dang drive.

  dd if=/dev/zero of=/dev/hda bs=1024

  Use a live CD for both of these steps if possible.

* Repartition, lay down new file systems and re-install Linux.

* Generate new user names, passwords, etc. for users and
  databases. Generate new SSH keys.

* Restore data from backups taken before the earliest time you suspect
  the system was cracked. Re-enter more recent data. You do keep
  multiple backups around, don't you?

* If you must restore more recent files, do so one at a time, after
  manually inspecting them for bogus data. The manual inspection
  requirement applies particularly to database contents.

-- 

Charles Curley                  /"\    ASCII Ribbon Campaign
Looking for fine software       \ /    Respect for open standards
and/or writing?                  X     No HTML/RTF in email
http://www.charlescurley.com    / \    No M$ Word docs in email

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-us-ut/attachments/20071008/96fc0453/attachment.pgp 


More information about the ubuntu-us-ut mailing list