>From: MICHAEL NITTMANN <NITTMANN @
UWLAX .
EDU>
>it only seems to me to show his lack
>of real life experience.
>
I have only real (life) experience with routers.
>First thing of source filtering: ping to a private network
>interface.
> I would like to make some networks invisible, and only visible
>to people I deal with. This means, the ping target is not the router
>interface, but an internal host which logs who sends the icmp
>requests and when, including full packet trace.
>
I also keep some (sub)nets invisible to the outside world.
I use static route table control to do this.
Please explain how filtering on source ports would help this. I don't see it.
>Maybe David should have a look at NSC's Vitalink customers list and
>find a hell a lot of people that prefer a full filtering capable
>router to a firewall host setup. Source filtering facilitates big
>time the configuration of boxes and reduces the size of config
>files, including the difficulty in maintaining them per interface.
>
[Everybody should ignore the nastiness here.]
In what way does source port filtering "facilitate big time"?
I can only see additional lines in a filter list if this were available.
>Transparency, ease of administration, and completeness of a filter
>set are very important, at least to some.
>
I think what Brent is looking for is regularity of the configuration of
access control filters. The view is that it should be possible to specify
filters based on any parts of the packet headers, not just some.
>To me it seems again that individuals defend here an obvious lack of
>a feature as intended.
>
I try to be careful not to judge behavior of others (especially who have been
involved in the business longer than me) just because I do not understand it.
It strikes me as easier for Cisco to have provided filtering commands for all
bits in the packet header, so I look for good reasons not to have some features.
My conclusion is that Cisco deliberately left out some header fields so that
their customers would not be lured into a subtle mistake.
There are other aspects of their filtering that have different reasons:
only filtering outgoing packets used to be a performance issue;
logging packets at the router is still a performance issue.
>Mike
We all lament the lack of association control inherent in UDP.
I am not sure adding configuration access to source ports helps much.
If the ports are below 1024, you give control over to just the administrator,
or the SUID program he/she wrote; if over 1024 you can't trust them at all.
There is a trick the CheckPoint people have popularized that I call dynamic
access-list entries. At the risk of getting flamed (not on the list please),
I will summarize it:
When a transaction controlled from inside the firewall requests a reply from
a specific host|protocol|port, the screening router creates a short-duration
permit statement for just the reply. This solves the nasty problem of needing
special FTP clients at sites that control FTP access. It also provides much
finer-grain control for those troublesome UDP-based protocols.
My hint to Cisco is that this would be much better than adding configuration
control for source ports. But it still would not be as regular as Brent wants:-)
John
|
|
