Forum OpenACS Q&A: Re: server security...
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?
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 ?
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.
: localhost::MyServer: could not connect to server:
: No such file or directory
: Is the server running locally and accepting
: connections on Unix domain socket
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