Ryan,
I suppose I should clarify what I said:
Historically I have come to understand "packet filtering" as screening based on
IP-level and transport level information. With such limited information, you
can't determine with certainty the application-level service; you can only make
a best guess.
Of course, if you have a more advanced packet filter, you could arbitrarily
examine any or all bits in the entire packet. At that point, though, you're
basically performing application-level analysis, and incurring the performance
penalty, so why not use a proxy?
Regards,
Chris
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Christopher Zarcone - Data Communications Design Analyst
Lockheed Martin Enterprise Information Systems
czarcone @
vf .
lmco .
com * Chris .
Zarcone @
lmco .
com * czarcone @
acm .
org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My opinions do not necessarily reflect those of my employer.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >Jon,
> >
> >Stateful inspection engines suffer the same disadvantages as packet
> filters,
> >because THEY ARE packet filters.
>
> But they are not JUST packet filters.
>
> >I would say that (my) single biggest problem with packet filtering is
> >application-level security (e.g. how can a packet filter differentiate a
> >sendmail server from a rogue webserver running on port 25? It can't. A
> proxy
> >can.)
>
> They can, in the same manner that a proxy can.
>
Follow-Ups:
|
|
