DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 1st November 2011
scrummie02 scrummie02 is offline
Port Guard
 
Join Date: Nov 2011
Posts: 15
Thanked 0 Times in 0 Posts
Default Help with PF NAT configuration

Hello all, I am replacing a Cisco ASA with an OpenBSD PF NAT box for a couple of reasons: I'm tired of paying Cisco money just to receive updates, tired of the license limits and the device is about six years old.

So I have an atom server with three interfaces one for public/dmz/internal.

The current config with the ASA is the following:

external (fxp1) --->Firewall ---> DMZ (192.168.100.0/24) (fxp0) --->Inetrnal (192.168.200.0/24) (re0).

I don't really want to re-IP the nodes in the DMZ so if possible I'd like to keep everything the same. I've purchased the book of PF version 2 but still need some assistance. Here is my pf.conf:
Code:
#MACROS
_int="re0"
lan="re0:network"

_dmz="fxp0"
dmz="192.168.100.0/24"

mailserver="192.168.100.2"
ftpwebserver="192.168.100.1"
RFC1918="{ 10/8 172.16/12 192.168/16 }"
 
#TABLES
 
#OPTIONS
set skip on lo
set block-policy drop
 
#NORMALIZE  TRAFFIC
match in all scrub ( no-df max-mss 1440 )
 
#NAT
match out on egress from $lan to any nat-to egress
match out on egress from $dmz to any nat-to egress
 
#REDIRECTIONS
match in on egress inet proto tcp from any to any port 25 \
    rdr-to $mailserver
match in on egress inet proto tcp from any to any port 110 \
    rdr-to $mailserver
match in on egress inet proto tcp from any to any port 587 \
    rdr-to $mailserver
match in on egress inet proto tcp from any to any port 465 \
    rdr-to $mailserver
match in on egress inet proto tcp from any to any port 25 \
    rdr-to $mailserver
match in on egress inet proto tcp from any to any port 995 \
    rdr-to $mailserver
match in on egress inet proto tcp from any to any port 443 \
    rdr-to $mailserver
match in on egress inet proto tcp from any to any port 110 \
    rdr-to $mailserver
match in on egress inet proto tcp from any to any port 80 \
    rdr-to $ftpwebserver
 
#BLOCK POLICY
block log all
 
#PROTECTION
antispoof for { lo0 re0 fxp0 fxp1 }
block in on egress from $RFC1918 to any
block out on egress from any to $RFC1918
 
#AUTHORIZE PINGS
pass inet proto icmp all icmp-type { echoreq, unreach }
 
#FORWARDING OUT
pass out on egress inet proto tcp from any to any 
pass out on egress inet proto udp from any to any 

#LAN SERVICES 
anchor "ftp-proxy/*"
pass in on $_int proto tcp from any to any port ftp \
    rdr-to 127.0.0.1 port 8021

#AUTHORIZED SERVICES 
pass in on $_int proto tcp from $lan to any port \
    { 80 22 3000 4567 443 53 69 } 
pass in quick on $_int proto udp from $lan to any port { domain 69 }

#CONSOLE ACCESS 
#pass in on egress proto tcp from any to egress port 22 

#DMZ SERVICES
pass in on egress proto tcp from any to $mailserver port \
    { 25 110 443 587 465 995 }
pass out on $_dmz proto tcp from any to $mailserver port \
    { 25 110 443 587 465 995 }
pass in on $_dmz proto tcp from $mailserver to any port \
    { 25 110 587 465 995 }

#ACCESS WEB SERVICES
pass in on egress inet proto tcp from any to $ftpwebserver port 80
pass out on $_int inet proto tcp from any to $ftpwebserver port 80

basically I want the internal network to be able to access the DMZ but obviously not the other way around. I'm having some issues with that part.

Last edited by ocicat; 1st November 2011 at 05:05 PM. Reason: Please use [code] & [/code] tags when posting command output.
Reply With Quote
  #2   (View Single Post)  
Old 1st November 2011
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,156
Thanked 182 Times in 149 Posts
Default

In your case you have to deal with the following packet flows ( I hope I didn't miss any )
  1. EXTERNAL INTERFACE
    1. Outgoing traffic
      1. initiated by the internal LAN( entered on the internal interface)
      2. initiated by the DMZ servers (e.g. DNS requests by the mail server)
      3. initiated by the firewall box itself (e.g. troubleshooting by admin)
      4. answer packets issued by the DMZ servers to clients on the internet
    2. Incoming traffic

      1. answer packets for connections initiated by the internal LAN
      2. answer packets for the DMZ servers (e.g. DNS answers for the mail server)
      3. connections initiated by clients on the internet to the DMZ servers
  2. INTERNAL INTERFACE
    1. Outgoing traffic
      1. answer packets entering the external interfaces destined for internal LAN
      2. answer packets entering the DMZ interface, destined for connections initiated by internal LAN
    2. Incoming traffic
      1. packets initiated by internal LAN clients with destination internet,
      2. packets initiated by internal LAN clients with destination DMZ
  3. DMZ INTERFACE
    1. Outgoing traffic
      1. packets entered on external interface with destination DMZ server
        (connections initated by external clients on the Internet)
        (connections initiated by DMZ server (e.g. DNS anwers for mail server)
      2. packets entered on internal interface with destination DMZ server
        (connections initiated by clients on the internal LAN)
    2. Incoming traffic
      1. answer packets for external clients on the Internet
      2. answer packets for internal lan clients

The dangereous ones are in red, and actually should not be used in a "real DMZ" configuration.

As far as I understand the Diginotar debacle, this is how they got 'cracked". The internal administrative machine connected to the Diginotar DMZ servers was compromised, and used as base to generate the "fake" SSL certificates.

Back to your issue

I would advise to use pf's tags to make it easier to handle the flows.
An example for DNS requests, or connections initatiated by a DMZ mail server

Code:
# DMZ interface
# -- in
pass in quick on DMZ_if from DMZ-servers to !(INT_lan:network, EXT_if) tag OUT_OK

# EXTERNAL INTERFACE
# --out
pass out quick on EXT_if tagged OUT_OK
(Untested because I have to walk the dog ), but you get the idea.

In a similar way you could tag the traffic from the internal LAN to the internet with the same OUT_OK tag, and the last rule would "automagically" deal with that traffic too. A great way to simplify your ruleset.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

Last edited by J65nko; 1st November 2011 at 10:27 PM.
Reply With Quote
  #3   (View Single Post)  
Old 2nd November 2011
scrummie02 scrummie02 is offline
Port Guard
 
Join Date: Nov 2011
Posts: 15
Thanked 0 Times in 0 Posts
Default

OKay, I've readjusted my rules and went with tagging like you suggested. A read up a little ont he OpenBSD's PF FAQ and came up with the following ruleset
Code:
#MACROS
_int = "re0"
_dmz  = "fxp0"
_ext  = "fxp1"
int_net = "192.168.200.0/24"
dmz_net = "192.168.100.0/24"

webserver = "192.168.100.53"
mailserver = "192.168.100.51"

int_tcp_services = "{ 80 25 53 3000 4567 }"
int_udp_services = "{ 53 }"
dmz_tcp_services = "{ 80 25 53 }"
dmz_udp_services = "{ 53 }"

RFC1918="{ 10/8 172.16/12 192.168/16 }"

#TABLES
table <spamd> persist file "/etc/spammers"
table <bastards> persist file "/etc/bastards"

#OPTIONS
set skip on lo
set block-policy drop
 
#NORMALIZE  TRAFFIC
match in all scrub ( no-df max-mss 1440 )

# BLOCKING AND PACKET TAGGING
block log all
antispoof for { lo0 re0 fxp0 fxp1 }
block in on _ext from $RFC1918 to any
block out on _ext from any to $RFC1918
block in on _ext from <bastards>

pass out on $_ext tag LAN_NAT_TO_INET tagged LAN_TO_INET nat-to ($_ext)
pass out on $_ext tag DMZ_NAT_TO_INET tagged DMZ_TO_INET nat-to ($_ext)
pass in on $_int from $int_net tag LAN_TO_INET
pass in on $_int from $int_net to $dmz_net tag LAN_TO_DMZ
pass in on $_dmz from $dmz_net port $dmz_tcp_services tag DMZ_TO_INET
pass in on $_dmz from $dmz_net port $dmz_udp_services tag DMZ_TO_INET

#SERVICES INBOUND
pass in on $_ext proto tcp to $wwwserver port { 80 3000 4567 } tag INET_TO_DMZ
pass in on $_ext proto tcp to $mailserver port {25 110 587 465 } tag INET_TO_DMZ

#SPAMD 
pass in on $_ext proto tcp from <spamd> to port smtp tag SPAMD rdr-to 127.0.0.1 port 8025

# POLICY ENFORCEMENT 
pass in  quick on $_ext tagged SPAMD
pass out quick on $_ext tagged LAN_NAT_TO_INET
pass out quick on $_ext tagged DMZ_NAT_TO_INET
pass out quick on $_dmz tagged LAN_TO_DMZ
pass out quick on $_dmz tagged INET_TO_DMZ
My int is obviously 192.168.200.0/24 and need to be able to ssh/read ports 80,3000 on the dmz at 192.168.100./24 so this config should work. Do I ned to add a static route since the DMZ and int networks are different networks?

Last edited by ocicat; 2nd November 2011 at 09:23 PM. Reason: Again, *please* use [code] & [/code] tags when posting command output.
Reply With Quote
  #4   (View Single Post)  
Old 2nd November 2011
scrummie02 scrummie02 is offline
Port Guard
 
Join Date: Nov 2011
Posts: 15
Thanked 0 Times in 0 Posts
Default

I'm still having issues. When I use tagging I can't even get out to the internet at all and tcpdump doesn't show anything.

Any help would be appreciated.
Reply With Quote
  #5   (View Single Post)  
Old 2nd November 2011
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,156
Thanked 182 Times in 149 Posts
Default

I sometimes forget that the hosts in the DMZ need a default route set to the IP address of the DMZ interface.
Code:
#  route add default 192.168.100.1
What happened to the redirections of your previous ruleset?
Quote:
#REDIRECTIONS
match in on egress inet proto tcp from any to any port 25 \
rdr-to $mailserver

[snip]
match in on egress inet proto tcp from any to any port 80 \
rdr-to $ftpwebserver
Because you have "block log all" default policy you can watch the blocked packets with tcpdump.
Code:
# tcpdump -eni pflog0
Make sure that the pflog0 interface is up See man pflog.

Code:
# pass in on $_int from $int_net tag LAN_TO_INET
pass in quick on $_int from $_int:network to !($_dmz:network, $_int) tag LAN_TO_INET
......
pass out quick on $_ext tagged LAN_NAT_TO_INET
This should allow traffic from the internal lan to the internet.

The best way is to build up your pf.conf for each packet flow step by step. (The approach advocated for programming by Niklaus Wirth father of Pascal, Modula etc)

Start with a block log all
Now add a rule to allow ssh access from your workstation to the router/firewall.
From an xterm on your workstation SSH in to the firewall and run tcpdump on the pflog0 interface.
From an other xterm ssh in and add the tag rules for internal LAN to internet traffic. From another workstation xterm do a dig yahoo.com Then a ping -c2 yahoo.com. If that all works try to access the yahoo.com website with a browser.

For testing your DMZ setup please read the gotchas explained in http://www.openbsd.org/faq/pf/rdr.html#reflect

You can ssh in to your router/firewall multiple times each in different xterm. That way you can check whether the packets really arrive at an interface
To prevent ssh packets from "polluting" your tcpdump output, you can exclude these ssh packets on the internal interface withtcpdump -ni re0 'not port ssh'.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #6   (View Single Post)  
Old 3rd November 2011
scrummie02 scrummie02 is offline
Port Guard
 
Join Date: Nov 2011
Posts: 15
Thanked 0 Times in 0 Posts
Default

I get a syntax error with the line you posted...
Reply With Quote
  #7   (View Single Post)  
Old 3rd November 2011
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,156
Thanked 182 Times in 149 Posts
Default

Because I am don't have a machine with multiple interfaces at hand, you could dig up the correct syntax in the pf.conf man page. The BNF is at the end of the man page
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #8   (View Single Post)  
Old 3rd November 2011
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,156
Thanked 182 Times in 149 Posts
Default

The issue is that you will have to find a way to tag the traffic with destination public Internet. In your case traffic entering the internal interface can have three destinations: Internet, DMZ net or the address of the external interface

Code:
# internal LAN to DMZ traffic (dangereous!)
pass in quick on $int from $int:network to $dmz:network tag LAN2DMZ

# only needed e.g. to ping the external interface, so no tag needed here
pass in quick on $int from $int:network to $ext 

# the remaining traffic not passed yet is from the internal LAN to the INTERNET
pass in quick on $int from $int:network to any tag LAN2INET
EDIT: Note that normally pf follows a "last match wins" strategy. The only way to circumvent this stragegy it to use quick. That way the rule will be applied immediately, and no other alternative rules will be sought for and tried.

You could try this approach.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

Last edited by J65nko; 3rd November 2011 at 10:22 AM.
Reply With Quote
  #9   (View Single Post)  
Old 3rd November 2011
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,888
Thanked 190 Times in 160 Posts
Default

Quote:
Originally Posted by scrummie02 View Post
I get a syntax error with the line you posted...
scrummie02, you have not disclosed what version of OpenBSD you are using. Posting the complete output of dmesg(8) (enclosed within [code] & [/code] tags...) would be beneficial.
Reply With Quote
Old 3rd November 2011
scrummie02 scrummie02 is offline
Port Guard
 
Join Date: Nov 2011
Posts: 15
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by J65nko View Post
The issue is that you will have to find a way to tag the traffic with destination public Internet. In your case traffic entering the internal interface can have three destinations: Internet, DMZ net or the address of the external interface

Code:
# internal LAN to DMZ traffic (dangereous!)
pass in quick on $int from $int:network to $dmz:network tag LAN2DMZ

# only needed e.g. to ping the external interface, so no tag needed here
pass in quick on $int from $int:network to $ext 

# the remaining traffic not passed yet is from the internal LAN to the INTERNET
pass in quick on $int from $int:network to any tag LAN2INET
EDIT: Note that normally pf follows a "last match wins" strategy. The only way to circumvent this stragegy it to use quick. That way the rule will be applied immediately, and no other alternative rules will be sought for and tried.

You could try this approach.

Okay I've started all over and this is what I have so far, I can get out and reach the DMZ/Interweb from the internal

DMZ can reach the internet

Code:
######MACROS
int = "re0"
dmz = "fxp0"
ext = "fxp1"
int_net = "192.168.200.0/24"
dmz_net = "192.168.100.0/24"
RFC1918="{ 10/8 172.16/12 192.168/16 }"

######TABLES
table <spamd> persist file "/etc/spammers"
table <bastards> persist file "/etc/bastards"

######OPTIONS
set skip on lo
set block-policy drop

######NORMALIZE TRAFFIC
match in all scrub ( no-df max-mss 1440 )

##### NAT RULES

#####i## BLOCKING AND PACKET TAGGING
block log all

#LAN OUT
pass in on $int from $int_net tag LAN
pass in on $int from $int_net to $dmz_net tag LAN_TO_DMZ

#DMZ OUT
pass in on $dmz from $dmz_net tag DMZ


#POLICY ENFORCEMENT
#pass out quick on $ext tagged LAN_TO_INET
pass out quick on $dmz tagged LAN_TO_DMZ

pass out on $ext tag LAN_TO_INET tagged LAN nat-to ($ext)
pass out on $ext tag DMZ_TO_INET tagged DMZ nat-to ($ext)
I am running OpenBSD 4.9. Dmesg is here:
Code:
OpenBSD 4.9 (GENERIC.MP) #819: Wed Mar  2 06:57:49 MST 2011
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2128334848 (2029MB)
avail mem = 2057654272 (1962MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe43c0 (27 entries)
bios0: vendor Intel Corp. version "MOPNV10J.86A.0148.2009.1102.2315" date 11/02/2009
bios0: Intel Corporation D510MO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT
acpi0: wakeup devices SLPB(S4) PS2M(S4) PS2K(S4) UAR1(S4) UAR2(S4) P32_(S4) ILAN(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) EHCI(S3) AZAL(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.93 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: apic clock running at 166MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.69 MHz
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG
cpu1: 512KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.69 MHz
cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG
cpu2: 512KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.69 MHz
cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG
cpu3: 512KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 8 pa 0xfec00000, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 8
acpimcfg0 at acpi0 addr 0xf8000000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 5 (P32_)
acpiprt1 at acpi0: bus 0 (PCI0)
acpiprt2 at acpi0: bus 1 (PEX0)
acpiprt3 at acpi0: bus 2 (PEX1)
acpiprt4 at acpi0: bus 3 (PEX2)
acpiprt5 at acpi0: bus 4 (PEX3)
acpicpu0 at acpi0: C1, PSS
acpicpu1 at acpi0: C1, PSS
acpicpu2 at acpi0: C1, PSS
acpicpu3 at acpi0: C1, PSS
acpibtn0 at acpi0: SLPB
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xd0000000, size 0x10000000
inteldrm0 at vga1: apic 8 int 16 (irq 11)
drm0 at inteldrm0
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: apic 8 int 22 (irq 9)
azalia0: codecs: Realtek ALC662
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: apic 8 int 17 (irq 255)
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/8111D (0x2800), apic 8 int 16 (irq 11), address 00:27:0e:07:6b:34
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: apic 8 int 16 (irq 255)
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01: apic 8 int 18 (irq 255)
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: apic 8 int 19 (irq 255)
pci4 at ppb3 bus 4
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 8 int 23 (irq 10)
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 8 int 19 (irq 11)
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 8 int 18 (irq 9)
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 8 int 16 (irq 11)
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 8 int 23 (irq 10)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb4 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe1
pci5 at ppb4 bus 5
ppb5 at pci5 dev 0 function 0 "DEC 21154 PCI-PCI" rev 0x05
pci6 at ppb5 bus 6
fxp0 at pci6 dev 4 function 0 "Intel 8255x" rev 0x0d, i82550: apic 8 int 21 (irq 10), address 00:d0:a8:00:e8:ad
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
fxp1 at pci6 dev 5 function 0 "Intel 8255x" rev 0x0d, i82550: apic 8 int 22 (irq 9), address 00:d0:a8:00:e8:ae
inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4
pcib0 at pci0 dev 31 function 0 "Intel Tigerpoint LPC" rev 0x01
pciide0 at pci0 dev 31 function 2 "Intel 82801GB SATA" rev 0x01: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using apic 8 int 19 (irq 11) for native-PCI interrupt
wd0 at pciide0 channel 1 drive 0: <HDS725050KLA360>
wd0: 16-sector PIO, LBA48, 476940MB, 976773168 sectors
wd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 6
ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: apic 8 int 19 (irq 11)
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-6400CL5
spdmem1 at iic0 addr 0x51: 1GB DDR2 SDRAM non-parity PC2-6400CL5
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
wbsio0 at isa0 port 0x4e/2: W83627THF rev 0x84
lm1 at wbsio0 port 0x290/8: W83627THF
mtrr: Pentium Pro MTRR support
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
root on wd0a swap on wd0b dump on wd0b
Reply With Quote
Old 3rd November 2011
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,156
Thanked 182 Times in 149 Posts
Default

You have now
Code:
#LAN OUT
pass in on $int from $int_net tag LAN
pass in on $int from $int_net to $dmz_net tag LAN_TO_DMZ
Please consider this little bit confusing snippet from the pf man page:
Code:
tag <string>
             Packets matching this rule will be tagged with the specified
             string.  The tag acts as an internal marker that can be used to
             identify these packets later on.  This can be used, for example,
             to provide trust between interfaces and to determine if packets
             have been processed by translation rules.  Tags are "sticky",
             meaning that the packet will be tagged even if the rule is not
             the last matching rule.  Further matching rules can replace the
             tag with a new one but will not remove a previously applied tag.
             A packet is only ever assigned one tag at a time.  Tags take the
             same macros as labels (see above).
If you ping a DMZ server from the internal net, pass in on $int from $int_net tag LAN it
be tagged with LAN. However, because you don't use quick, pf will keep evaluating the ping with the next rule pass in on $int from $int_net to $dmz_net tag LAN_TO_DMZ
You can check this with pfctl -vvsr and check the Evaluations counter.

Remember that packets entering on the internal interface all have the internal lan as origin. There are however two groups: packets with destination DMZ and packets for the Internet.
If pass in quick on $int from $int_net tag LAN would come first, the packets would never be evaluated to check whether they have the DMZ as destination.

So the solution is:

Code:
pass in quick on $int from $int_net to $dmz_net tag LAN_TO_DMZ
pass in quick on $int from $int_net tag LAN
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
Old 10th November 2011
scrummie02 scrummie02 is offline
Port Guard
 
Join Date: Nov 2011
Posts: 15
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by J65nko View Post
You have now
Code:
#LAN OUT
pass in on $int from $int_net tag LAN
pass in on $int from $int_net to $dmz_net tag LAN_TO_DMZ
Please consider this little bit confusing snippet from the pf man page:
Code:
tag <string>
             Packets matching this rule will be tagged with the specified
             string.  The tag acts as an internal marker that can be used to
             identify these packets later on.  This can be used, for example,
             to provide trust between interfaces and to determine if packets
             have been processed by translation rules.  Tags are "sticky",
             meaning that the packet will be tagged even if the rule is not
             the last matching rule.  Further matching rules can replace the
             tag with a new one but will not remove a previously applied tag.
             A packet is only ever assigned one tag at a time.  Tags take the
             same macros as labels (see above).
If you ping a DMZ server from the internal net, pass in on $int from $int_net tag LAN it
be tagged with LAN. However, because you don't use quick, pf will keep evaluating the ping with the next rule pass in on $int from $int_net to $dmz_net tag LAN_TO_DMZ
You can check this with pfctl -vvsr and check the Evaluations counter.

Remember that packets entering on the internal interface all have the internal lan as origin. There are however two groups: packets with destination DMZ and packets for the Internet.
If pass in quick on $int from $int_net tag LAN would come first, the packets would never be evaluated to check whether they have the DMZ as destination.

So the solution is:

Code:
pass in quick on $int from $int_net to $dmz_net tag LAN_TO_DMZ
pass in quick on $int from $int_net tag LAN
Okay, I have a question, On the packet tagging FAQ on the OpenBSD site they don't' use quick, and wouldn't I want all of the rules evaluated even after traffic passes the int interface? I'm just wondering.
Reply With Quote
Old 10th November 2011
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,156
Thanked 182 Times in 149 Posts
Default

When the traffic has passed the internal interface and has been tagged by the quick rule, it will be forwarded to the either the external interface, or the DMZ interface.
There it will be subject to further processing by pf e.g. pass out quick on $dmz tagged LAN_TO_DMZ
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
router configuration !! wlm2 OpenBSD General 1 11th July 2011 01:51 PM
PF NAT configuration help ikevinjpdev OpenBSD Security 0 7th August 2010 04:41 PM
PF Configuration for newbie slakic OpenBSD Security 1 20th August 2009 02:35 PM
ssh and PuTTY Configuration rtwingfield FreeBSD Security 4 8th June 2009 09:55 PM
k3b, configuration. maxrussell FreeBSD Ports and Packages 4 3rd March 2009 04:23 AM


All times are GMT. The time now is 01:48 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick