Server Hacks

[memymy]

I lease a fully managed dedicated server. I'm am not a Linux administrator. The server has been hacked repeatedly. I have FTP/Telnet access but not root access. I have noticed that many directories are set at chmod 755 (including /)

The server managers seem to have no interested in helping me harden the box. That leaves me 2 choices:

1) Learn to harden the box myself; or,
2) Change server provider

Since I won't have time to figure out how to manage my own box, I am leaning toward changing providers.

With that, I'm trying to determine if I should get another fully managed box, or co-locate a box and hire an administrator. Budget is an issue. Any comments / recommendations?

Thanks!

 

[thedaver]

I can offer consulting services - contact me offlist via my website below.

In a more direct sense, your hosting via a leased/dedicated solution should involve a few key areas of behavior on your part - all of which should require only root access to the machine and no direct intervention on the part of the hosting provider.

1) Get smart on package management for your linux distribution to ensure that you are working through an automated, scheduled and reliable process of keeping your entire system updated to avoid vulnerabilities in your core services and kernel/modules.

2) Shut off everything you do not need to have running. There will be power management daemons and such that are key to supporting the hardware. But take a hard look at fingerd, named, ftpd, telnetd, xinetd, smtpd, and a host of other services that may be on by default but for which you have no need.

3) Get a firewall running on that machine. IPTables provides very strong firewall performance and safety, and there are literally dozens of firewall configuration and maintenance tools to aid you in configuring IPTables for your needs.

4) Use 'tripwire' and scheduled runs of 'chkrootkit'.

5) Remove unnecessary user accounts or set their shell to /bin/false.

6) Use a hardening script for a number of other common default settings that might put your machine at risk.

AFTER DOING ALL OF THIS, you are only as safe as the controls in your Apache/PHP configurations can control.

It's essential to understand that "scripts" (free or purchased) or other code that might be insecure can provide just as much power and opportunity to a system cracker as any acknowledged vulneratibility that you defended against in the first 6 points of this note.

If your web sites/scripts permit the use of SQL injection or priviledge escalation or uploading of file to /tmp or direct use of system shells/calls, any means that a cracker can find to get their code onto your system is sufficient for them to STAY INTERESTED in cracking your machine.

MOST cracking is first initiated by scripted scans of large blocks of IP space looking for a particular vulnerability fingerprint. If the cracker doesn't have interest in your system that's very good for you.

Dave.





D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/