RE: ipfw/nated stateful rules example

2004-01-21 Thread fbsd_user
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

2004-01-21 Thread Micheal Patterson

- 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

2004-01-21 Thread Alex Zbyslaw
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

2004-01-21 Thread fbsd_user
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

2004-01-21 Thread Jonathan Chen
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

2004-01-20 Thread Alex Zbyslaw
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

2004-01-20 Thread fbsd_user
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

2004-01-20 Thread Alex Zbyslaw
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

2004-01-20 Thread fbsd_user
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

2004-01-20 Thread Micheal Patterson


- 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

2004-01-20 Thread fbsd_user
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

2004-01-20 Thread Jonathan Chen
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

2004-01-20 Thread Micheal Patterson

- 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

2004-01-20 Thread Micheal Patterson




- 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

2004-01-19 Thread fbsd_user
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

2004-01-19 Thread Thomas T. Veldhouse
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

2004-01-19 Thread fbsd_user
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

2004-01-19 Thread Thomas T. Veldhouse
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

2004-01-19 Thread fbsd_user
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

2004-01-19 Thread Lowell Gilbert
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

2004-01-19 Thread fbsd_user
 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

2004-01-19 Thread Ken Bolingbroke

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

2004-01-19 Thread Micheal Patterson


- 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]