[ale] how do I close a port / security problem

Joe Knapka jknapka at charter.net
Thu Nov 25 13:36:28 EST 1999


jfondow wrote:
> 
> I just noticed that I have ports 25(smtp), 80 and 139 (NetBIOS) open and
> I need to close them.  I am running a SuSE box to connect to the
> internet and it is running ip-masq to serve the connection to the rest
> of the house.  What do I need to do to make this machine tighter on
> security.  I thought I had ip-chains configured correctly, but I must be
> wrong.  Here is the url that detected the open ports:
> http://www.grc.com/default.htm.  Any and all help would be greatly
> appreciated.  Thank you.
> 
> SuSE 6.2, kernel 2.2.10

The Gibson Research site is pretty cool.

I used the following ipchain rule to close all ports but 22 (secure
shell)
to TCP traffic:

ipchains -A input -s 0.0.0.0/0 -d <my.ip.addr> ! 22 -p tcp -y -j DENY

It denies any packet attempting to open a connection
to a port other than 22.

For UDP, it seems that you have to block relevant
ports individually. That's because, UDP not being connection-oriented,
you
don't know if an incoming packet is an attempt to gain access to your
machine or just a reply to a request you sent. So I have the following
rules for ports 136-139 (NetBIOS):

ipchains -A input -s 0.0.0.0/0 -d <my.ip.addr> 136 -p udp -l -j DENY
...

This seems to do the job. It would be better to just deny all UDP
traffic except for ports you actually use, but I haven't had time
to figure out which ports need to be opened yet. Even cooler would
be a way to reject unsolicited UDP packets, but allow ones that
are coming from sites to which you've recently sent requests.
I don't think IPchains allows that, though. The above collection
of rules will cause your ports to show up as "stealth" on the
grc site, and will prevent any NetBIOS name information from
being discovered as well.

I only deny input packets. I think this is sufficient. Does anyone
know for sure? Is there a way an attacker can take advantage of
a failure to block outgoing packets? (Assuming the above rules
are in place.)


-- Joe Knapka






More information about the Ale mailing list