Michael Batchelder wrote:
> Use explicit filtering rules or proxies, whichever
> is applicable.
I don't know that a filtration rule as such can protect against a
session splice, either. Proxies may be a different matter (for example
if the attack is a known exploit you can have an application proxy drop
the packet based on matching it against a list of exploit signatures).
But even then you can't protect against, for example, man-in-the-middle
data thieving.
I'm no expert, but I believe that the standard method for protecting
against session hijacking is to have a robust TCP/IP stack with good
random sequence numbering at each endpoint of the connection (ie, don't
use Windows, AIX, HP-UX, or out-of-the-box Solaris), OR use layer three
cryptography with authentication enabled (not always an option,
obviously). The firewall doesn't really matter much in this case.
--
~~~Michael Jinks, IB // Technical Entity // Saecos Corporation~~~~
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
