RE: ipfw/nated stateful rules example
You must have missed reading some parts of the thread. The problem is not whether you just do keep-state on the public side or the private side, it's with doing keep-state on both sides at the same time from within ipfw along with using divert statement. The stated problem is ipfw1 and ipfw2 does not work when keep-state rules are used on an single interface along with divert/nated. They do work if divert/nated is not used and user ppp nat is used to perform the nat function. As far as the question of using keep-state rules on both the private and public interfaces this is cross population of the single stateful table and returning packets are being matched to entries in the stateful table which do not belong to the interface the original enter was posted from. This is an logic error and invalidates the function of the purpose of the whole stateful concept. -Original Message- From: Jonathan Chen [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 12:20 AM To: fbsd_user Cc: Micheal Patterson; [EMAIL PROTECTED] Subject: Re: ipfw/nated stateful rules example On Tue, Jan 20, 2004 at 09:18:27PM -0500, fbsd_user wrote: Yes you are making it work, but not work correctly. In the true security sense, this is un-secure and invalidates the whole purpose of using keep-state rules at all. This would never be allowed by an real firewall security professional. I'm curious as to why you'd consider it insecure. How would applying the keep-state rules on the public IP be anymore secure that using it on the internal IP? The mechanism works the same regardless. You haven't provided an case as to why you think it is unsecure. -- Jonathan Chen [EMAIL PROTECTED] -- Don't worry about avoiding temptation, as you grow older, it starts avoiding you. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
- Original Message - From: fbsd_user [EMAIL PROTECTED] To: Jonathan Chen [EMAIL PROTECTED] Cc: Micheal Patterson [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 7:29 AM Subject: RE: ipfw/nated stateful rules example You must have missed reading some parts of the thread. The problem is not whether you just do keep-state on the public side or the private side, it's with doing keep-state on both sides at the same time from within ipfw along with using divert statement. If you have multiple lans (which in effect you do in my situation) you state inspect traffic into and out of each network. The stated problem is ipfw1 and ipfw2 does not work when keep-state rules are used on an single interface along with divert/nated. They do work if divert/nated is not used and user ppp nat is used to perform the nat function. They also work if NAT is used. That's because keep-state monitors the source of the packet and relies on that. So what you're telling me is that you'd prefer a masqueraded IP to be the source for all of your stateful inspections instead of the true tcp source? And you feel that is more secure than applying stateful to the true source of the traffic prior to network translation? As far as the question of using keep-state rules on both the private and public interfaces this is cross population of the single stateful table and returning packets are being matched to entries in the stateful table which do not belong to the interface the original enter was posted from. This is an logic error and invalidates the function of the purpose of the whole stateful concept. It's not cross population of the stateful table. It's how stateful works with multiple networks. Regardless if you are running NAT or not, if you have 3 /24's behind your firewall, do you expect to secure them all by simply having stateful on the firewall's wan port? What keeps them from infiltrating each other? Don't make the assumption that all are welcome behind the firewall. You treat them as entirely separate networks unless otherwise stated. Now, what's going to happen to your stateful table then? It's going to be so cross populated with traffic from 762 other systems that you'll not see straight. -- Micheal Patterson TSG Network Administration 405-917-0600 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
Micheal Patterson wrote: Whereas what I'm doing Private LAN Keep-State NAT World is not secure and would not be accepted by a security professional? How do you figure that either method is more or less secure than the other? If stateful is breached in either method, the underlying network is compromised. Sorry, it's late and I may be missing something but I just don't see it. I haven't checked your specific example, but in theory is nothing wrong with this at all. One of my examples works the same way. Packets you didn't ask for don't get through. How much more security can you want? As for breaching the dynamic rules you would, I think, have to spoof at least the target IP and probably more, in which case any firewall could succumb. Personally, I am filing away the various example for future use, and calling this topic closed. Thanks to everyone who posted solutions. I for one am grateful. --Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ipfw/nated stateful rules example
You do what ever you want. But typically the private LANS are considered secure and only the interface facing the public internet needs stateful processing. What you are doing is an waste of resources and corrupts the stateful table no matter what you think. But the fact still remains that stateful processing on only the public facing interface with divert/nated does not work period. I an finished with this subject. I have made me case and nobody has been able to prove otherwise. Hope the ipfw2 maint team members have been reading this thread and do something to correct this problem, like copy the ipnat code and make it their own so it works with ipfw2. As an side note, I do not use ipfw1 or ipfw 2, I now use IPFILTER because it does not have this problem and I want an software solution that provides the MAX protection which ipfw does not. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Micheal Patterson Sent: Wednesday, January 21, 2004 11:09 AM To: [EMAIL PROTECTED] Subject: Re: ipfw/nated stateful rules example - Original Message - From: fbsd_user [EMAIL PROTECTED] To: Jonathan Chen [EMAIL PROTECTED] Cc: Micheal Patterson [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 7:29 AM Subject: RE: ipfw/nated stateful rules example You must have missed reading some parts of the thread. The problem is not whether you just do keep-state on the public side or the private side, it's with doing keep-state on both sides at the same time from within ipfw along with using divert statement. If you have multiple lans (which in effect you do in my situation) you state inspect traffic into and out of each network. The stated problem is ipfw1 and ipfw2 does not work when keep-state rules are used on an single interface along with divert/nated. They do work if divert/nated is not used and user ppp nat is used to perform the nat function. They also work if NAT is used. That's because keep-state monitors the source of the packet and relies on that. So what you're telling me is that you'd prefer a masqueraded IP to be the source for all of your stateful inspections instead of the true tcp source? And you feel that is more secure than applying stateful to the true source of the traffic prior to network translation? As far as the question of using keep-state rules on both the private and public interfaces this is cross population of the single stateful table and returning packets are being matched to entries in the stateful table which do not belong to the interface the original enter was posted from. This is an logic error and invalidates the function of the purpose of the whole stateful concept. It's not cross population of the stateful table. It's how stateful works with multiple networks. Regardless if you are running NAT or not, if you have 3 /24's behind your firewall, do you expect to secure them all by simply having stateful on the firewall's wan port? What keeps them from infiltrating each other? Don't make the assumption that all are welcome behind the firewall. You treat them as entirely separate networks unless otherwise stated. Now, what's going to happen to your stateful table then? It's going to be so cross populated with traffic from 762 other systems that you'll not see straight. -- Micheal Patterson TSG Network Administration 405-917-0600 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
On Wed, Jan 21, 2004 at 08:29:32AM -0500, fbsd_user wrote: [...] As far as the question of using keep-state rules on both the private and public interfaces this is cross population of the single stateful table and returning packets are being matched to entries in the stateful table which do not belong to the interface the original enter was posted from. This is an logic error and invalidates the function of the purpose of the whole stateful concept. A logic error is only there is something doesn't work. The proposed solution works, so there is no logic error. I can't see how the stateful concept has been invalidated - the mechanism works as intended. What you've presented is a matter of opinion rather than any concrete example as to why the proposed solution is insecure. -- Jonathan Chen [EMAIL PROTECTED] -- The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
Ken Bolingbroke wrote: I just jumped in the middle here, so I may be out of context. But, stateful rules don't play nice with NAT. You're quite right, they don't play nice at all. [EMAIL PROTECTED] wrote: I disagree with you that the /etc/rc.firewall is the best example. It's really a good example of stateless rules, how to use scripting Symbolic substitution. I found it OK for stateful rules, as long as you don't use natd! I couldn't find any examples *anywhere* of how to get it to work. So I posted on a newsgroup a while back and got a working idea (see below) and in the meantime came up with one of my own. I found it really helpful to draw a little picture of the gateway machine and its interfaces and trace how packets went out including the natd in the middle. When working with natd you really do have to consider packets that come in/out your *internal* network interface. Without natd you can effectively ignore them (which all examples do). Note that in a standard setup it's a little more complicated since packets that come in from the local network get nat'ed whereas packets originating from the gateway machine don't. Anyway, here's my final message on the topic which contains two ways you might go. I have extensively traced the packets on the second, less elegant solution and it really does work. Michael Sierchio wrote: Alex wrote: The basic thrust of the problematic section is: ipfw add divert natd all from any to any via external_interface ipfw add pass udp from any to any ntp out xmit external_interface ipfw add pass udp from any ntp to any ntp in recv external_interface Try this: # local rules for this gateway's traffic (hope DF is set for UDP) ipfw add allow udp from me to any out xmit $ext_if keep-state # divert ipfw add divert natd ip from any to any via $ext_if # this rule looks a bit strange here, but it's to allow the # nat-ed packets outbound to leave. If you're concerned about # egress filtering from the gateway itself, add appropriate # non-stateful allow rules ipfw add allow ip from me to any out xmit $ext_if ipfw add check-state ipfw add allow udp from any to any in recv $int_if keep_state Putting the keep-state on the internal ethernet is a neat solution, thanks. (It conflicts somewhat with some of the way my firewall is set up prior to the ntp/natd stuff, but I'm looking at rewriting that). I did think of one more solution which works on the external interface only, but it's not as elegant. # Check all inbound ntp calls ipfw add skipto 20500 udp from any ntp to any in recv $ext_if # Checks all outbound ntp calls and (by dynamic rule) all inbound ntp calls ipfw add skipto 2 udp from any to any out xmit $ext_if keep-state [ rest of firewall including natd go here ] # Make sure we do not fall through into special rulesets add deny log all from any to any # Only get to these rules in two circumstances: # 1) Any outbound ntp packet which has been keep-state'ed # 2) Any inbound ntp packet which matched a dynamic rule ipfw add 2 divert natd all from any to any out xmit $ext_if ipfw add allow udp from any ntp to any in recv $ext_if ipfw add allow udp from any to any ntp out xmit $ext_if ipfw add deny log all from any to any # Only get here on an incoming ntp packet. Need to see # if we want to accept it or not. Check-state will # trigger dynamic rule and skipto 2 on match ipfw add 20500 divert natd all from any to any in recv ${ext_if} ipfw add check-state ipfw add deny log all from any to any --Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ipfw/nated stateful rules example
As the original poster of this thread, I want to say thank you to Ken Bolingbroke who posted his rule set and to the other posters who voiced their comments. I want to point out that Ken Bolingbroke acknowledged that has work around of doing keep-state on both the Lan interface and the public interface only works because the returning public packet is being matched by stateful table entries posted from the Lan interface keep-state rules. Yes he provided he could make it work, but not work correctly. In the true security sense, this is un-secure and invalidates the whole purpose of using keep-state rules at all. I an surprised that I have not yet heard the old timers dogma that the Nated process it self is really performing an keep-state like process and that is why keep-state does not work with divert/Natd. There is some truth to that because the Nat process does have to keep it's own internal table to remap IP address, but it just blindly does the mapping with out any regard to if the packet belongs to an authorized session conversation, like the keep-state function does. The conclusion so far is that ipfw1 and ipfw2 using keep-state rules on the interface facing the public internet with divert/nated does not work period. By all accounts this is an long time bug propagated by the continued use of the legacy divert keyword sub-routine call to ipfw's userland Natd function. The using of keep-state rules on the interface facing the public internet is restricted to situations where there are no Lans behind the ipfw firewall or when 'user ppp' -NAT function is used. I have tested using ipnat as an front end to ipfw with keep-state but that also ends up handing off the packet to ipfw at the wrong time. Now that ipfw2 has replaced ipfw1 in 5.2, maybe some of that ipfw2 programming teams effort can be directed at fixing this problem. The IPNAT code of IPFILTER runs in the kernel and could be modified to be ipfw2's external Nat function. So firewall users who want the maximum level of protection have to use IPFILTER. IPFILTER has had the keep state function long before the keep-state option was ever added to ipfw1. Still would like to be provided wrong on my conclusion. -Original Message- From: Micheal Patterson [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 12:50 AM To: Ken Bolingbroke; fbsd_user Cc: [EMAIL PROTECTED] Subject: Re: ipfw/nated stateful rules example - Original Message - From: Ken Bolingbroke [EMAIL PROTECTED] To: fbsd_user [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 19, 2004 10:28 PM Subject: RE: ipfw/nated stateful rules example On Mon, 19 Jan 2004, fbsd_user wrote: That's a play on words. And still does not prove stateful rules work on the interface facing the public internet. There is no documentation that says keep-state and limit only works on the interface facing the private Lan network. And the implied meaning is they are to be used on the interface facing the public internet. I just jumped in the middle here, so I may be out of context. But, stateful rules don't play nice with NAT. Consider non-NAT, a public IP address contacting an Internet address: 67.161.59.61 - 66.218.71.91 A rule is created for 66.218.71.91 coming to 67.161.59.61. When 66.218.71.91 replies, the stateful rule lets it in. This is good. But consider NAT: 10.0.0.10 changed to 67.161.59.61 - 66.218.71.91 If you do a keep-state before NAT, you have a rule to allow 66.218.71.91 to 10.0.0.10, but the return incoming packet will be 66.218.71.91 - 67.161.59.61, so the rule doesn't match. If you do a keep-state after NAT, then you have a rule to allow 66.218.71.91 to 67.161.59.61. The return incoming packet matches that rule, but it accepts the packet and packet processing stops, so it's never passed through NAT, and never makes it back to 10.0.0.10. So as it stands now, I don't see that you can use stateful connections with NAT, unless check-state is changed to allow a packet to be passed through NAT. Ken Bolingbroke Ken, try this one. This is what I use here at home and it does indeed work: Launch NATD with natd -interface ep0 -s -m -u (Only RFC1918 packets get altered) ## Divert everything to NAT. ipfw add 1 divert natd ip from any to any via ep0 #Prevent inbound spoof attempts for my lan range ipfw add 10 deny ip from 192.168.1.0/24 to any in via ep0 #Check State Rules ipfw add 20 check state #LAN Allow Stateful ipfw add 31 allow ip from 192.168.1.0/24 to any keep-state #Allow Outbound Stateful. ipfw add 40 allow ip from 68.12.xx.xx to any keep-state NAT keeps a seperate table of it's translations to provide a back channel. Traffic comes in, generates a dynamic ruleset, gets translated, heads out and creates the 2nd dynamic for the packet. You'll end up with something like this ipfw -d list snip ## Dynamic rules: 00040 4 692 (T 18, slot 215) - tcp, 68.12.xx.xx3777- 216.239.57.99 80 00031 35 20374 (T 10
Re: ipfw/nated stateful rules example
fbsd_user wrote: The conclusion so far is that ipfw1 and ipfw2 using keep-state rules on the interface facing the public internet with divert/nated does not work period. Probably my post hasn't reached you yet. I think you are mistaken if you mean that keep-state rules cannot be securely used in a NAT configuration -- see two examples in my post. The mistake I believe you are making is in talking about only the public-internet facing interface. What you are trying to do is to ensure that *conversations* from anywhere on your internal network can be keep-stated when talking to the external network. But the packets *start* on the internal facing interface. It just so happens that without NAT you can ignore this bit of the conversation, but once you include it, you cannot. In any case, my somewhat messy example which puts the keep-state on a skipto rule still manages without *looking* at the internal interface, though it does take into consideration the whole conversation. Still would like to be proved wrong on my conclusion. If you find any bugs in the two alternatives I posted then I would love to know. --Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ipfw/nated stateful rules example
Alex Yep I missed you previous post, this lists mail has increased since 5.2 showed up on the FTP sites and I just missed your post in all volume. First of all the method of doing keep-state on both the internal Lan interface and the external is an violation of security protocol because the packets are being allowed to pass based on stateful info posted by the wrong interface. This method is an example of making the firewall function incorrectly which is not the goal of an secure firewall. The method is discard as not viable. Now on to your second method of coding the rules file with gymnasiast goto statements. From an user view point, this kind of coding should not be necessary just to get keep-state rules to function. And if it is necessary then it should be so documented in man ipfw that way and a working example should be included in /etc along the other example. That being said, lets look at what you posted. this first part has already been address and discarded The basic thrust of the problematic section is: ipfw add divert natd all from any to any via external_interface ipfw add pass udp from any to any ntp out xmit external_interface ipfw add pass udp from any ntp to any ntp in recv external_interface Try this: # local rules for this gateway's traffic ipfw add allow udp from me to any out xmit $ext_if keep-state # divert ipfw add divert natd ip from any to any via $ext_if # this rule looks a bit strange here, but it's to allow the # nat-ed packets outbound to leave. If you're concerned about # egress filtering from the gateway itself, add appropriate # non-stateful allow rules ipfw add allow ip from me to any out xmit $ext_if ipfw add check-state ipfw add allow udp from any to any in recv $int_if keep_state Putting the keep-state on the internal ethernet is a neat solution, thanks. (It conflicts somewhat with some of the way my firewall is set up prior to the ntp/natd stuff, but I'm looking at rewriting that). start of second method * I did think of one more solution which works on the external interface only, but it's not as elegant. # Check all inbound ntp calls ipfw add skipto 20500 udp from any ntp to any in recv $ext_if # Checks all outbound ntp calls and (by dynamic rule) all inbound ntp calls ipfw add skipto 2 udp from any to any out xmit $ext_if keep-state [ rest of firewall including natd go here ] # Make sure we do not fall through into special rulesets add deny log all from any to any # Only get to these rules in two circumstances: # 1) Any outbound ntp packet which has been keep-state'ed # 2) Any inbound ntp packet which matched a dynamic rule ipfw add 2 divert natd all from any to any out xmit $ext_if ipfw add allow udp from any ntp to any in recv $ext_if ipfw add allow udp from any to any ntp out xmit $ext_if ipfw add deny log all from any to any # Only get here on an incoming ntp packet. Need to see # if we want to accept it or not. Check-state will # trigger dynamic rule and skipto 2 on match ipfw add 20500 divert natd all from any to any in recv ${ext_if} ipfw add check-state ipfw add deny log all from any to any end of second method * First of all the first skipto rule ipfw add skipto 20500 udp from any ntp to any in recv $ext_if ipfw add skipto 2 all from any to any out xmit $ext_if keep-state uses ntp as an port name on the from object. Ntp is the name given in /etc/services for port number 123 which is the tcp time network protocol. This has to be an typo as there is no way this can have any meaning about what we are talking about. So I will take ntp to mean an symbolic as in $ntp which holds the private ip address of Lan network. Looking closer at your skipto rules they only executes on udp packets and the second statement has keep state on it. Plus your skipto locations are using stateless rules There is no use going any further, this is non-logical all ready. When and if you can get your shipto method to only use stateful rules and the check-state rule to process the divert rule correctly then you will have something to talk about. Until them, my statement still stands. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
- Original Message - From: fbsd_user [EMAIL PROTECTED] To: Micheal Patterson [EMAIL PROTECTED]; Ken Bolingbroke [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 8:41 AM Subject: RE: ipfw/nated stateful rules example As the original poster of this thread, I want to say thank you to Ken Bolingbroke who posted his rule set and to the other posters who voiced their comments. I want to point out that Ken Bolingbroke acknowledged that has work around of doing keep-state on both the Lan interface and the public interface only works because the returning public packet is being matched by stateful table entries posted from the Lan interface keep-state rules. Yes he provided he could make it work, but not work correctly. In the true security sense, this is un-secure and invalidates the whole purpose of using keep-state rules at all. I an surprised that I have not yet heard the old timers dogma that the Nated process it self is really performing an keep-state like process and that is why keep-state does not work with divert/Natd. There is some truth to that because the Nat process does have to keep it's own internal table to remap IP address, but it just blindly does the mapping with out any regard to if the packet belongs to an authorized session conversation, like the keep-state function does. The conclusion so far is that ipfw1 and ipfw2 using keep-state rules on the interface facing the public internet with divert/nated does not work period. By all accounts this is an long time bug propagated by the continued use of the legacy divert keyword sub-routine call to ipfw's userland Natd function. The using of keep-state rules on the interface facing the public internet is restricted to situations where there are no Lans behind the ipfw firewall or when 'user ppp' -NAT function is used. I have tested using ipnat as an front end to ipfw with keep-state but that also ends up handing off the packet to ipfw at the wrong time. Now that ipfw2 has replaced ipfw1 in 5.2, maybe some of that ipfw2 programming teams effort can be directed at fixing this problem. The IPNAT code of IPFILTER runs in the kernel and could be modified to be ipfw2's external Nat function. So firewall users who want the maximum level of protection have to use IPFILTER. IPFILTER has had the keep state function long before the keep-state option was ever added to ipfw1. Still would like to be provided wrong on my conclusion. Again I'll use this simple ruleset as a base. I've just used it on my network here at home to test for stateful inspection. ## Divert everything to NAT. ipfw add 1 divert natd ip from any to any via ep0 #Prevent inbound spoof attempts for my lan range ipfw add 10 deny ip from 192.168.1.0/24 to any in via ep0 #Check State Rules ipfw add 20 check-state #Stateful Test Deny Rule ipfw add 25 deny log ip from any to any in via ep0 #LAN Allow Stateful ipfw add 31 allow ip from 192.168.1.0/24 to any keep-state #Allow Outbound Stateful. ipfw add 40 allow ip from 68.12.xx.xx to any keep-state #Default Deny ipfw add 65000 deny ip from any to any In order for traffic to hit your internal network, for a packet inbound to your LAN, 2 things have to happen. 1. A NAT entry that matches source ip / port to target ip / port. 2. A stateful dynamic rule that matches the LAN ip / port pair as well. If #1. doesn't occur, the traffic is treated as if it were heading to the firewall system itself. If there's no state match, it's dropped by the default deny rule at 65000. If #1 occurs, the traffic is translated, handed back to ipfw to check for #2. If #2 exists, the traffic passes onwards to the LAN. If not, it's dropped by the deny rule at 65000. If #1 doesn't occur, the traffic is treated as if it's heading to the firewall system and is checked against state for a match for the WAN IP / Port. If there's a match, traffic is allowed. If there's no match, the traffic is dropped by the default route. If you'd like to test this, here's how. Create the firewall ruleset as above (adjusted for your setup of course). Get on the net. Run an ipfw -d list to show your statefule rules, then edit the rulset and simply comment ouf the check-state entry. Rerun your ipfw ruleset and try again. Tail your /var/log/security file and watch the denies come rolling in for rule 25. Then try it with it enabled again and you'll see that stateful is indeed working as it jumps rule 25 completely and allows the traffic to pass once you're tried to access the remote site. -- Micheal Patterson Network Administration TSG Incorporated 405-917-0600 SecureCRT 3.3.lnk Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ipfw/nated stateful rules example
You are doing keep-state on both the Lan interface and the public interface and it only works because the returning public packet is being matched to stateful table entries posted by the Lan interface keep-state rules and not the stateful table entries posted by the external interface. Yes you are making it work, but not work correctly. In the true security sense, this is un-secure and invalidates the whole purpose of using keep-state rules at all. This would never be allowed by an real firewall security professional. If you fell secure in using this method, be my guest. But know it's not really providing you protection for packets inserted by an attacker. It nullifies the benefits of keep state on the interface facing the public internet. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Micheal Patterson Sent: Tuesday, January 20, 2004 8:48 PM To: [EMAIL PROTECTED] Subject: Re: ipfw/nated stateful rules example - Original Message - From: fbsd_user [EMAIL PROTECTED] To: Micheal Patterson [EMAIL PROTECTED]; Ken Bolingbroke [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 8:41 AM Subject: RE: ipfw/nated stateful rules example As the original poster of this thread, I want to say thank you to Ken Bolingbroke who posted his rule set and to the other posters who voiced their comments. I want to point out that Ken Bolingbroke acknowledged that has work around of doing keep-state on both the Lan interface and the public interface only works because the returning public packet is being matched by stateful table entries posted from the Lan interface keep-state rules. Yes he provided he could make it work, but not work correctly. In the true security sense, this is un-secure and invalidates the whole purpose of using keep-state rules at all. I an surprised that I have not yet heard the old timers dogma that the Nated process it self is really performing an keep-state like process and that is why keep-state does not work with divert/Natd. There is some truth to that because the Nat process does have to keep it's own internal table to remap IP address, but it just blindly does the mapping with out any regard to if the packet belongs to an authorized session conversation, like the keep-state function does. The conclusion so far is that ipfw1 and ipfw2 using keep-state rules on the interface facing the public internet with divert/nated does not work period. By all accounts this is an long time bug propagated by the continued use of the legacy divert keyword sub-routine call to ipfw's userland Natd function. The using of keep-state rules on the interface facing the public internet is restricted to situations where there are no Lans behind the ipfw firewall or when 'user ppp' -NAT function is used. I have tested using ipnat as an front end to ipfw with keep-state but that also ends up handing off the packet to ipfw at the wrong time. Now that ipfw2 has replaced ipfw1 in 5.2, maybe some of that ipfw2 programming teams effort can be directed at fixing this problem. The IPNAT code of IPFILTER runs in the kernel and could be modified to be ipfw2's external Nat function. So firewall users who want the maximum level of protection have to use IPFILTER. IPFILTER has had the keep state function long before the keep-state option was ever added to ipfw1. Still would like to be provided wrong on my conclusion. Again I'll use this simple ruleset as a base. I've just used it on my network here at home to test for stateful inspection. ## Divert everything to NAT. ipfw add 1 divert natd ip from any to any via ep0 #Prevent inbound spoof attempts for my lan range ipfw add 10 deny ip from 192.168.1.0/24 to any in via ep0 #Check State Rules ipfw add 20 check-state #Stateful Test Deny Rule ipfw add 25 deny log ip from any to any in via ep0 #LAN Allow Stateful ipfw add 31 allow ip from 192.168.1.0/24 to any keep-state #Allow Outbound Stateful. ipfw add 40 allow ip from 68.12.xx.xx to any keep-state #Default Deny ipfw add 65000 deny ip from any to any In order for traffic to hit your internal network, for a packet inbound to your LAN, 2 things have to happen. 1. A NAT entry that matches source ip / port to target ip / port. 2. A stateful dynamic rule that matches the LAN ip / port pair as well. If #1. doesn't occur, the traffic is treated as if it were heading to the firewall system itself. If there's no state match, it's dropped by the default deny rule at 65000. If #1 occurs, the traffic is translated, handed back to ipfw to check for #2. If #2 exists, the traffic passes onwards to the LAN. If not, it's dropped by the deny rule at 65000. If #1 doesn't occur, the traffic is treated as if it's heading to the firewall system and is checked against state for a match for the WAN IP / Port. If there's a match, traffic is allowed. If there's no match, the traffic is dropped by the default route. If you'd like to test
Re: ipfw/nated stateful rules example
On Tue, Jan 20, 2004 at 09:18:27PM -0500, fbsd_user wrote: Yes you are making it work, but not work correctly. In the true security sense, this is un-secure and invalidates the whole purpose of using keep-state rules at all. This would never be allowed by an real firewall security professional. I'm curious as to why you'd consider it insecure. How would applying the keep-state rules on the public IP be anymore secure that using it on the internal IP? The mechanism works the same regardless. You haven't provided an case as to why you think it is unsecure. -- Jonathan Chen [EMAIL PROTECTED] -- Don't worry about avoiding temptation, as you grow older, it starts avoiding you. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
- Original Message - From: fbsd_user [EMAIL PROTECTED] To: Micheal Patterson [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 8:18 PM Subject: RE: ipfw/nated stateful rules example You are doing keep-state on both the Lan interface and the public interface and it only works because the returning public packet is being matched to stateful table entries posted by the Lan interface keep-state rules and not the stateful table entries posted by the external interface. Yes you are making it work, but not work correctly. In the true security sense, this is un-secure and invalidates the whole purpose of using keep-state rules at all. This would never be allowed by an real firewall security professional. If you fell secure in using this method, be my guest. But know it's not really providing you protection for packets inserted by an attacker. It nullifies the benefits of keep state on the interface facing the public internet. It's working because my fbsd box is in router mode and I don't want people to communicate with it's serial ip unless I request it. That's why there are two stateful entries. One to protect the serial and one to protect my lan. NAT sits happily in the middle. Let's take this to a more real world scenario though. You have the following: Cisco 3745 connected to a Sprint ATM circuit. Serial IP's: 62.121.1.2 Your side / 62.121.1.1 Sprint side. Cisco LAN: 10.0.0.1/30 Firewall WAN: 10.0.0.2/30 Firewall LAN: 64.1.1.1 The above is a generic dmz setup. Since this is on Sprint, the routers serial IP is not accessible either unless you specifically request it via their NOC so they can remove their default filters. I'm assuming that we're in agreement here. In this scenario, where would you put stateful? On the LAN side. Now, assume that this is a nat'd network with 128 IP's and you've got 200+ systems behind it. Cisco 2620 connected to Sprint DS1: Serial IP's: 62.121.1.2 Your side / 62.121.1.1 Sprint side Cisco LAN: 64.1.1.1 Firewall WAN w/NAT: 64.1.1.2 Firewall LAN: 192.168.1.0/24 In this scenario, you have NAT running on the firewall and doing the translations for the internal range. NAT sits on your WAN interface and does it's merry little thing. If I understand you correctly, you're saying that Private NAT WAN Keep-State World is the accepted manner of a network security professional and is secure. Whereas what I'm doing Private LAN Keep-State NAT World is not secure and would not be accepted by a security professional? How do you figure that either method is more or less secure than the other? If stateful is breached in either method, the underlying network is compromised. Sorry, it's late and I may be missing something but I just don't see it. -- Micheal Patterson Network Administration TSG Incorporated 405-917-0600 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
- Original Message - From: Jonathan Chen [EMAIL PROTECTED] To: fbsd_user [EMAIL PROTECTED] Cc: Micheal Patterson [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 11:20 PM Subject: Re: ipfw/nated stateful rules example On Tue, Jan 20, 2004 at 09:18:27PM -0500, fbsd_user wrote: Yes you are making it work, but not work correctly. In the true security sense, this is un-secure and invalidates the whole purpose of using keep-state rules at all. This would never be allowed by an real firewall security professional. I'm curious as to why you'd consider it insecure. How would applying the keep-state rules on the public IP be anymore secure that using it on the internal IP? The mechanism works the same regardless. You haven't provided an case as to why you think it is unsecure. -- Jonathan Chen [EMAIL PROTECTED] That's what I'm trying to figure out. As far as I can tell, it's working exactly how I want it to work. My public IP traffic is stateful from the firewall to the world and the LAN traffic is stateful to the world. I'd just like to hear what the firewall security professional would have to say about it. -- Micheal Patterson Network Administration TSG Incorporated 405-917-0600 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw/nated stateful rules example
Friends In both 4.9 and 5.2 I can not get an rules set to function that only uses keep-state' rules for outbound and inbound selection control and the divert rule. Does anybody have an rules set they can share with me as an sample for me to see. Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
fbsd_user wrote: Friends In both 4.9 and 5.2 I can not get an rules set to function that only uses keep-state' rules for outbound and inbound selection control and the divert rule. Does anybody have an rules set they can share with me as an sample for me to see. Thanks The best sample is /etc/rc.firewall [and look in /usr/share/examples/ipfw for a potentially useful script to use while testing]. I have moved over to IPFILTER due to the fact that natd is userland based and is more problematic [than ipnat] because of it. Tom Veldhouse ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ipfw/nated stateful rules example
I disagree with you that the /etc/rc.firewall is the best example. It's really a good example of stateless rules, how to use scripting Symbolic substitution. I have working keep-state rule set using user-ppp -nat, but as soon as I add that darn legacy divert rule and drop user-ppp -nat it will not work. Dynamic stateful rules table always ends up with an mis-match between public and private ip address. Moving the divert rule around only changes which ip address gets posted to the stateful table(ie: the private or public one). Test results look like that legacy divert subroutine call to NATD is the problem. See same mis-match ip address problem when stateless rules are used, but since there is no stateful table involved it just slips by un-noticed. Was hoping that the ipfw2 rewrite would have fixed this problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas T. Veldhouse Sent: Monday, January 19, 2004 1:41 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] ORG Subject: Re: ipfw/nated stateful rules example fbsd_user wrote: Friends In both 4.9 and 5.2 I can not get an rules set to function that only uses keep-state' rules for outbound and inbound selection control and the divert rule. Does anybody have an rules set they can share with me as an sample for me to see. Thanks The best sample is /etc/rc.firewall [and look in /usr/share/examples/ipfw for a potentially useful script to use while testing]. I have moved over to IPFILTER due to the fact that natd is userland based and is more problematic [than ipnat] because of it. Tom Veldhouse ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
fbsd_user wrote: I disagree with you that the /etc/rc.firewall is the best example. It's really a good example of stateless rules, how to use scripting Symbolic substitution. I have working keep-state rule set using user-ppp -nat, but as soon as I add that darn legacy divert rule and drop user-ppp -nat it will not work. Dynamic stateful rules table always ends up with an mis-match between public and private ip address. Moving the divert rule around only changes which ip address gets posted to the stateful table(ie: the private or public one). Test results look like that legacy divert subroutine call to NATD is the problem. See same mis-match ip address problem when stateless rules are used, but since there is no stateful table involved it just slips by un-noticed. Was hoping that the ipfw2 rewrite would have fixed this problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas T. Veldhouse Sent: Monday, January 19, 2004 1:41 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] ORG Subject: Re: ipfw/nated stateful rules example fbsd_user wrote: Friends In both 4.9 and 5.2 I can not get an rules set to function that only uses keep-state' rules for outbound and inbound selection control and the divert rule. Does anybody have an rules set they can share with me as an sample for me to see. Thanks The best sample is /etc/rc.firewall [and look in /usr/share/examples/ipfw for a potentially useful script to use while testing]. I have moved over to IPFILTER due to the fact that natd is userland based and is more problematic [than ipnat] because of it. Tom Veldhouse Here are the contents of one that I used to use when I used IPFW ... it was originally and loosely based off of /etc/rc.firewall. # # Setup system for firewall service. # # 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 quiet mode if requested # case ${firewall_quiet} in [Yy][Ee][Ss]) fwcmd=/sbin/ipfw -q ;; *) fwcmd=/sbin/ipfw ;; esac # Flush out the list before we begin. # ${fwcmd} -f flush # set these to your outside interface network and netmask and ip oif=dc0 onet=x.y.z.32 omask=255.255.255.240 oip=x.y.z.33 # set these to your inside interface network and netmask and ip iif=fxp0 inet=192.168.1.0 imask=255.255.255.0 iip=192.168.1.3 # outlaw addresses, never allow traffic from these outlaws=24.93.67.0/24 # Only in rare cases do you want to change these rules # ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 105 deny all from any to 127.0.0.0/8 ${fwcmd} add 110 deny ip from 127.0.0.0/8 to any # ip-options (per FreeBSD Security Advisory: FreeBSD-SA-00:23.ip-options) ${fwcmd} add deny log ip from any to any ipoptions ssrr,lsrr,ts,rr via ${oif} # allow certain ICMP through (allows ping, traceroute, plus # the required source quence and similar) ${fwcmd} add pass icmp and to any icmptypes 0,3,4,8,11,12 via ${oif} ${fwcmd} add deny icmp from any to any icmptypes 9 via ${oif} # silent block on router advertisements ${fwcmd} add pass icmp from any to any via ${iif} # allow all internally ${fwcmd} add deny icmp from any to any # Stop spoofing ${fwcmd} add deny all from ${inet}:${imask} to any in via ${oif} ${fwcmd} add deny all from ${onet}:${omask} to any in via ${iif} # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} # 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} add deny all from any to 0.0.0.0/8 via ${oif} ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. case ${natd_enable} in [Yy][Ee][Ss]) if [ -n ${natd_interface} ]; then ${fwcmd} add divert natd all from any to any via ${natd_interface} fi ;; esac # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} # 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} add deny all from 0.0.0.0/8 to any via ${oif} ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} ${fwcmd} add deny all from
RE: ipfw/nated stateful rules example
Sorry but the rule set you posted is doing 'keep-state' on the lan interface and not the interface facing the public internet. All the rule statements processing against the public interface are stateless. Doing stateful testing on the private lan is just waste of cpu cycles, it proves nothing other than you have less turst in your lan users that you have in unknown public internet users. Like I said in previous post the /etc/rc.firewall file is useless as it does not use stateful rules on the interface facing the public internet where it will do the most good. But thanks for taking the time to reply. So if you no longer use ipfw what do you use? And why did you change? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas T. Veldhouse Sent: Monday, January 19, 2004 5:26 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] ORG Subject: Re: ipfw/nated stateful rules example fbsd_user wrote: I disagree with you that the /etc/rc.firewall is the best example. It's really a good example of stateless rules, how to use scripting Symbolic substitution. I have working keep-state rule set using user-ppp -nat, but as soon as I add that darn legacy divert rule and drop user-ppp -nat it will not work. Dynamic stateful rules table always ends up with an mis-match between public and private ip address. Moving the divert rule around only changes which ip address gets posted to the stateful table(ie: the private or public one). Test results look like that legacy divert subroutine call to NATD is the problem. See same mis-match ip address problem when stateless rules are used, but since there is no stateful table involved it just slips by un-noticed. Was hoping that the ipfw2 rewrite would have fixed this problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas T. Veldhouse Sent: Monday, January 19, 2004 1:41 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] ORG Subject: Re: ipfw/nated stateful rules example fbsd_user wrote: Friends In both 4.9 and 5.2 I can not get an rules set to function that only uses keep-state' rules for outbound and inbound selection control and the divert rule. Does anybody have an rules set they can share with me as an sample for me to see. Thanks The best sample is /etc/rc.firewall [and look in /usr/share/examples/ipfw for a potentially useful script to use while testing]. I have moved over to IPFILTER due to the fact that natd is userland based and is more problematic [than ipnat] because of it. Tom Veldhouse Here are the contents of one that I used to use when I used IPFW ... it was originally and loosely based off of /etc/rc.firewall. # # Setup system for firewall service. # # 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 quiet mode if requested # case ${firewall_quiet} in [Yy][Ee][Ss]) fwcmd=/sbin/ipfw -q ;; *) fwcmd=/sbin/ipfw ;; esac # Flush out the list before we begin. # ${fwcmd} -f flush # set these to your outside interface network and netmask and ip oif=dc0 onet=x.y.z.32 omask=255.255.255.240 oip=x.y.z.33 # set these to your inside interface network and netmask and ip iif=fxp0 inet=192.168.1.0 imask=255.255.255.0 iip=192.168.1.3 # outlaw addresses, never allow traffic from these outlaws=24.93.67.0/24 # Only in rare cases do you want to change these rules # ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 105 deny all from any to 127.0.0.0/8 ${fwcmd} add 110 deny ip from 127.0.0.0/8 to any # ip-options (per FreeBSD Security Advisory: FreeBSD-SA-00:23.ip-options) ${fwcmd} add deny log ip from any to any ipoptions ssrr,lsrr,ts,rr via ${oif} # allow certain ICMP through (allows ping, traceroute, plus # the required source quence and similar) ${fwcmd} add pass icmp and to any icmptypes 0,3,4,8,11,12 via ${oif} ${fwcmd} add deny icmp from any to any icmptypes 9 via ${oif} # silent block on router advertisements ${fwcmd} add pass icmp from any to any via ${iif} # allow all internally ${fwcmd} add deny icmp from any to any # Stop spoofing ${fwcmd} add deny all from ${inet}:${imask} to any in via ${oif} ${fwcmd} add deny all from ${onet}:${omask} to any in via ${iif} # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} # 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} add deny all from any to 0.0.0.0/8 via ${oif} ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} ${fwcmd} add deny all
Re: ipfw/nated stateful rules example
fbsd_user [EMAIL PROTECTED] writes: Sorry but the rule set you posted is doing 'keep-state' on the lan interface and not the interface facing the public internet. All the rule statements processing against the public interface are stateless. Doing stateful testing on the private lan is just waste of cpu cycles, it proves nothing other than you have less turst in your lan users that you have in unknown public internet users. Not really; the stateful rules are being applied against the public Internet responses to packets sent out by the LAN users. -- Lowell Gilbert, embedded/networking software engineer, Boston area: resume/CV at http://be-well.ilk.org:8088/~lowell/resume/ username/password public ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ipfw/nated stateful rules example
to any in via $pif #Class D E multicast # Deny public pings $cmd 00310 deny icmp from any to any in via $pif # Deny ident $cmd 00315 deny tcp from any to any 113 in via $pif # Deny all Netbios service. 137=name, 138=datagram, 139=session # Netbios is MS/Windows sharing services. # Block MS/Windows hosts2 name server requests 81 $cmd 00320 deny tcp from any to any 137 in via $pif $cmd 00321 deny tcp from any to any 138 in via $pif $cmd 00322 deny tcp from any to any 139 in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Deny any late arriving packets $cmd 00330 deny all from any to any frag in via $pif # Deny ACK packets that did not match the dynamic rule table $cmd 00332 deny tcp from any to any established in via $pif # Allow in standard www function because I have apache server $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Allow in secure FTP, Telnet, and SCP from public Internet $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Allow in non-secure Telnet session from public Internet # labeled non-secure because ID PW are passed over public # internet as clear text. $cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Reject Log all incoming connections from the outside $cmd 00499 deny log all from any to any in via $pif # Everything else is denied by default # deny and log all packets that fell through to see what they are $cmd 00999 deny log all from any to any End of IPFW rules file ### -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Lowell Gilbert Sent: Monday, January 19, 2004 8:14 PM To: [EMAIL PROTECTED] Subject: Re: ipfw/nated stateful rules example fbsd_user [EMAIL PROTECTED] writes: Sorry but the rule set you posted is doing 'keep-state' on the lan interface and not the interface facing the public internet. All the rule statements processing against the public interface are stateless. Doing stateful testing on the private lan is just waste of cpu cycles, it proves nothing other than you have less turst in your lan users that you have in unknown public internet users. Not really; the stateful rules are being applied against the public Internet responses to packets sent out by the LAN users. -- Lowell Gilbert, embedded/networking software engineer, Boston area: resume/CV at http://be-well.ilk.org:8088/~lowell/resume/ username/password public ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ipfw/nated stateful rules example
On Mon, 19 Jan 2004, fbsd_user wrote: That's a play on words. And still does not prove stateful rules work on the interface facing the public internet. There is no documentation that says keep-state and limit only works on the interface facing the private Lan network. And the implied meaning is they are to be used on the interface facing the public internet. I just jumped in the middle here, so I may be out of context. But, stateful rules don't play nice with NAT. Consider non-NAT, a public IP address contacting an Internet address: 67.161.59.61 - 66.218.71.91 A rule is created for 66.218.71.91 coming to 67.161.59.61. When 66.218.71.91 replies, the stateful rule lets it in. This is good. But consider NAT: 10.0.0.10 changed to 67.161.59.61 - 66.218.71.91 If you do a keep-state before NAT, you have a rule to allow 66.218.71.91 to 10.0.0.10, but the return incoming packet will be 66.218.71.91 - 67.161.59.61, so the rule doesn't match. If you do a keep-state after NAT, then you have a rule to allow 66.218.71.91 to 67.161.59.61. The return incoming packet matches that rule, but it accepts the packet and packet processing stops, so it's never passed through NAT, and never makes it back to 10.0.0.10. So as it stands now, I don't see that you can use stateful connections with NAT, unless check-state is changed to allow a packet to be passed through NAT. Ken Bolingbroke [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw/nated stateful rules example
- Original Message - From: Ken Bolingbroke [EMAIL PROTECTED] To: fbsd_user [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 19, 2004 10:28 PM Subject: RE: ipfw/nated stateful rules example On Mon, 19 Jan 2004, fbsd_user wrote: That's a play on words. And still does not prove stateful rules work on the interface facing the public internet. There is no documentation that says keep-state and limit only works on the interface facing the private Lan network. And the implied meaning is they are to be used on the interface facing the public internet. I just jumped in the middle here, so I may be out of context. But, stateful rules don't play nice with NAT. Consider non-NAT, a public IP address contacting an Internet address: 67.161.59.61 - 66.218.71.91 A rule is created for 66.218.71.91 coming to 67.161.59.61. When 66.218.71.91 replies, the stateful rule lets it in. This is good. But consider NAT: 10.0.0.10 changed to 67.161.59.61 - 66.218.71.91 If you do a keep-state before NAT, you have a rule to allow 66.218.71.91 to 10.0.0.10, but the return incoming packet will be 66.218.71.91 - 67.161.59.61, so the rule doesn't match. If you do a keep-state after NAT, then you have a rule to allow 66.218.71.91 to 67.161.59.61. The return incoming packet matches that rule, but it accepts the packet and packet processing stops, so it's never passed through NAT, and never makes it back to 10.0.0.10. So as it stands now, I don't see that you can use stateful connections with NAT, unless check-state is changed to allow a packet to be passed through NAT. Ken Bolingbroke Ken, try this one. This is what I use here at home and it does indeed work: Launch NATD with natd -interface ep0 -s -m -u (Only RFC1918 packets get altered) ## Divert everything to NAT. ipfw add 1 divert natd ip from any to any via ep0 #Prevent inbound spoof attempts for my lan range ipfw add 10 deny ip from 192.168.1.0/24 to any in via ep0 #Check State Rules ipfw add 20 check state #LAN Allow Stateful ipfw add 31 allow ip from 192.168.1.0/24 to any keep-state #Allow Outbound Stateful. ipfw add 40 allow ip from 68.12.xx.xx to any keep-state NAT keeps a seperate table of it's translations to provide a back channel. Traffic comes in, generates a dynamic ruleset, gets translated, heads out and creates the 2nd dynamic for the packet. You'll end up with something like this ipfw -d list snip ## Dynamic rules: 00040 4 692 (T 18, slot 215) - tcp, 68.12.xx.xx3777- 216.239.57.99 80 00031 35 20374 (T 10, slot 219) - udp, 192.168.1.3 4986- 198.247.231.41 27019 00031 3 216 (T 1, slot 483) - tcp, 192.168.1.1 22- 192.168.1.2 3574 00031 16 11902 (T 298, slot 752) - tcp, 192.168.1.2 3777- 216.239.57.99 80 Granted, you'll end up with a dual entry for each packet in stateful space, but it does work. Perhaps not as intended with a single match but you can use statful with NAT. -- Micheal Patterson Network Administration TSG Incorporated 405-917-0600 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]