"The Linux Gazette...making Linux just a little more fun!"

Closing Ports, Disabling Unwanted Services

From Troy Miller on Tue, 18 Jan 2000

I'm new to Linux and I'm trying to secure my PC. I have a DSL line and I found out I have 4 open ports (FTP, Finger, Telnet and SMTP). I'm trying to find a resource on how to close these ports. I do not plan to use them at this time. I don't want to compromise my system.

Thanks,
Troy

Bravo! You are doing the right thing.

Three of the services you mention are usually launched dynamically by inetd. So you can disable them by editing your /etc/inetd.conf file, find these services by name, and commenting them out of the file (inserting a "#" (hash/pound sign) at the beginning of those lines). After that you can send a HUP signal to inetd to force it to re-initialize itself. You can use the following command to do that:

kill -HUP $(cat /var/run/inetd.pid)

Of course, in this case you aren't running ANY other inetd services so you can even just kill you inetd process using a command like:

/etc/rc.d/init.d/inetd stop

... or something like that. (The exact path to your /etc/.../init.d scripts might differ depending on your distribution).

You can also find an remove the rcX.d scripts that start inetd during boot if you like. Your system might have a 'chkconfig' command to manage those SysV init symlinks for you, or you can use the technique that I've described here before (create /etc/.../rc*.d/disabled directories, and move the S??... symlinks into those as appropriate).

Search the back issues for "sysv init" to hear the long-winded discussion of how all of that works.

That leaves the SMTP service. That is probably being provided by sendmail, which is probably being loaded "standalone" (not dynamically through inetd). So you also want to find the /etc/.../rcX.d/S* script that's starting sendmail and disable that.

After you've done that you'll have a machine that doesn't provide any network services to anyone.

You can double check that using a command like:

netstat --inet -an

... and looking for anything that's in the LISTEN state. You can also check it using a port scanner like nmap from another system. (I'm guessing that you've already been playing with one of those, to get the information on which you've based this question).

Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 50 February 2000

HTML transformation by Heather Stern of Starshine Technical Services, https://www.starshine.org/

					1	2	3	5
				5	6	7	8	9
10	11		13	14	15	16	17
18	19	20	21	22	23	24
26	27	28	29	30	31	32	33
34		36	37	38	39	42	41
42	43	44	45	46	47	48