Firewall rules

Vernon Schryver vjs@calcite.rhyolite.com
Mon Sep 13 13:24:52 UTC 2004


> From: Richard Underwood 

> | Most DCC installations are of clients. Some installations also
> | include DCC servers. It is usually desirable to have a DCC client
> | with a local server fallback on the external, public DCC servers.
> | This will allow query responses from external servers to reach
> | the internal client at 192.168.7.2:
> | 
> |   access-list 101 permit udp any eq 6277 host 192.168.7.2 gt 1023
>
> 	This allows any UDP traffic originating from port 6277 to any port
> greater than 1023. This could be used for udp port scanning (e.g. with nmap)
> or even bypassing the rules - some protocols use well known UDP ports above
> 1023. e.g. nfs typically uses 2049.

That's right.  If your DCC clients always use the same port from which to
send their requests to distant servers, then you could tighten that rule.
Do your DCC clients always use the same port?  I doubt it.

The same considerations apply to DNS.  What do you firewall rules say
about port 53?  If you block responses from distant port 53 to your
local anonymous ports, can you still resolve external domain names?
(If you have a local caching server, you'd want to test blocking
its traffic, since your local resolvers should be talking to it.)


> | Access-list 101 should already have an 'allow established' line that
> | will allow return tcp packets resulting from the local dccd flooding
> | to a remote dccd. If does not, add this for the DCC server at
> | 192.168.7.2:
> | 
> |   access-list 101 permit tcp any eq 6277 host 192.168.7.2 gt 1023
>
> 	Likewise, this allows TCP connections to any port greater than 1023
> from 6277. As an example, my server also has mysql installed. If I used the
> rule as described, an attacker could bind their client to port 6277 and
> connect to port 3306 on my server, connecting to the mysql server which was
> otherwise firewalled.
>
> 	While best practice would mean that these connections are also
> restricted at the service, I don't believe it's appropriate to offer
> security advice that isn't secure, despite warnings; I'd suggest stressing
> the use of "established" rules or stateful firewalls and explicitly warning
> that allowing incoming connections based upon the source port is inherently
> insecure.

What wording do you suggest?


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.