Re: [RFC][patch] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 08:13, Julian Elischer wrote: yes I think keep-state should be deprecated and replaced or supplemented by 'save_state' that does NOT do an implicit 'check-state'.. I don't know whose idea that was but it's just wrong. (if the state exists, maybe just replace it..) Update, not replace :) See my Version-3 patch for record-state :) - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0eTUXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePoS0P/iCMeTo+fFA4iGwe/8FnlF+y 899fomt4tzOBppxg1r5/xx11OMB9DJ6VG1z8+61gzIg1jgxvAIBTBGz5oxIgyfv5 mtbEbfhsxsABYTASjwIQymxR1zvLCbyd7fWgDRhM8YJYEy/akWNzOwtbokrkK1Ww 3j2IODup3onYr5LhwoQZGPdtmIyH10rnEcs49IWUs1ZweWlJx7XRQOGBAepTQRx9 bh/D0owV1j9BBzyqd5n54aXiQpMKMIdOihmNOOUYhl0B3GksacWguV7Keabbv0Dh Nnk3g/GrBYJPdmF0JqkocjrGxSuWAwBXfdXg3SoG8l1dPqaDg8UNVXq7VthS7FKO 8jyoRXaptbcrTjgG0SHdfnSzbhpLj78/PdGi1VvJwrvjnK2MNb6dZ2PE3E88ScgM f7OIOef9GyLwgAPqn6TJeiC7Oddvq+vL1vEigqLMJscJ4ErwqX8RVidbkYdNmKCf HYSd9mSJgkAMUH7q2U5PCRY9Ay6BOkuGHEqvMHGFClqBWb81RTyT8ZR+BL+JeqRr QNilMWvUXJSGEcvMYijKiv2EVDB6by3sY2SK9KLa93H0jY1nR3XPpilpyLcHLzN9 5aVknqR2/TzFDS1BiSEg/wYipyqjgIyHTqqxj0Vd0pnZMSw3AqdrOSLz8mHJzXKp 3J8Y7Lw7fuM1N8Doq2Md =/M0i -END PGP SIGNATURE- ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 15:34, Ian Smith wrote: I don't get this .. we're always working on just one packet at any time, either inbound or outbound (to kernel), so how can check_state (or the check also on keep-state) apply to any other packets than that one? Simply enough: assume packet goes from internal network (in recv em0, say) to external one, (out xmit em1). It passes firewall twice, really. In ip_input() (it is matched by in) and ip_output() (it is matched by out). Say, we have keep-state for this packet when it is in as last action, something like allow keep-state to have this state to check answer packet in recv em1 (note, em1 here) appropriately. And in out section we could have OTHER keep-state rule, for locally originated packets (which never pass through as in ones). Of course, this, second, keep-state is equipped with additional conditions like src-ip me. Now, our transit packet creates state in in section and is passed to out section. And it triggers this state on src-ip me keep-state rule! It doesn't belong to this rule! But doesn't pass conditions of this rule! It SHOULD NOT BE AFFECTED by this rule, match failed, try next one! But -BANG-! keep-state has implicit UNCONDITIONAL check-state! So, we need additional stupid skipto like this: XXX skipto ZZZ not src-ip me YYY allow src-ip me keep-state ZZZ nat 1 // out To me, it is stupid, contra-intuitive, non-orthogonal and bad design. I think, there is THREE DIFFERENT things: (1) Creation/updating of state, with normal condition checks on packet. (2) Checking packet against state table, updating state, performing action (if appropriate state is found, of course). (3) Performing action WHEN state is created (not checked!) Now ipfw has very tangled way to do this. We have: (A) (2) + (1) + (3) (in this order, please, note that condition checks are done in (1), not BEFORE this chain). It is keep-state. (B) (2). It is check-state (c) (3). It is stateless rule. That's all! You could not do (1) without (2). You could not do conditional (1). You could not do (1) but not (3). Nothing! And if conditional (2) may be too much, but only possible to go to (1) is via (2) and inevitable (3) after that is too much, IMHO! It is very obscure behavior! To be honest, I want add not only keep-state-only (pure (1)), but, also have keep-state-do-action-no-check to have (1) + (3) without (2). - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0hiMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePd60P/iTr55i4uyLfa7cf/TH9ypdt S9iP23qGZDPo+YzjVfmcyBNWbYJ2eNfkve9DhYHoizpacqHeepnWfMxNPdSf0kLI lZ0qYt/EtwTDCOoSx+wE/c1ywzvHUKO7k631GS/EpRbUwli5yEZnJEFwJPlEJ8WY A3uBtPxBAn3CEiS7ps91Da260Qt3xgw4Sv99YOzY7k2etUOsj8r2EEkLG8gsH96V Pk4udb17Kc0WygwNN7OaI1mxXaoKkd6NzZM4W0WvWy5fKgD/Rhep5hD4/oFixfsJ HKxjYjUDrzc6/elL5GW1+OwzQ08+KziriRqBT2QMOJnso9a1yQc/5jvO1C4zol9Y wF3ZgcMIAJKBmOdkWHPMfrhNYMutI8gPsKH063BRkHFTtTQb7yL8bysLYE1P23lM hzl3ubZtcas7Z5kBpsAL2L0xXLReMCCTSULv0oQDitb6H4z3eUeN5iq2Sk6b0uwB J6mZiHCYU48KU0ST4/UAnZFYX4mUFTiIfP2KzekdZ+BUNdGgdVr177EJChZxBL4M x/In6x944pwRxCExFa10OSMzQqdOJ+IQEfS1LfG+l/A4X7Rjx87Gbb4A/3ePkkdA HoZLACmRfFGxmWILZa8EtldUvDsOjXs+Q08rpvp2So0szcM0N5XIixDbnLEvCqFu xn6GOWuyaJVzZlpllCV0 =ALXi -END PGP SIGNATURE- ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 16:03, Lev Serebryakov wrote: To be honest, I want add not only keep-state-only (pure (1)), but, also have keep-state-do-action-no-check to have (1) + (3) without (2). Ideally, here should not be implicit check-state at all, and should be two options to rule: (1) keep-state (2) skip-immediate-action So, current keep-state becomes two-rules: check-state all from any to any rule keep-state And all other variants are possible too, like rule keep-state skip-action and meaningless, but still possible, rule skip-immediate-action It is hard to add now in backward-compatible way, though. But may be... May be... I should think! It looks like doable on second glance, and better (more flexible orthogonal) that my current proposal! - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0hrdXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePGFcP/0CpmLVadnVjQqC+PLQVpT4E cqLy5RfE4D587JeaXfoDher7J/WJj02NKJWkuhZqkvuZAVvFx5xiyl63X9yR1ASR a8rHGkM9pa4wbQ9XA2YKlhsaVntQtmmk1/qyp9AZecX/aZl6taWualeRCPGgNSvC lP6JdUCTelUIjlGwvsKI4Xu9ljuV59PaYh3SxLXxQSuyr5CA1ayRjT5e6Mp7SLPk gfy38Cq7PmrwrQAtkYfcP8K9fYTpnHaKqXYKpELSIqbpKGUcB0AnloXg9u2fJbmD Ux8lf0MvpDOiw0UfcHaypluLzU0/vuWE9EwyXe4p6GbdWjd9YXwgkbMsCWcR5lbT KJrAo0Jk2//blLFtKNDSLHb3JpKjSQkVRE/dhNOr066m682xnloPxFPE1p1e79P8 9D4Yi/ii2CGR15tP9keNjnDEOvO5JSSD+kHH/elUyuHye++UjKKNJoDCp5JIopFr SJ7NHYyVhlMmIMWIQeXUIRoNxblv9C5C9G2k7nBMlaxWN8VG0AKIerRyHTrEtwzt 0M9Tb6Et7dXULvqR0U+PgXvOLDo+DmmYf5cZiUCsVnLba0UwcWt7i2qWsA9KmQEE ZqTaVz8cJSkHybQLqlGtIwMfWgh7s6XSAjaPgk0OviDNCwTs9Ry/6QRPpCnkcC5p wsN8ML5mL59HqlkIvTxU =gWCG -END PGP SIGNATURE- ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
The possible issue is is that once NAT changes the IP address and possibly the port number, state tracking can no longer be applied. AKA, the packet headers before the NAT is different than the packet headers after. This is why NAT needs to track the state instead of ipfw. ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
On 2/4/15 5:22 PM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 08:13, Julian Elischer wrote: yes I think keep-state should be deprecated and replaced or supplemented by 'save_state' that does NOT do an implicit 'check-state'.. I don't know whose idea that was but it's just wrong. (if the state exists, maybe just replace it..) Update, not replace :) See my Version-3 patch for record-state :) I meant a function that acts like 'keep-state' except it does not do a 'check-state'. Im suggesting adding yet-another command. a 'fixed' keep-state. I sort of know why they did it.. so that if the state for that session already exists, the original state rule is used and not the new rule. but ..it fires on other packets as well as the one you are working with. - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0eTUXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePoS0P/iCMeTo+fFA4iGwe/8FnlF+y 899fomt4tzOBppxg1r5/xx11OMB9DJ6VG1z8+61gzIg1jgxvAIBTBGz5oxIgyfv5 mtbEbfhsxsABYTASjwIQymxR1zvLCbyd7fWgDRhM8YJYEy/akWNzOwtbokrkK1Ww 3j2IODup3onYr5LhwoQZGPdtmIyH10rnEcs49IWUs1ZweWlJx7XRQOGBAepTQRx9 bh/D0owV1j9BBzyqd5n54aXiQpMKMIdOihmNOOUYhl0B3GksacWguV7Keabbv0Dh Nnk3g/GrBYJPdmF0JqkocjrGxSuWAwBXfdXg3SoG8l1dPqaDg8UNVXq7VthS7FKO 8jyoRXaptbcrTjgG0SHdfnSzbhpLj78/PdGi1VvJwrvjnK2MNb6dZ2PE3E88ScgM f7OIOef9GyLwgAPqn6TJeiC7Oddvq+vL1vEigqLMJscJ4ErwqX8RVidbkYdNmKCf HYSd9mSJgkAMUH7q2U5PCRY9Ay6BOkuGHEqvMHGFClqBWb81RTyT8ZR+BL+JeqRr QNilMWvUXJSGEcvMYijKiv2EVDB6by3sY2SK9KLa93H0jY1nR3XPpilpyLcHLzN9 5aVknqR2/TzFDS1BiSEg/wYipyqjgIyHTqqxj0Vd0pnZMSw3AqdrOSLz8mHJzXKp 3J8Y7Lw7fuM1N8Doq2Md =/M0i -END PGP SIGNATURE- ___ 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 ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
On Wed, 4 Feb 2015 19:121:46 +, Julian Elischer wrote: On 2/4/15 5:22 PM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 08:13, Julian Elischer wrote: yes I think keep-state should be deprecated and replaced or supplemented by 'save_state' that does NOT do an implicit 'check-state'.. I don't know whose idea that was but it's just wrong. (if the state exists, maybe just replace it..) Update, not replace :) See my Version-3 patch for record-state :) I meant a function that acts like 'keep-state' except it does not do a 'check-state'. Im suggesting adding yet-another command. a 'fixed' keep-state. I sort of know why they did it.. so that if the state for that session already exists, the original state rule is used and not the new rule. but ..it fires on other packets as well as the one you are working with. I don't get this .. we're always working on just one packet at any time, either inbound or outbound (to kernel), so how can check_state (or the check also on keep-state) apply to any other packets than that one? I've seen examples that run keep-state on the same packet both before and after NAT, ie state on both the internal and external addresses, which is even more confusing and surely inefficient too. I'm not sure that everyone realises that it's the first check-state or keep-state rule _encountered_ - ie not skipped around - that matters. A good, definitive tutorial on how to best handle stateful, NAT'd rules would be useful, because there are a few different theories in the wild. Personally I only run stateful on a few types of session, and then always using the internal addresses, but that's just one of the ways .. but doing _everything_ statefully seems to be the Holy Grail to some. 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: [RFC][patch] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 14:11, Julian Elischer wrote: On 2/4/15 5:22 PM, Lev Serebryakov wrote: On 04.02.2015 08:13, Julian Elischer wrote: yes I think keep-state should be deprecated and replaced or supplemented by 'save_state' that does NOT do an implicit 'check-state'.. I don't know whose idea that was but it's just wrong. (if the state exists, maybe just replace it..) Update, not replace :) See my Version-3 patch for record-state :) I meant a function that acts like 'keep-state' except it does not do a 'check-state'. Im suggesting adding yet-another command. a 'fixed' keep-state. Yep. Maybe, additional option? Which will work only on user level and force to skip generation of O_PROBE_STATE? Now on KERNEL level nothing force this check, it is additional opcode, added by user-level compiler. Only thing we need to make it work properly is in my last patch for record-state: add TCP state propagation to install_state function to make it able to update existing state properly. and after that you don't need any additional opcodes for keep-but-not-check-state command/option, it will be user-level change. I sort of know why they did it.. so that if the state for that session already exists, the original state rule is used and not the new rule. but ..it fires on other packets as well as the one you are working with. Yep, because O_PROBE_STATE is FIRST opcode always. It is matter of compilation. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0gOIXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP/1sQAKMgZyk3BVCXB8Q+Rmvy/D0K YhPICBbPqUWHw35HfXG0hgw66pa/SX0G68HO2LoxurbxFtu3pdsKA3X8ok4J3Yvb 374MPQcUYFxoUmvjjWUpNMGUBBm72TPk61cjUdsWWJoYWrLJmM0UMJ2wJREvS2D6 s0hUuFGBb/OaTW8aHWY2gAwViPDxR2gQmX8Pw6XpZLxR3ZyNcMTnx78jGn+8jykM tLxmLjlOSAw4XfsbkiG6X7CmkgyFhcN/B6cpRNB8qsLSmG6rzBup6JrAcFYRq/63 LUj8Z0azwJoHqeLBKZ7RfcfqbB9PMdMTaufBPxQVclQntERkN4nEacT4LSRd1aoL 2zEKMV+PN8X4sL3h73laURLq5lHOVuJsG73YGR1n/IPtlkeeLu1zOADjPRd/0ZY+ kOWzvE00RGhb1mt2LNpL9qZQ8oIcf0r3pYuZKmV0vT7BnQ/Pw4lMjcPyHPSJyFgR yn2fslDvytg8e/iPvHuOm6h8t6Um3bAbV2LrW4fHSgbhMPGt/nzwuRicMoj6o+Fx r3q+ITM54QbodBZuS0Ie7IvCNZIfYwwp27GS1lZ8lEv1lYy4kVW9B3AOZzows5XW YWjVz4xzYd3qaTQyoNij9NFJYVx52IXoAP23PFPDhbr1OFhomGVXQCgu/KS3JHOQ kR5C1h4iKmkjLUCmDC/P =sqjh -END PGP SIGNATURE- ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 18:13, Jason Lewis wrote: The possible issue is is that once NAT changes the IP address and possibly the port number, state tracking can no longer be applied. AKA, the packet headers before the NAT is different than the packet headers after. This is why NAT needs to track the state instead of ipfw. If you create state and check state on proper ends of NAT (for example, create state for connection BEFORE out-NAT, with internal addresses, and check it AFTER in-NAT, with internal addresses again), it will work. But now, when state creation is terminal action AND state checking in one box, it is hard to implement and leads to very non-intuitive rule sets. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0jiVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTnQP/2kxqyTxUSa3RBLBsoq58iL4 IeGarQ7PrTVVaBTEVzhabU0yPuORpMqrwf47nImAZQWHcQP7UUjO+VjjqDthwwe8 S3CElbPFW86HmYLB7Nz1Lhg7n0eaKG6xxDO5um/b3cWuK7B3DiU+9oW7OHICF0Xa mk5Z9koVuAS3yuvT6PecSRgziV6HgxEKgYgNCgN+JmXWlL/H8kYUuYKBQTv1snkw hcRLKrRp31KavH8CRiTf6uBCozS4URvr6xRSfrkjcuU9LUlvHcI6jBCm7yOAEeDH HkcU5g5mNSK0vdJXZVmtveFADs8RrtAtovxt4FQZCjYPBhCDMRvM9IPQX8eK8tKX 8efJHb6DPIZQs+AeEhL1jeNJTu/UJRUag65Aua7TXq7jcopOMHM85aNMs6FzyqeG eT5Epc+oZ0Zbi0RAZzqvUeQSnARPE4tGddoOK5z5YMbF0jSiHM5ftfYncOp8YvDE uJMQAHOU4CHfuK/knzNkZ4VoD3+i+/fIiR4knNCLCe1wOvY9QmI+3iyk6JGZ4GJ9 vc7W+XCSnfuhFq5+o/8Lr+50z2qpmkJVaWoRW4DItWiHrWbx6dngL2aY8+e7TjEk 24rRQb16uYC6w3dUkNiKHMtUEaN+Zzju186jbQZpPjX6Rz4/9i2DJ6qYiZDWV28x e5TUOek2WeiROK+VvF/2 =XfPm -END PGP SIGNATURE- ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
On 2/3/15 6:23 PM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03.02.2015 13:04, Ian Smith wrote: Now to make stateful firewall with NAT you need to make some not very readable tricks to record state (allow) of outbound connection before NAT, but pass packet to NAT after that. I know two: (a) skipto-nat-allow pattern from many HOWOTOs Lev, can you provide references for these HOWTOs you refer to? I have a suspicion that some of them should be taken out and shot. google for FreeBSD ipfw nat stateful :) There are lot of them. Not real HOWTOs, but blog posts alike. BTW, without new mechanism it is really hard to do such firewall, as we need action (nat) after allow keep-state. It could be done with this ugly skip-to or with allow keep-state in INCOMING section of firewall, what is not much better, as I prefer to decide let packet out or not in OUTCOMING part of firewall and with allow keep-state in incoming path it flood state table with unused states. Another problem, that keep-state acts as check-state too, so you could not have ANOTHER keep-state before NAT in outgoing part or you miss nat completely (sate is created in outgoing path, and then checked before nat in outgoing path with keep-state, gr, ugly!). yes I think keep-state should be deprecated and replaced or supplemented by 'save_state' that does NOT do an implicit 'check-state'.. I don't know whose idea that was but it's just wrong. (if the state exists, maybe just replace it..) - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KGqXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePYvYQALeGCF9EuZKP3jLDaRwad+TO IhYq5I3xPPqU3eNEdQ6OqdFonVQ4mDB+UipZzspC/U5drf1qo2LkOF8oBNDlVDW4 2I+bgYStptIkpSoBOe5AGRYwO3jfec77GvXhR8cMeQZK2Z9NIazn5ZtFkdQyiiDU +b7pxBQ0SbbMUT3hubl4H+v93dMGfjnzrFg1aSY4/uYnmilb8plWN1o4BshZVMSz z1lrFSaorj4RNYxnpM6f6YtDDYx4TahA7+OILl/BvzmNoztWb5hKNX+1TGLZPcch QE19iix+8O75yuVEMim6FxZ7u6sRk+4PpL/WzCLC2PpPxP/AyiFRh4zw7Q34HDNm xPe4Nfzt5vDj0/2HYMY0q0UeSfVY/U0iB3TWmV/3HFObaLeibCgHqOFGmtCpHw5/ EXJX36mpffO1wI6ImPAvQ9C/wE6/JdoL8R3EPrsN3hdNmoVNIrnDuaeAwiQM6Ljm 4CHzsqlYYzyjzgyMmmJahaZ3Lrr0IjnVixC3/z46SfpPipaua8Pr+oZozC4WFmnn 4IhsXH+XK7fTbKQaZML6o9j6Bm0hs9g6mt+VSWCYWGCHh/V3DzTuH2BECUeC8lsD 9pwHv4x4vPbh7d/kBwAl75mOe3etb8nD/+i+x0oqbPn0T73DgdGgYPnIKqElOi4Y Ws6uw/Euno3YnSSds5Eb =FJZe -END PGP SIGNATURE- ___ 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 ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
On 2/3/15 5:30 PM, Lev Serebryakov wrote: looking at my own rules I don't seem to have a problem.. You have check-state only once, on entrance, before all NATs, so it could work only for packets which don't need NAT. And looks like (correct me if I'm wrong) you don't try to track states of connections passed through NAT. yes, because NAT is a stateful filter so it's a duplication - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
On Tue, 3 Feb 2015 13:23:38 +0300, Lev Serebryakov wrote: On 03.02.2015 13:04, Ian Smith wrote: Now to make stateful firewall with NAT you need to make some not very readable tricks to record state (allow) of outbound connection before NAT, but pass packet to NAT after that. I know two: (a) skipto-nat-allow pattern from many HOWOTOs Lev, can you provide references for these HOWTOs you refer to? I have a suspicion that some of them should be taken out and shot. google for FreeBSD ipfw nat stateful :) There are lot of them. Not real HOWTOs, but blog posts alike. As I suspected, most of them either are or refer to or are based on the handbook IPFW page, which I believe has caused more damage to the cause of IPFW adoption and usage than anything else. ipfw(8) is your friend, and pretty much your only friend in this regard. Of those, https://nileshgr.com/2014/12/07/freebsd-ipfw-nat-jails isn't bad. Many of the others are up to 10 years old and not much help. http://www.pl.freebsd.org/doc/handbook/firewalls-ipfw.html is an earlier version of https://www.freebsd.org/doc/handbook/firewalls-ipfw.html which has undergone significant improvement lately (compare), but still contains factual errors in the rulesets and very muddle-headed ideas regarding syslog and other things, IMHO. I'd best say no more on this topic; you can't discombobulate confusion. Cheers, Ian out BTW, without new mechanism it is really hard to do such firewall, as we need action (nat) after allow keep-state. It could be done with this ugly skip-to or with allow keep-state in INCOMING section of firewall, what is not much better, as I prefer to decide let packet out or not in OUTCOMING part of firewall and with allow keep-state in incoming path it flood state table with unused states. Another problem, that keep-state acts as check-state too, so you could not have ANOTHER keep-state before NAT in outgoing part or you miss nat completely (sate is created in outgoing path, and then checked before nat in outgoing path with keep-state, gr, ugly!). - -- // Lev Serebryakov AKA Black Lion ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03.02.2015 13:04, Ian Smith wrote: Now to make stateful firewall with NAT you need to make some not very readable tricks to record state (allow) of outbound connection before NAT, but pass packet to NAT after that. I know two: (a) skipto-nat-allow pattern from many HOWOTOs Lev, can you provide references for these HOWTOs you refer to? I have a suspicion that some of them should be taken out and shot. google for FreeBSD ipfw nat stateful :) There are lot of them. Not real HOWTOs, but blog posts alike. BTW, without new mechanism it is really hard to do such firewall, as we need action (nat) after allow keep-state. It could be done with this ugly skip-to or with allow keep-state in INCOMING section of firewall, what is not much better, as I prefer to decide let packet out or not in OUTCOMING part of firewall and with allow keep-state in incoming path it flood state table with unused states. Another problem, that keep-state acts as check-state too, so you could not have ANOTHER keep-state before NAT in outgoing part or you miss nat completely (sate is created in outgoing path, and then checked before nat in outgoing path with keep-state, gr, ugly!). - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KGqXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePYvYQALeGCF9EuZKP3jLDaRwad+TO IhYq5I3xPPqU3eNEdQ6OqdFonVQ4mDB+UipZzspC/U5drf1qo2LkOF8oBNDlVDW4 2I+bgYStptIkpSoBOe5AGRYwO3jfec77GvXhR8cMeQZK2Z9NIazn5ZtFkdQyiiDU +b7pxBQ0SbbMUT3hubl4H+v93dMGfjnzrFg1aSY4/uYnmilb8plWN1o4BshZVMSz z1lrFSaorj4RNYxnpM6f6YtDDYx4TahA7+OILl/BvzmNoztWb5hKNX+1TGLZPcch QE19iix+8O75yuVEMim6FxZ7u6sRk+4PpL/WzCLC2PpPxP/AyiFRh4zw7Q34HDNm xPe4Nfzt5vDj0/2HYMY0q0UeSfVY/U0iB3TWmV/3HFObaLeibCgHqOFGmtCpHw5/ EXJX36mpffO1wI6ImPAvQ9C/wE6/JdoL8R3EPrsN3hdNmoVNIrnDuaeAwiQM6Ljm 4CHzsqlYYzyjzgyMmmJahaZ3Lrr0IjnVixC3/z46SfpPipaua8Pr+oZozC4WFmnn 4IhsXH+XK7fTbKQaZML6o9j6Bm0hs9g6mt+VSWCYWGCHh/V3DzTuH2BECUeC8lsD 9pwHv4x4vPbh7d/kBwAl75mOe3etb8nD/+i+x0oqbPn0T73DgdGgYPnIKqElOi4Y Ws6uw/Euno3YnSSds5Eb =FJZe -END PGP SIGNATURE- ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03.02.2015 12:30, Lev Serebryakov wrote: keep-state. Problem is, it adds if branch for EACH action (in kernel code). IMHO, it is very prohibitive. I've though about that, but decide it is too expensive to have if (!iHaveRecordOnly || fromDynamic) for EACH action, always. It could be done easily, of course. Oh, I'm stupid! I know how to do keep-state-only cheap for fast path! I'll prepare new patch today or tomorrow. Also, I BADLY want keep-state-but-dont-check one. Sometimes it adds couple of skipto rules to avoid keep-state because it will trigger check too, even if MATCH will fail. - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KJTXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTEMP/R3MZ8AmqKA0h7pFPy5SCwjT /zhnjjRvk+sDpc5BJPA/xIXV8IBupCPBCDR8CvCcqbaxFBECTTbW+JHCaHB0idXf F7lI2fTjiXcx5EK3E1RkjJ8dbRuHLAiYttMA4e1YIZBidsflgX/wLIEexseeia1K Vqh0NLofJLgzZET+wDbDBNncgWSaUnyJyW05BtVDUi/kpHekpZg4zm71gfWAoLgl tROv3i0y1YfkulwzZ84BcegsEAPMqD11AhSYZayeF1Ozl5jBGXTpC4rhaOQNYl7n +Hcr828rOZFiP/b4p/QhHx0TAMdYm3oqxSXMtr8GzWK+q5cClk7vdBv2Nj2W5f43 jOaJhDHgy21HxKCmFKKvSg/ZMb43F21ZHh0hU4eVlAK+AH74cli8hISTzZo4KxwC g74vUIPQkKs177UB+Hx1ADxwmur9fzbJpWWcK5zd/bLKQ8klUfiVrXp4awqLHma5 z6mKH89pxG9IC8rHFODetgfyvCJCiI0VY8bYuR8zJ6ciyk4NLGVhLk/VlzPyap8Y IT8O+kYLCaOWPbJvR+Zqti+hnvsk+5JnGxa16tVUkxXiJfh7VfWt9dDQ12Z9At1t srjr79R9yEJ0aPYKZRT4Z3q+CPhJZ+TpZyCxX3QT0vJuzewrj+R0CwSPP2xaWUZ3 x+Z6nsvc0bx37IgR7vsx =DlMK -END PGP SIGNATURE- ___ 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: [RFC][patch] Two new actions: state-allow and state-deny
On Mon, 2 Feb 2015 22:17:25 +0300, Lev Serebryakov wrote: Now to make stateful firewall with NAT you need to make some not very readable tricks to record state (allow) of outbound connection before NAT, but pass packet to NAT after that. I know two: (a) skipto-nat-allow pattern from many HOWOTOs Lev, can you provide references for these HOWTOs you refer to? I have a suspicion that some of them should be taken out and shot. 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: [RFC][patch] Two new actions: state-allow and state-deny
On 2/3/15 3:17 AM, Lev Serebryakov wrote:
I propose two new actions: state-allow and state-deny.
They imply keep-state and create new dynamic rules, when called
directly, but pass packet to NEXT rule after that (don't stop search).
When they are called as dynamic rule, they acts as allow and deny.
So, stateful firewall with NAT could be rewritten like this:
add 1000 skipto 2000 all from any to any out xmit outIface
add 1010 skipto 3000 all from any to any in recv outIface
add 2000 state-allow from any to any // keep-state is implied
add 2010 nat NR from any to any // No out here!
add 2020 allow all from any to any
add 3000 nat NR from any to any
add 3010 check-state // Use dynamic rule based on 2000 as allow here
What do you think?
I understand what you are trying to do..
but part of the usefulness of the state runes is that they
can be any action, not just allow and deny.
I might try the following action:
record: (or record-only)
it allows the rule to be stored, but the action is not performed.
on check-state, the rule is performed..
so skipto 2000 ip from me to fred 80 record-only out xmit bge0
would do nothing but record the session
and on input the session packet would skipto 2000
you could do deny or accept as well so it's a superset of what you
suggest.
I'm not sure where in the rule record-only shoudl be put..
maybe
ipfw add 1000 log record-only skipto 2000 tcp from me to fred 80,443
out xmit bge0
might be more syntactically correct?
What I would find more useful, is separate state rules for each interface.
so you could not have the danger of a packet on interface A adding a
rule that eventually does something unexpected on a packet on interface B.
looking at my own rules I don't seem to have a problem..
Just for kicks,
here is the base ipfw script.. just sets up the framework
---
#!/bin/sh
fwcmd=/sbin/ipfw
# Suck in the configuration variables.
if [ -z ${source_rc_confs_defined} ]; then
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
source_rc_confs
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
fi
# set these to your outside interface network and netmask and ip
oif=tun0
onet=192.168.36.0
omask=24
oip=x.x.x.x
# set these to your inside interface network and netmask and ip
iif=vr0
inet=192.168.2.0
imask=255.255.255.0
iip=192.168.2.21
# for not the natd target is us but change this if you
# change that in natd.conf
natd_target=${oip}
work_vpnserver=y.y.y.y
INCOMING=4000
OUTGOING=8000
LOCAL=1000
SET=1
sysctl net.inet.ip.fw.enable=0
${fwcmd} -q flush
${fwcmd} -q table 1 flush
${fwcmd} -q table 2 flush
${fwcmd} -q table 3 flush
${fwcmd} -q table 4 flush
${fwcmd} table 1 add 10.0.0.0/8
${fwcmd} table 1 add 172.16.0.0/12
#${fwcmd} table 1 add 192.168.0.0/16
# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes
# RESERVED-1, DHCP auto-configuration, NET-TEST, MULTICAST
(class D),
# and class E) on the outside interface
${fwcmd} table 1 add 0.0.0.0/8
${fwcmd} table 1 add 169.254.0.0/16
${fwcmd} table 1 add 192.0.2.0/24
${fwcmd} table 1 add 224.0.0.0/4
${fwcmd} table 1 add 240.0.0.0/4
# add legit sources of ssh.. DNS is not up yet so use IPs
# could add to /etc/hosts I guess.
# myotherhouse.org
${fwcmd} table 2 add a.b.c.d
# work
${fwcmd} table 2 add c.d.e.f/24
# my vps
${fwcmd} table 2 add f.g.h.i/24
# add legit DNS tcp (zone) sources
# my.dns.friends
${fwcmd} table 3 add m.n.o.p
# my.dns.friend
${fwcmd} table 3 add q.r.s.t
# my.vps
${fwcmd} table 3 add f.g.h.i
# Add our local networks here
${fwcmd} table 4 add 192.168.2.0/24
${fwcmd} table 4 add 172.16.15.0/24
# common spoofing code
# --- ALL PACKETS START HERE.
${fwcmd} set disable ${SET}
# Stop localhost spoofing
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny log all from any to 127.0.0.0/8
${fwcmd} add 300 deny log ip from 127.0.0.0/8 to any
# If we've already decided on it. keep our word.
${fwcmd} add check-state
# Interception rules for external interfaces go here ---
# Internal traffic. generally don't care
# except to stop spoofing.
# make extra sure we don't block DHCP to our server (me)
# as initial request will be from 0.0.0.0/0
${fwcmd} add ${LOCAL} set ${SET} allow udp from any to any 67
in recv ${iif}
${fwcmd} add allow udp from any 67 to any out xmit ${iif}
# other wise it has to be to
Re: [RFC][patch] Two new actions: state-allow and state-deny
*cool, I like this, it got some points.*
*though the email is too long to be read.*
On 3 February 2015 at 14:44, Julian Elischer jul...@freebsd.org wrote:
On 2/3/15 3:17 AM, Lev Serebryakov wrote:
I propose two new actions: state-allow and state-deny.
They imply keep-state and create new dynamic rules, when called
directly, but pass packet to NEXT rule after that (don't stop search).
When they are called as dynamic rule, they acts as allow and deny.
So, stateful firewall with NAT could be rewritten like this:
add 1000 skipto 2000 all from any to any out xmit outIface
add 1010 skipto 3000 all from any to any in recv outIface
add 2000 state-allow from any to any // keep-state is implied
add 2010 nat NR from any to any // No out here!
add 2020 allow all from any to any
add 3000 nat NR from any to any
add 3010 check-state // Use dynamic rule based on 2000 as allow here
What do you think?
I understand what you are trying to do..
but part of the usefulness of the state runes is that they
can be any action, not just allow and deny.
I might try the following action:
record: (or record-only)
it allows the rule to be stored, but the action is not performed.
on check-state, the rule is performed..
so skipto 2000 ip from me to fred 80 record-only out xmit bge0
would do nothing but record the session
and on input the session packet would skipto 2000
you could do deny or accept as well so it's a superset of what you
suggest.
I'm not sure where in the rule record-only shoudl be put..
maybe
ipfw add 1000 log record-only skipto 2000 tcp from me to fred 80,443 out
xmit bge0
might be more syntactically correct?
What I would find more useful, is separate state rules for each interface.
so you could not have the danger of a packet on interface A adding a rule
that eventually does something unexpected on a packet on interface B.
looking at my own rules I don't seem to have a problem..
Just for kicks,
here is the base ipfw script.. just sets up the framework
---
#!/bin/sh
fwcmd=/sbin/ipfw
# Suck in the configuration variables.
if [ -z ${source_rc_confs_defined} ]; then
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
source_rc_confs
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
fi
# set these to your outside interface network and netmask and ip
oif=tun0
onet=192.168.36.0
omask=24
oip=x.x.x.x
# set these to your inside interface network and netmask and ip
iif=vr0
inet=192.168.2.0
imask=255.255.255.0
iip=192.168.2.21
# for not the natd target is us but change this if you
# change that in natd.conf
natd_target=${oip}
work_vpnserver=y.y.y.y
INCOMING=4000
OUTGOING=8000
LOCAL=1000
SET=1
sysctl net.inet.ip.fw.enable=0
${fwcmd} -q flush
${fwcmd} -q table 1 flush
${fwcmd} -q table 2 flush
${fwcmd} -q table 3 flush
${fwcmd} -q table 4 flush
${fwcmd} table 1 add 10.0.0.0/8
${fwcmd} table 1 add 172.16.0.0/12
#${fwcmd} table 1 add 192.168.0.0/16
# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes
# RESERVED-1, DHCP auto-configuration, NET-TEST, MULTICAST (class
D),
# and class E) on the outside interface
${fwcmd} table 1 add 0.0.0.0/8
${fwcmd} table 1 add 169.254.0.0/16
${fwcmd} table 1 add 192.0.2.0/24
${fwcmd} table 1 add 224.0.0.0/4
${fwcmd} table 1 add 240.0.0.0/4
# add legit sources of ssh.. DNS is not up yet so use IPs
# could add to /etc/hosts I guess.
# myotherhouse.org
${fwcmd} table 2 add a.b.c.d
# work
${fwcmd} table 2 add c.d.e.f/24
# my vps
${fwcmd} table 2 add f.g.h.i/24
# add legit DNS tcp (zone) sources
# my.dns.friends
${fwcmd} table 3 add m.n.o.p
# my.dns.friend
${fwcmd} table 3 add q.r.s.t
# my.vps
${fwcmd} table 3 add f.g.h.i
# Add our local networks here
${fwcmd} table 4 add 192.168.2.0/24
${fwcmd} table 4 add 172.16.15.0/24
# common spoofing code
# --- ALL PACKETS START HERE.
${fwcmd} set disable ${SET}
# Stop localhost spoofing
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny log all from any to 127.0.0.0/8
${fwcmd} add 300 deny log ip from 127.0.0.0/8 to any
# If we've already decided on it. keep our word.
${fwcmd} add check-state
# Interception rules for external interfaces go here ---
# Internal traffic. generally don't care
# except to stop spoofing.
# make extra sure we don't block
