ipfw stateful and ICMP

[Ian Smith]

On Mon, 10 Mar 2014 20:53:39 -0700, Julian Elischer wrote:
 > It has annoyed me for some time that icmp packets refering ot an ongoing
 > session can not be matched by a dynamic rule that goversn that session.
 > 
 > For example, if you have a dynamic rule for tcp 1.2.3.4 port
 > 80 from 5.6.7.8 port 10000 then a returning icmp packet giving
 > "destination unreachable" and holding the appropriate header
 > in it's data segment should probably be allowed to go through
 > back to the originator.

Can you always expect the data segment to contain the true srcaddr 
(perhaps NAT'd, perhaps with the same srcport) when any router along the 
way might be sending these - legitimately or otherwise?  We don't need 
an open door for any MITM router to send us whatever ICMP it fancies, 
but I am interested in the development of this idea.

Maybe you'll be looking into in-general stateful ICMP anyway?  ISTR 
that any icmptypes were passed in return, but that was ages ago; is 
there yet any matching for request and response types, beyond pings?

 > Briefly looking at the code I see no sign of this and I haven't seen
 > any sign of it in action so I hope I'm not going to get a
 > "but it already does that" response.
 > 
 > My way of approaching it would be to change the dynamic rule code so that
 > it checks that the ICMP destination address matches the source address
 > of the packet fragment in the 'data' section, and then match the data segment
 > packet header with the dynamic rules instead of the icmp packet itself.

Have we only the srcaddr/dstaddr in the data returned to match flows on?  
And ports if from say a TCP or UDP request?  Sorry, I've no time to hunt 
code, hope you don't mind me asking such basic stuff?

I'm wondering about security in which case you (or at least authors of 
ipfw rulesets) might - likely should - want to filter out potential 
nasties like redirects, perhaps router advertisements, even better first 
pre-pass specified allowed icmptypes, dropping the rest (or at least, 
dropping them for consideration in stateful matches), BEFORE any 
check-state or keep-state waves packets through the fast lane - and we 
see quite a few rulesets published that begin with a check-state.

 > I would also add a sysctl to disable this behaviour, because there is always
 > someone who doesn't want any change you care to name.

I agree with Dewayne about POLA; start opt-in, it will get promoted once 
widely appreciated :)  It may need more sysctls for default behaviours.

 > The only way you can allow get icmp packets back to the originating sender
 > at the moment is to just allow them through without any major filtering.
 > That leaves you open to a large attack window.

Yes, so cautious people have followed assorted gurus' advice re 'good' 
icmptypes, and this will need a way (apart from expert ruleset creation) 
to integrate that - some sort of allowed / denied icmptypes mask with 
conservative defaults? - so people don't inadvertantly open their boxes 
to, say, MITM floodpings, MSS choking, dodgy redirects, or worse(?)

 > anyone have violent objections?
 > 
 > (I'm currently rewriting the firewall rules at $DAYJOB and I think I'd like
 > to have this,
 > but as we're on 8.0 I'll have to wait a while before I can use my own patch
 > :-)

Can you trust a patch that its author isn't using? :)

cheers, Ian