[j-nsp] "ping: sendto: Operation not permitted" in LAN

Stefan Fouant sfouant at shortestpathfirst.net
Fri Aug 19 19:03:09 EDT 2011


This is the nature of stateless firewall-filters guys... It has been this way since the beginning and everybody else seems to understand this behavior. I don't see anybody else screaming that this is a gaping security hole.  You do realize that this is no different than ACLs on Cisco right? If you need something that will handle traffic statefully, use a firewall instead.

Stefan Fouant
JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant

Sent from my iPad

On Aug 19, 2011, at 6:33 PM, Nick Kritsky <nick.kritsky at gmail.com> wrote:

> "inconsistency"?
> I would say "gaping security hole". I wonder how many routers out there are setup to pass any IP packet with ACK bit turned on. 
> 
> Nick
> 
> On Fri, Aug 19, 2011 at 5:50 PM, Stefan Fouant <sfouant at shortestpathfirst.net> wrote:
> Hi Saku,
> 
> 'tcp-established' or any of the other TCP bit-field match conditions do assume an implied TCP, but they aren't actually checking to see if the protocol is actually TCP.  Therefore, they are simply looking for a bit to be on or off at a specific offset where those fields would be if the packet was actually TCP.
> 
> What this means is that if the packet is anything other than TCP, and a protocol match type of TCP is not specified, other packets may match if the bit is set at that particular offset.
> 
> This isn't really an "inconsistency" as you say and there are no real useful applications here... This is why the Juniper documentation and other literature is explicit to point out that you should always use a 'protocol tcp' match when using these bit-field conditions...
> 
> HTHs.
> 
> Stefan Fouant
> JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
> Technical Trainer, Juniper Networks
> http://www.shortestpathfirst.net
> http://www.twitter.com/sfouant
> 
> 


More information about the juniper-nsp mailing list