> I'd love to be proven wrong, though; source port filtering is the last
> major missing feature in Cisco's packet filtering.
Brent,
honestly, why do you think that source port filtering is important? (I am
asking quite seriously.) We have looked at the issue many times and always
come up deciding that adding source ports to filters adds risks but adds
no real security. Recently, I have had some long rounds of discussions on
this topic. I have yet to be convinced, but I am always open.
My concept of firewall design has no need for source port filtering. In
fact, I can see of no way to use them securely.
Generally when people talk to me about source ports, they are interested in
a way to allow standard outbound ftp traffic (initiated inside their net)
without allowing inbound TCP connections (used for the data channel) on all
destination ports greater than 1024. The problem is that you have no
control of machines outside of your net and what software can be run on
them. So to allow inbound connections from source port 20 (ftp-data) to
any destination port > 1024 is equivalent just allowing any connection to a
destination port > 1024 with some "security through obscurity" tossed in.
It's trivial for me to change my telnet program to always use source port
20. The right solution for ftp traffic is to use an ftp client with the
PASV patches or to use some form of proxy agent.
I know that ftp is only one example, but it is the most common one due to
the nature of the program. Other examples that I am aware of fall into the
same trust model. If you can't trust the information, how can you use it
as a basis for your security model.
Dave
----------------------------------------------------------------------------
David Carrel | E-mail: carrel @
cisco .
com
Security Development, cisco Systems | phone: (415) 324-5207
P.O. Box 3075, 1525 O'Brien Dr. | fax: (415) 428-5080
Menlo Park, Ca, 94025-1435 |
----------------------------------------------------------------------------
References:
|
|
