[Shorewall-newbies] Shorewall 1.4.9 + Reject/Drop/Stealth

Ow Mun Heng ow.mun.heng at wdc.com
Tue Jan 27 17:54:39 PST 2004

> -----Original Message-----
> From: Ow Mun Heng 
> Sent: Tuesday, January 27, 2004 3:07 PM
> > -----Original Message-----
> > From: Tom Eastep [mailto:teastep at shorewall.net]
> > Sent: Wednesday, January 14, 2004 5:52 AM
> Shorewall version 1.4.7
> iptables 1.2.7a
> RH9 + Kernel 2.4.24
> Quoting from the release notes
> =========
> 2) To cut down on the number of "Why are these ports closed 
> rather than
>    stealthed?" questions, the SMB-related rules in
>    /etc/shorewall/common.def have been changed from 'reject' 
> to 'DROP'.
> =========
> So.. does this mean that now, when I audit/scan my PC's firewall rules
> from places like auditmypc.com etc.. I won't get the <CLOSED> 
> status? and 
> then having them tell me that my ports are actually 
> responding and that 
> is not a good way to go??
> I tried changing the all2all from REJECT to DROP and 
> re-running it, but
> still get the warning.
> Challenge my understanding(or lack of).. Please.

This is from the WIKI-FAQ
(FAQ 4) I just used an online port scanner to check my firewall and it shows
some ports as "closed" rather than "blocked". Why? 
Answer: The common.def included with version 1.3.x always rejects connection
requests on TCP port 113 rather than dropping them. This is necessary to
prevent outgoing connection problems to services that use the "Auth"
mechanism for identifying requesting users. Shorewall also rejects TCP ports
135, 137, 139 and 445 as well as UDP ports 137-139. These are ports that are
used by Windows (Windows can be configured to use the DCE cell locator on
port 135). Rejecting these connection requests rather than dropping them
cuts down slightly on the amount of Windows chatter on LAN segments
connected to the Firewall. 

I still don't see/understand why they are "closed" My understanding is VERY
limited at this point in time.

> 2nd one..
> ==========
> 6) The default value for NEWNOTSYN in shorewall.conf is now "Yes"
>    (non-syn TCP packets that are not part of an existing 
> connection are
>    filtered according to the rules and policies rather than being
>    dropped). I have made this change for two reasons:
>    a) NEWNOTSYN=No tends to result in lots of "stuck" 
> connections since
>    any timeout during TCP session tear down results in the firewall
>    dropping all of the retries.
>    b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info 
> resulted in
>    lots of confusing messages when a connection got "stuck". While I
>    could have changed the default value of LOGNEWNOTSYN to suppress
>    logging, I dislike defaults that silently throw away packets.
> =========
> During my web-surfing sessions, I tend to see a few of these newnotsyn
> connections
> and I'm wonderig if this is cos the webserver's actually just 
> pinging (some
> are ICMP packets)
> my box due to item 6(a)
> _______________________________________________
> Shorewall-newbies mailing list
> Post: Shorewall-newbies at lists.shorewall.net
> Subscribe/Unsubscribe: 
Support: http://www.shorewall.net/support.htm
FAQ: http://www.shorewall.net/FAQ.htm

More information about the Shorewall-newbies mailing list