[nat comments deleted]
> Filtering is something akin to what a proxy would do. If a packet
> comes in, it's matched against the network objects (dynamic and static) which
> are complete stateful sessions (UDP is another matter - supprise). No match,
> it's dropped. If it's matched, then it's translated according to the state
> of the network object it's matched against. Sessions all have dynamic
the problem here is that the filter doesn't fully understand the
application protocal that you are firewalling. an example is http.
could the PIX firewall prevent a java or activeX connection should
my security policy require that i do so?
> Another neat trick is in some load leveling stuff they've got in
> there. Got a heavily loaded web server? It can load level between several
> servers for you and the outside network won't even know the difference.
You can do this stuff with DNS if you are sneaky....you can even have a
DNS server remove machines from the pool if they go down for some reason,
again, if you are sneaky :)
> like cookies and stateful CGI from breaking). Got three different
> algorithms for load level. Will load level based on equal number of requests,
> amount of data traffic, and request-to-response time. Some packet filter...
using DNS gives you the above thanx to host caching. you set
your cache timeout and *poof* request affinity.
> > Their biggest selling pt. is that they use a "cut through" proxy (read
> > packet filter rulebase) that processes packet while it is being
> > received. Do not ask me what this means :) I rephrase their sales ppl.
I've only heard cut through in terms of switches (versus store and
forward). If i remember correctly, a cut through switch started switching
the packet while it was still being received. A store and forward would
receive the SOB, then take a checksum and, perhaps, apply some minimal
routing/whatever against it. the latter has marginally higher latency
(measured in micro-seconds) but keeps garbled packets off of your net.
in this instance, i'd bet that they *don't* start operating on the packet
until at least the headers were received, so that they can start computing
where it will go. If they don't look at the payload, though, i,
personally, will be kinda nervous. One never knows whether that there
packet contains a bomb instead of the 'research material' it should have.
Am i wrong? is a firewall not something akin to the bomb detectors at an
airport terminal? Shouldn't the luggage be xrayed and the electronics
inspected?
-- craig
-------------------------------------------------------------------------------
Craig I. Hagan "It's a small world, but I wouldn't want to back it up"
hagan @
cih .
com "True hackers don't die, their ttl expires"
References:
|
|
