Re: ipfw stateful and ICMP
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 1 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 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: ipfw stateful and ICMP
On 3/11/14, 1:05 AM, Dewayne Geraghty wrote: On 11/03/2014 2:53 PM, 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 1 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. 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. 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. 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. 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 :-) Julian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org Julian, That's a good idea, and I appreciate the feedback opportunity. May I suggest a sysctl to enable the behaviour, rather than one to disable it. For two reasons: so that existing ipfw sites don't find the need to change or amend existing firewall rules (we typically open icmp 3 and 11); and how do you envisage ipfw show will display this compound behaviour? I don't know that it need show anything special. the display of dynamic rules might be changed to show something but I haven't thought too much about it yet. Regards, Dewayne. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: ipfw stateful and ICMP
On 11/03/2014 2:53 PM, 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 1 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. 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. 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. 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. 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 :-) Julian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org Julian, That's a good idea, and I appreciate the feedback opportunity. May I suggest a sysctl to enable the behaviour, rather than one to disable it. For two reasons: so that existing ipfw sites don't find the need to change or amend existing firewall rules (we typically open icmp 3 and 11); and how do you envisage ipfw show will display this compound behaviour? Regards, Dewayne. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
ipfw stateful and ICMP
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 1 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. 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. 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. 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. 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 :-) Julian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
