i would like to close as many ports as possible, at the very least ftp and telnet.. Are there any other ports on this list that i should or should not close?? This is our gateway and its sole purpose is to provide internet connectivity for the office.
I would also keep ssh open to allow for
remote monitoring and administration.
You may also wish to use ssh to "tunnel"
through to an internal system. It really
comes in handy when you get a call in the middle
of the night
21/tcp ftp (COMMENT OUT IN INETD.CONF)
22/tcp ssh (KEEP THIS FOR REMOTE MGT)
23/tcp telnet (COMMENT OUT IN INETD.CONF)
25/tcp smtp (COMMENT OUT IN START UP SCRIPTS)
37/tcp time (YOU MAY WANT THIS FOR REMOTE MGT)
80/tcp http (YOU MAY WANT THIS FOR REMOTE MGT, OTHERWISE COMMENT OUT)
113/tcp auth (KEEP FOR OTHER DAEMONS TO USE)
515/tcp printer (COMMENT OUT IN STARTUP SCRIPTS)
587/tcp submission (COMMENT OUT IN STARTUP SCRIPTS)
1024/tcp kdm (COMMENT OUT IN STARTUP SCRIPTS)
6000/tcp x11 (COMMENT OUT IN START UP SCRIPTS)
Don't forget to enable route filtering and use FW (packet filtering) tools.
So far everything is good, you just wanna re-start inetd...
In Linux, you could use the service comand, but normally, all you need to do is "ps -ef | grep inet", now get the PID of the inetd proc, take that and send it a "kill -SIGUSR1" \(see your kill manpage for a better idea of what signal to send\), this will force the inetd process to re-scan it's conf file.
As I said, READ the kill man page BEFORE doing this, make sure you get the right signal, otherwise, you may kill inetd completely, and not be able to telnet \(or anything\) in to restart it. Another good idea is to be at the console if you are re-configging network stuff, just for safety's sake.
Just one last little bit, your inetd.conf file is a better reference for what is running on the box, under inetd,(not to mention the use of lsof and looking at /etc/services) than an nmap scan. nmap is guessing at what is running on what port from a list of what is assumed to be a known service on those ports, usually anything above port 1024 (and sometimes, below it) is arbitrarily set to serve from that port. BackOrifice and NetBus could be config'd to run from other ports, so can netcat and other such tools. Your best bet is stripping down to only what you need, and keeping a sharp eye out for any new servers being put out there. You can use lsof to get an idea (okay, see what's happening) of exactly what proc is using which port so you can see who is serving what out of your box.
The nmap scans are excellent for finding servers that are nto running under inetd's auspices. Sounds like you're going in the right direction....