On 04/04/2000 at 19:32:11 EST, Guy Johnson <[EMAIL PROTECTED]> wrote:
> Is it true that in order to be "secure" firewalls should restrict access
> to protected services by filtering the SOURCE port of the connection
> from the outside?
>
> I work on an application for which a single participating machine may
> need to open multiple connections to a single service on a target server
> machine. That target service listens on a single known port. It's not
> even possible to work this scenario without allowing there to be
> multiple source ports, right? Otherwise how are the individual sockets
> distinguishable?
>
> What is anyone REALLY losing by allowing packets to flow where the
> source port is not checked? It seems that damage can only be done to
> open listeners... Generally of the stuff I've read so far, filtering
> source ports is more likely to break things than actually increase
> security. A hacker can always specify a source port that would work
> anyway, right?
>
> Any general comments about the pros or cons of source port filtering in
> firewalls would be appreciated.
Source port filtering of traffic coming into your network should only be
done for responses to client-type requests from your own systems. You
probably shouldn't filter the source port of, for example, connection
requests coming into your own machines.
Here's an example of the former type. You have a dns server that must be
able to query other servers on the Internet. When it makes an outbound
request, it will use a destination port of 53; it's source port is likely
to be something over 1023. Ignoring what filtering you might be doing of
outbound traffic, let's consider the response to your dns request. If you
don't do source port filtering, you have to let traffic flow from the
Internet to your dns server on all tcp and udp (dns traffic may use either
or both) ports above 1023 (as well as the normal 53, assuming you accept
queries from the Internet). If you do source port filtering you can limit
that significantly by requiring that the source port be 53. It makes me
feel better anyway.
Note that your dns server can still be attacked on any of its high ports.
If the attacker uses a source port of 53, he's going to get by your
filters. Still, I think there is some benefit to this.
Here's an example of where you usually don't want to do source port
filtering. Let's once again assume you have a dns server. It's going to
receive requests to a destination port of 53, but you shouldn't make any
assumptions about what the source port must be. There have been cases
where folks have said, "I know the source port must be above 1023." They
block all else and later find out that some platform or application uses a
low-numbered source port. Dns is an example of this; dns requests often
are sent with a source port of 53. And some ssh clients use a source port
less than 1024.
You could make similar arguments about outbound traffic. If your machines
only act as servers, for example, you may know what source ports they can
legitimately use. A machine that is just a web server perhaps will use
only a source port of 80. If you filter all else and your web server is
compromised, the attacking entity will not be able to communicate outbound
without realizing that it must use that source port for all of its traffic.
Tony Rall
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
