pf keep state on 3.8

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

pf keep state on 3.8

Jimmy Scott
Hi misc@,

I finaly had some time to rearrange my network, and split it into 3
parts: LAN, DMZ, WAN.

Basicly, the LAN (172.20) may not access the DMZ (172.16), but host
172.20.1.10 can. the DMZ may not access the LAN, and both can go to the
WAN.

But for some reason, when I create state from 172.20.1.10 to 172.16.x.x;
the packet comming back gets blocked which should not happen because the
state would be checked first and the state really is created?!

I tried setting 'set state-policy floating' explicit, but no advance.
Someone who knows what the problem is here? I had a ruleset with a bunch
of 'quick' rules before instead of this, but had the same problem.

tcpdump on pflog:
18:12:16.483526 rule 12/(match) pass in on sis2: 172.20.1.10.57132 >
172.16.0.5.ssh: [|tcp]
18:12:16.483960 rule 21/(match) block in on sis1: 172.16.0.5.ssh >
172.20.1.10.57132: [|tcp]


grep on state:
# pfctl -s state|grep 172.16.0.5
all tcp 172.16.0.5:22 <- 172.20.1.10:57132       CLOSED:SYN_SENT


kernel:
OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC

rules:
scrub in all no-df fragment reassemble
scrub out all no-df random-id fragment reassemble
block drop in log all
block drop log inet6 all
block drop in log quick on sis0 from any to (sis0:broadcast)
block drop in log quick on sis0 from <intruders> to any
pass log quick on lo0 inet from 127.0.0.0/8 to any
pass log quick on lo0 inet6 from ::1 to any
pass in log on sis2 inet proto tcp from 172.20.0.0/16 to any modulate state
pass in log on sis2 inet proto udp from 172.20.0.0/16 to any keep state
pass in log on sis2 inet proto icmp from 172.20.0.0/16 to any keep state
block drop in log on sis2 inet proto tcp from any to 172.16.0.0/16
block drop in log on sis2 inet proto udp from any to 172.16.0.0/16
block drop in log on sis2 inet proto icmp from any to 172.16.0.0/16
pass in log on sis2 inet proto tcp from 172.20.1.10 to 172.16.0.0/16 keep
state
pass in log on sis2 inet proto udp from 172.20.1.10 to 172.16.0.0/16 keep
state
pass in log on sis2 inet proto icmp from 172.20.1.10 to 172.16.0.0/16 keep
state
pass out log on sis2 inet proto tcp from 172.20.0.1 to 172.20.0.0/16 keep
state
pass out log on sis2 inet proto udp from 172.20.0.1 to 172.20.0.0/16 keep
state
pass out log on sis2 inet proto icmp from 172.20.0.1 to 172.20.0.0/16 keep
state
pass in log on sis1 inet proto tcp from 172.16.0.0/16 to any modulate state
pass in log on sis1 inet proto udp from 172.16.0.0/16 to any keep state
pass in log on sis1 inet proto icmp from 172.16.0.0/16 to any keep state
block drop in log on sis1 inet proto tcp from any to 172.20.0.0/16
block drop in log on sis1 inet proto udp from any to 172.20.0.0/16
block drop in log on sis1 inet proto icmp from any to 172.20.0.0/16
pass out log on sis1 inet proto tcp from 172.16.0.1 to 172.16.0.0/16 keep
state
pass out log on sis1 inet proto udp from 172.16.0.1 to 172.16.0.0/16 keep
state
pass out log on sis1 inet proto icmp from 172.16.0.1 to 172.16.0.0/16 keep
state
[sis0 rules snipped]

Kind regards,
Jimmy Scott

--
The Four Horsemen of the Apocalypse: Death, Famine, War, and SNMP

[demime 1.01d removed an attachment of type application/pgp-signature]

Reply | Threaded
Open this post in threaded view
|

Re: pf keep state on 3.8

Jim Razmus
* Jimmy Scott <[hidden email]> [051113 12:35]:

> Hi misc@,
>
> I finaly had some time to rearrange my network, and split it into 3
> parts: LAN, DMZ, WAN.
>
> Basicly, the LAN (172.20) may not access the DMZ (172.16), but host
> 172.20.1.10 can. the DMZ may not access the LAN, and both can go to the
> WAN.
>
> But for some reason, when I create state from 172.20.1.10 to 172.16.x.x;
> the packet comming back gets blocked which should not happen because the
> state would be checked first and the state really is created?!
>
> I tried setting 'set state-policy floating' explicit, but no advance.
> Someone who knows what the problem is here? I had a ruleset with a bunch
> of 'quick' rules before instead of this, but had the same problem.
>
> tcpdump on pflog:
> 18:12:16.483526 rule 12/(match) pass in on sis2: 172.20.1.10.57132 >
> 172.16.0.5.ssh: [|tcp]
> 18:12:16.483960 rule 21/(match) block in on sis1: 172.16.0.5.ssh >
> 172.20.1.10.57132: [|tcp]
>
>
> grep on state:
> # pfctl -s state|grep 172.16.0.5
> all tcp 172.16.0.5:22 <- 172.20.1.10:57132       CLOSED:SYN_SENT
>
>
> kernel:
> OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
>     [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
>
> rules:
> scrub in all no-df fragment reassemble
> scrub out all no-df random-id fragment reassemble
> block drop in log all
> block drop log inet6 all
> block drop in log quick on sis0 from any to (sis0:broadcast)
> block drop in log quick on sis0 from <intruders> to any
> pass log quick on lo0 inet from 127.0.0.0/8 to any
> pass log quick on lo0 inet6 from ::1 to any
> pass in log on sis2 inet proto tcp from 172.20.0.0/16 to any modulate state
> pass in log on sis2 inet proto udp from 172.20.0.0/16 to any keep state
> pass in log on sis2 inet proto icmp from 172.20.0.0/16 to any keep state
> block drop in log on sis2 inet proto tcp from any to 172.16.0.0/16
> block drop in log on sis2 inet proto udp from any to 172.16.0.0/16
> block drop in log on sis2 inet proto icmp from any to 172.16.0.0/16
> pass in log on sis2 inet proto tcp from 172.20.1.10 to 172.16.0.0/16 keep
> state
> pass in log on sis2 inet proto udp from 172.20.1.10 to 172.16.0.0/16 keep
> state
> pass in log on sis2 inet proto icmp from 172.20.1.10 to 172.16.0.0/16 keep
> state
> pass out log on sis2 inet proto tcp from 172.20.0.1 to 172.20.0.0/16 keep
> state
> pass out log on sis2 inet proto udp from 172.20.0.1 to 172.20.0.0/16 keep
> state
> pass out log on sis2 inet proto icmp from 172.20.0.1 to 172.20.0.0/16 keep
> state
> pass in log on sis1 inet proto tcp from 172.16.0.0/16 to any modulate state
> pass in log on sis1 inet proto udp from 172.16.0.0/16 to any keep state
> pass in log on sis1 inet proto icmp from 172.16.0.0/16 to any keep state
> block drop in log on sis1 inet proto tcp from any to 172.20.0.0/16
> block drop in log on sis1 inet proto udp from any to 172.20.0.0/16
> block drop in log on sis1 inet proto icmp from any to 172.20.0.0/16
> pass out log on sis1 inet proto tcp from 172.16.0.1 to 172.16.0.0/16 keep
> state
> pass out log on sis1 inet proto udp from 172.16.0.1 to 172.16.0.0/16 keep
> state
> pass out log on sis1 inet proto icmp from 172.16.0.1 to 172.16.0.0/16 keep
> state
> [sis0 rules snipped]
>
> Kind regards,
> Jimmy Scott
>
> --
> The Four Horsemen of the Apocalypse: Death, Famine, War, and SNMP
>
> [demime 1.01d removed an attachment of type application/pgp-signature]
>

I think you might have the concept of "in" and "out" rules confused.
Visualize yourself sitting in the computer between the three interfaces.
From that perspective, "in" rules mean a packet coming from a remote
host to you through one of those interfaces.  Conversely "out" rules
mean a packet leaving from the local machine to some remote host.

Give something like this a whirl for starters.  Caution, I have not
tested these!  You also likely need to allow packets from the Internet
into your DMZ.

# pf.conf
scrub in all no-df fragment reassemble
scrub out all no-df random-id fragment reassemble
block drop in log all
block drop log inet6 all
block drop in log quick on sis0 from any to (sis0:broadcast)
block drop in log quick on sis0 from <intruders> to any
pass log quick on lo0 inet from 127.0.0.0/8 to any
pass log quick on lo0 inet6 from ::1 to any

# LAN interface
pass in on sis2 inet proto tcp \
  from 172.20.0.0/16 to !172.16.0.0/16 modulate state
pass in on sis2 inet proto udp \
  from 172.20.0.0/16 to !172.16.0.0/16 keep state
pass in on sis2 inet proto icmp \
  from 172.20.0.0/16 to !172.16.0.0/16 keep state
pass in on sis2 inet proto tcp \
  from 172.20.1.10 to any modulate state
pass in on sis2 inet proto udp \
  from 172.20.1.10 to any keep state
pass in on sis2 inet proto icmp \
  from 172.20.1.10 to any keep state
block out on sis2 all # nothing gets out unless state or rule allows it
# not sure why you want these rules here, what's the firewall doing?
pass out on sis2 inet proto tcp \
  from 172.20.0.1 to 172.20.0.0/16 keep state
pass out on sis2 inet proto udp \
  from 172.20.0.1 to 172.20.0.0/16 keep state
pass out on sis2 inet proto icmp \
  from 172.20.0.1 to 172.20.0.0/16 keep state

# DMZ interface
pass in on sis1 inet proto tcp \
  from 172.16.0.0/16 to !172.20.0.0/16 modulate state
pass in on sis1 inet proto udp \
  from 172.16.0.0/16 to !172.20.0.0/16 keep state
pass in log on sis1 inet proto icmp \
  from 172.16.0.0/16 to !172.20.0.0/16 keep state
block out on sis1 all # nothing gets out unless state or rule allows it
# not sure why you want these rules here, what's the firewall doing?
pass out on sis1 inet proto tcp \
  from 172.16.0.1 to 172.16.0.0/16 keep state
pass out on sis1 inet proto udp \
  from 172.16.0.1 to 172.16.0.0/16 keep state
pass out on sis1 inet proto icmp \
  from 172.16.0.1 to 172.16.0.0/16 keep state

# WAN interface
[sis0 rules snipped]

HTH,
Jim

Reply | Threaded
Open this post in threaded view
|

Re: pf keep state on 3.8

Jimmy Scott
Quoting Jim Razmus <[hidden email]>:

> * Jimmy Scott <[hidden email]> [051113 12:35]:
> > Hi misc@,
> >
> > I finaly had some time to rearrange my network, and split it into 3
> > parts: LAN, DMZ, WAN.
> >
> > Basicly, the LAN (172.20) may not access the DMZ (172.16), but host
> > 172.20.1.10 can. the DMZ may not access the LAN, and both can go to the
> > WAN.
> >
> > But for some reason, when I create state from 172.20.1.10 to 172.16.x.x;
> > the packet comming back gets blocked which should not happen because the
> > state would be checked first and the state really is created?!
> >
> > I tried setting 'set state-policy floating' explicit, but no advance.
> > Someone who knows what the problem is here? I had a ruleset with a bunch
> > of 'quick' rules before instead of this, but had the same problem.
> >
> > [diagnostics snipped]
> >
>
> I think you might have the concept of "in" and "out" rules confused.
> Visualize yourself sitting in the computer between the three interfaces.
> From that perspective, "in" rules mean a packet coming from a remote
> host to you through one of those interfaces.  Conversely "out" rules
> mean a packet leaving from the local machine to some remote host.
>
> Give something like this a whirl for starters.  Caution, I have not
> tested these!  You also likely need to allow packets from the Internet
> into your DMZ.
>
> # pf.conf
> [proposed firewall rules snipped]
>
>
> HTH,
> Jim
>
>

Aah, I see what I did wrong, since I used in the passed 'pass all on sis2',
I never realized that state creation on an 'in' will only match an 'out'
for traffic in the other direction right? So for traffic from sis2 to sis1
I will need to create states on the 'in' of sis2 and states on the 'out' of
sis1 if I got it right.

Also thanks for your example, I will take a look at it later when I'm back
home to figure things out.

Kind regards,
Jimmy Scott



----------------------------------------------------------------
This message has been sent through ihosting.be
To report spamming or other unaccepted behavior
by a iHosting customer, please send a message
to [hidden email]
----------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: pf keep state on 3.8

Jim Razmus
* [hidden email] <[hidden email]> [051114 02:47]:

> Quoting Jim Razmus <[hidden email]>:
>
> > * Jimmy Scott <[hidden email]> [051113 12:35]:
> > > Hi misc@,
> > >
> > > I finaly had some time to rearrange my network, and split it into 3
> > > parts: LAN, DMZ, WAN.
> > >
> > > Basicly, the LAN (172.20) may not access the DMZ (172.16), but host
> > > 172.20.1.10 can. the DMZ may not access the LAN, and both can go to the
> > > WAN.
> > >
> > > But for some reason, when I create state from 172.20.1.10 to 172.16.x.x;
> > > the packet comming back gets blocked which should not happen because the
> > > state would be checked first and the state really is created?!
> > >
> > > I tried setting 'set state-policy floating' explicit, but no advance.
> > > Someone who knows what the problem is here? I had a ruleset with a bunch
> > > of 'quick' rules before instead of this, but had the same problem.
> > >
> > > [diagnostics snipped]
> > >
> >
> > I think you might have the concept of "in" and "out" rules confused.
> > Visualize yourself sitting in the computer between the three interfaces.
> > From that perspective, "in" rules mean a packet coming from a remote
> > host to you through one of those interfaces.  Conversely "out" rules
> > mean a packet leaving from the local machine to some remote host.
> >
> > Give something like this a whirl for starters.  Caution, I have not
> > tested these!  You also likely need to allow packets from the Internet
> > into your DMZ.
> >
> > # pf.conf
> > [proposed firewall rules snipped]
> >
> >
> > HTH,
> > Jim
> >
> >
>
> Aah, I see what I did wrong, since I used in the passed 'pass all on sis2',
> I never realized that state creation on an 'in' will only match an 'out'
> for traffic in the other direction right? So for traffic from sis2 to sis1
> I will need to create states on the 'in' of sis2 and states on the 'out' of
> sis1 if I got it right.
>
> Also thanks for your example, I will take a look at it later when I'm back
> home to figure things out.
>
> Kind regards,
> Jimmy Scott
>
>
>
> ----------------------------------------------------------------
> This message has been sent through ihosting.be
> To report spamming or other unaccepted behavior
> by a iHosting customer, please send a message
> to [hidden email]
> ----------------------------------------------------------------
>

You might find this helpful:

http://www.openbsd.org/faq/pf/filter.html#state

Your essentially correct if I understand you correctly.  ;-)  Actual
rules would help remove the ambiguity from the discussion.

Regardless, the pf FAQ is your friend and can explain the subject far
better than I can.

Good Luck,
Jim

Reply | Threaded
Open this post in threaded view
|

Re: pf keep state on 3.8

Jimmy Scott
On Mon, Nov 14, 2005 at 11:41:17AM -0500, Jim Razmus wrote:
> > > * Jimmy Scott <[hidden email]> [051113 12:35]:
> > > >
> > > > [snipped]
> > > >
> > > > I finaly had some time to rearrange my network, and split it into 3
> > > > parts: LAN, DMZ, WAN.
> > > >
> > > > Basicly, the LAN (172.20) may not access the DMZ (172.16), but host
> > > > 172.20.1.10 can. the DMZ may not access the LAN, and both can go to
the

> > > > WAN.
> > > >
> > > > [snipped]
> > > >
> > [snipped]
>
> You might find this helpful:
>
> http://www.openbsd.org/faq/pf/filter.html#state
>
> [snipped]

Thank you very much for your time looking at the problem. This time I
will give out the pf.conf file itself to all people interested in the
final solution I made from it (snipped from personal things and/or
replaced with example rules, eg: port 22 on host exmp).

I took this approach because the example mentioned in my book was
not that restrictive towards local traffic (between DMZ and LAN).

For those who didn't bought it yet and want all topics by hand,
"Building Firewalls with OpenBSD and PF" is a very good book.

Here mine goes:

######################################################################
######     MACRO DEFINITIONS                                    ######
######################################################################

# Interfaces
ext_if="sis0"
dmz_if="sis1"
lan_if="sis2"

# Hosts
enix="172.20.1.10"
exmp="172.16.1.10"

# Groups
staff="{" $enix "}"


######################################################################
######    TABLE DEFINITIONS                                     ######
######################################################################

# Unwanted people
table <intruders> file "/etc/pf.deny"


######################################################################
######    OPTIONS                                               ######
######################################################################

set require-order yes
set block-policy drop
set optimization normal
set loginterface $ext_if


######################################################################
######    TRAFFIC NORMALIZATION                                 ######
######################################################################

# Normalize every packet, and give random id's on outgoing
scrub in all no-df
scrub out all no-df random-id


######################################################################
######    BANDWIDTH MANAGEMENT                                  ######
######################################################################

# TODO


######################################################################
######    TRANSLATION                                           ######
######################################################################

# NAT the internal networks
nat on $ext_if from $lan_if:network -> ($ext_if:0)
nat on $ext_if from $dmz_if:network -> ($ext_if:0)


######################################################################
######    REDIRECTION                                           ######
######################################################################

# Redirect certain incomming requests
#rdr on $ext_if proto tcp from any to ($ext_if:0) port 22 -> $exmp port 22

# No redirects from LAN to DMZ and the other way around
no rdr on $lan_if proto tcp to $dmz_if:network
no rdr on $dmz_if proto tcp to $lan_if:network

# Redirect ftp requests through our ftp proxy with NAT
rdr on $lan_if proto tcp to ! $lan_if port ftp -> 127.0.0.1 port 8021
rdr on $dmz_if proto tcp to ! $dmz_if port ftp -> 127.0.0.1 port 8021


######################################################################
######    PACKET FILTERING                                      ######
######################################################################


### DEFAULT RULES

# Block all packets
block in log all
block out log all

# Block broadcast and intruders quick without further processing
block in log quick on $ext_if from any to ($ext_if:broadcast)
block in log quick on $ext_if from <intruders> to any


### LOOPBACK

# Allow all valid loopback traffic quick
pass quick on lo0 from lo0:network


### LAN INTERFACE

# Allow net traffic except to DMZ, modulate tcp
pass in on $lan_if inet proto tcp from $lan_if:network to ! $dmz_if:network \
                                                                modulate
state
pass in on $lan_if inet proto {udp,icmp} from $lan_if:network to \
                                                ! $dmz_if:network keep state

# Allow staff members to access the DMZ
pass in on $lan_if inet proto {tcp,udp,icmp} from $staff \
                                                to $dmz_if:network keep state

# Allow the firewall to access the LAN (for debugging problems)
#pass out on $lan_if inet proto {tcp,udp,icmp} from $lan_if \
#                                               to $lan_if:network keep state


### DMZ INTERFACE

# Allow net traffic except to LAN, modulate tcp
pass in on $dmz_if inet proto tcp from $dmz_if:network to ! $lan_if:network \
                                                                modulate
state
pass in on $dmz_if inet proto {udp,icmp} from $dmz_if:network to \
                                                ! $lan_if:network keep state

# Allow staff members to access the DMZ
pass out on $dmz_if inet proto {tcp,udp,icmp} from $staff \
                                                to $dmz_if:network keep state

# Allow access to external services running in the DMZ
# If you want LAN to access these you must permit so in the block above
pass out on $dmz_if inet proto tcp to $exmp port 22 keep state

# Allow the firewall to access the DMZ (for debugging problems)
#pass out on $dmz_if inet proto {tcp,udp,icmp} from $dmz_if \
#                                               to $dmz_if:network keep state


### EXTERNAL INTERFACE

# Block quick anything that looks spoofed (restricted antispoof)
block in log quick on $ext_if inet from ($ext_if)
block in log quick on $ext_if inet from lo0:network
block in log quick on $ext_if inet from $dmz_if:network
block in log quick on $ext_if inet from $lan_if:network

# Block quick and return RST for connections to ident port
block return-rst in log quick on $ext_if inet proto tcp to ($ext_if:0) \
                                                                port auth

# Allow incomming connections to the ftp proxy
pass in log on $ext_if inet proto tcp to ($ext_if:0) port > 49151 flags S/SA
\
                                                      user proxy modulate
state

# Allow incomming connections to these hosts
pass in log on $ext_if inet proto tcp to $exmp port 22 flags S/SA \
                                                                 synproxy
state

# Block outgoing packets that are not from our IP to disallow spoofing
block out log quick on $ext_if inet from !($ext_if:0) to any

# Allow all other outgoing connections (or just a few)
pass out log on $ext_if inet proto tcp to any modulate state
pass out log (all) on $ext_if inet proto {udp,icmp} to any keep state



Hope tis will help someday a person that is looking for the same.

Kind regards,
Jimmy Scott

--
The Four Horsemen of the Apocalypse: Death, Famine, War, and SNMP

[demime 1.01d removed an attachment of type application/pgp-signature]