Forum OpenACS Q&A: server security...

1: server security...

Posted by David Kuczek on 10/21/03 11:58 PM

I am not sure if it is bad luck or somebody continuously breaks into my server. Well, the first server wouldn't boot at all anymore and the second just went down today.

I am running RH8.0 and old school oacs 3.2.5.

1. What can I do to secure my server to a reasonable extent?

2. How can I check if somebody compromised my server after I get it back up again?

Cheers

David

2: Re: server security... (response to 1)

Posted by Michael Bluett on 10/22/03 01:52 AM

Presumably you have seen the install overview document which includes some security links, having commented on the next page in the install guide. The attack detection section of the admin security guide mentions tripwire, though you probably want something similar rather than a commercial program. Did you want more recent recommendations?

3: Re: server security... (response to 1)

Posted by David Kuczek on 10/22/03 02:16 AM

Hey Micheal,

thanks... I am not really sure if it was some kind of intruder or I just got unlucky with the hardware again.

In my ideal world I would like to have a bullet list of 20 things that I would have to do without much reading (maybe additionally, so that I know what I am securing), which would reasonably secure my server. Ideally for RH8.0 😊

Just wanted to hear what other people *exactly* do with their servers to secure them...

4: Re: server security... (response to 1)

Posted by Patrick Giagnocavo on 10/22/03 03:00 AM

David,

I strongly suggest that you do what you can to figure out whether you were hacked or not.

My suggestions:

1. Disable inetd or xinetd after you have made sure that the latest SSH daemon always starts at boot. If there are other services, such as POP3 or sendmail, that are running on the system, start them at boot time as well.

2. Install AIDE and run it nightly. This is a similar program to tripwire and works the same way. Set up properly, it will detect changes to system files.

3. A rule about accounts, should you need to use FTP, POP3 or any other service that does not encrypt passwords over the network: set the login to be /sbin/nologin or whatever RedHat has set up as the setting for disallowing logins. Accounts that can login to the server should never use insecure protocols like POP3; accounts that use insecure protocols should not be able to login.

4. Install IPF or use ipchains to only allow traffic on the ports you specify, such as 22 (ssh) , 80 (http), 443 (https).

There are many other things you can do as well, such as mounting /var and /home with noexec,nosuid , etc.

Hope this helps!

5: Re: server security... (response to 1)

Posted by russ m on 10/22/03 04:13 AM

General hints: perform as minimal an install of your OS of choice as can possibly get the job done - the more services running on the box the more potential points of attack. Keep up to date with vendor-supplied patches (ie subscribe to the RedHat update service). I assume (or is that "hope") that RedHat provide some kind of "securing your server" documentation - find it, read it, follow it.

A box is never "secure", it is just "up to date and secure enough". New vulnerabilities are continually discovered, and new exploits released. Keeping your system patched is essential, is (depending on your OS) usually pretty easy to do, and doing it would protect you from 7 of 10 most exploited unix vulnerabilities of the last year (according to SANS).

If you haven't been running something like AIDE or Tripwire, it's very difficult to know if your box has been compromised. "Once root, always root". There are rootkits available that load themselves into the kernel and make invisible their files, network activity and processes. The only way to be sure is to boot the server from a known-good system (like a bootable CD) and compare what's on disk to a known-good snapshot of your installed system. The safest approach is to nuke and reinstall the server in question.

6: Re: server security... (response to 1)

Posted by David Kuczek on 10/22/03 05:21 AM

mille gracie...

on the other hand: I had a lot of traffic on a celeron 2000, 512mb etc. machine with ide drives. Is it possible that too much traffic is bringing your server down?

Same question on this: How can I detect that?

7: Re: server security... (response to 1)

Posted by David Kuczek on 10/22/03 05:35 AM

Another question is wether to switch to RH9.0 or stick to 8.0 and follow the security docs from RH:

http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/security-guide/

I would of course follow the 9.0 security docs, but would in general switching be recommended?

8: Re: server security... (response to 1)

Posted by Tom Ayles on 10/22/03 11:14 AM

I haven't set up OpenACS on RH9 yet, but I don't know how much a fully patched RH8 install differs from a fully patched RH9 install. For server apps, maybe not that much. Anyway, if you're interested in a security checklist, I would recommend reading the CERT Unix security checklist. It's not specific to any particular OS, rather Unices in general. I've looked at the RedHat security list which echoes a lot said in the CERT list, but I always like to have multiple sources for this kind of advice. It kind of exceeds the 20 point list you were looking for, but you can probably sleep more easily at night if you apply it!

9: Re: server security... (response to 1)

Posted by David Kuczek on 10/22/03 01:32 PM

Tom,

thanks a lot... looks really good.

I just found out that it was a power failure and it didn't come up automatically. After the sysadmin rebooted the system Postgres apparently didn't start correctly or at least didn't start after AOLserver did. If I do a manual reboot everything works fine though.

#####

This is what I got in the server log:

Error: Ns_PgOpenDb(postgres): Could not connect to localhost::MyServer: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

#####

Obviously there was nothing in /tmp cause it got rebooted. When I started Postgres manually (/etc/rc.d/init.d/postgresql start) it said that it will force a start although another server might already be running and it worked.

Any hints on how Postgres will start properly after a power failure and in the future an automatic start of the server?

####

Another thingie:

I installed nmap and did:

[root@www root]# nmap -sT -O localhost

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1598 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
80/tcp open http
Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20
Uptime 0.169 days (since Wed Oct 22 09:14:53 2003)

Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds

#####

But I actually have webmin running on https on port 8000.

1. Why didn't nmap show port 8000 to be open?

2. Should I rather tunnel webmin through the ssh port? And how do I do this (just heard about it 😉?

Thanks

10: Re: server security... (response to 9)

Posted by Tom Ayles on 10/22/03 02:10 PM

First of all, I don't know a lot about NMap, but judging from the output produced, it hasn't scanned all your ports ('The 1598 ports scanned but not shown below are in state: closed'). I'd say it scanned 1601 ports - probably those corresponding to well-known services (FTP, HTTP,...) and a few extras commonly used for back doors, like the elite ports (somewhere in the 32 thousands, not sure where). As 8000 doesn't really fit into either of these, it probably didn't scan it. No doubt you can make it scan all ports, though there are 65k of them.

If you want to tunnel through SSH, the general incantation is:

ssh -L lport:rhost:rport -N rhost

...where you replace lport with the port you want to use on your local machine, rport with the one you are tunneling to on the remote machine, and rhost with the remote host name. The -N simply specifies that ssh shouldn't execute any command, and so doesn't open a shell on the remote machine as well. Something like ssh -L 8000:hostname:8000 -N hostname would probably do it for you. The tunnel persists for as long as the SSH command is running.You can then point your browser (or whatever) to localhost:8000 to do whatever it is you need to do. The merits of tunneling instead of allowing direct access are that you benefit from the security of SSH, which - despite weaknesses being announced (and fixed) recently - is pretty good.

In general, I'd recommend closing all ports on your machine that aren't essential to its running, which would include 8000 (use tunneling instead) and 25 (unless your machine needs to accept mail from the outside world). If you can put your machine behind a hardware firewall in addition to iptables, that's always a bonus as well.

11: Re: server security... (response to 1)

Posted by russ m on 10/22/03 04:13 PM

by default nmap only scans ports 1 - 1024 (the unix "privileged" ports) and anything listed in it's own services file. To scan *everything*, add the arguments "-p 0-" which tells it to scan ports from zero up to the sky...

12: Re: server security... (response to 1)

Posted by russ m on 10/22/03 04:18 PM

and come to think of it scanning against "localhost" will only show services that are listening on the loopback interface, and miss anything that's specifically bound to a real network interface. To get an accurate view of how the outside world sees your server you should run nmap against it from some other machine.

13: Re: server security... (response to 1)

Posted by Tom Ayles on 10/22/03 04:38 PM

David - a couple of useful commands for you:

netstat -a

That'll list all processes that are bound to ports on your machine, regardless of whether they can be seen from outside (eg, iptables filters that port). This is useful to see which services are running on your machine.

rpm -Va

This will check the integrity of all the RPMs installed on your machine. Even a healthy machine will produce some output, so you'll need to analyse the results manually - refer the rpm man pages for what the output means. MD5 mismatches on binaries are quite a bad thing. I had a server at one stage that was misbehaving - turned out to be due to some kind of filesystem problem - and running this command can tell you what's damaged so you can fix it.

I wouldn't rely on either of these commands to tell if your system's been compromised, as a skilled hacker would probably have trojaned these utilities with a root kit to hide their trails. Regardless, the first is good to see what your running, and the second is useful if you suspect accidental system corruption.

14: Re: server security... (response to 1)

Posted by Mark Aufflick on 10/22/03 04:50 PM

i know this is not as easy for some installations as it sounds, but i use a firewall.

A bottom end sonicwall firewall will do (www.sonicwall.com) like the Tele3, and just open up what you want. it even detects smtp and other dos attacks and denies them (and alerts you) etc.

as a bonus you can use it's vpn capabilities to admin your box and not even open yourself to ssh vulnerabilities! (comes with a windows client, but it's just IPSec - i'm sure a linux box can connect to this somehow - but i haven't tried yet). or install a sonicwall firewall in your office and make a semi-permnanent vpn link.

of course there are other options in the same and different price ranges - it's just what i use.

15: Re: server security... (response to 9)

Posted by Randy O'Meara on 10/23/03 05:07 AM

: Error: Ns_PgOpenDb(postgres): Could not connect to
: localhost::MyServer: could not connect to server:
: No such file or directory
: Is the server running locally and accepting
: connections on Unix domain socket
: "/tmp/.s.PGSQL.5432"?

On RH (and probably others also), in /etc/rc.d/rc.sysinit, add the third line below. The first two should already be there. This will clean out a leftover .pid file and allow the /etc/rc.d/init.d/postgresql startup script to start PG on boot.

# Delete Postgres sockets
rm -f /tmp/.s.PGSQL.*
rm -f ~postgres/data/*.pid