"Michael R. Jinks" wrote:
>
> 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.
My comment you cite wasn't intended to address a defense against session
splicing in particular, but rather the part of the email that dealt with
proper ways to set up a firewall in general, i.e. not using a form of
NAT in place of real rulesets.
> 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.
Agreed.
Michael
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
