tarballed
August 9th, 2002, 15:45
Hello everyone.
I'm pretty new to OpenBSD and PF, but im having a really good time learning it. I've recently ventured into setting up my own firewall using PF.

As I learn more each day, I do have questions on how rules work as well as placing them in the correct order.

I wanted to place a quick snip of my rules that im currently working on in hopes of getting a better explanation of what going on. Let me paste here:

# UDP
pass out log on $ext_if inet proto udp all keep state
pass in on $ext_if inet proto udp from any to $ext_if keep state
pass in on $ext_if inet proto udp from any to any keep state

(Let me first explain that I only want my LAN computers to access the internet. I'm not allowing any connections from the internet to access my LAN. No mail, dns or web servers at this time.)

Ok..I understand the first rule, pass out. It passes out traffic that my internal LAN requests.

Where im a confused is on the second two rules.
First, do I even need those two rules?

Maybe someone can explain to me really quickly why I would want to pass in to my internal LAN...do I need to pass in due to the previous rule, pass out?

This is where im a bit shaky and need some explanation.
I have more questions as well, but thought i'd start with this.

Thanks everyone.

Tarballed.

KrUsTy!
August 9th, 2002, 16:17
Okay, better step back a bit and start from the beginning. You want to have a firewall that blocks incoming connetions, but lets computers on the inside lan surf the net like normal right?

So let's start with a simple ruleset. I'll give the explanation below each area,

Start by setting out your varriables. pf is great because the varriables make looking at the rules much easier, nad keeps the ruleset simple.


# External ethernet interface, from "ifconfig -a":
ext_if = "xl1"
NoRouteIPs="{ 127.0.0.1/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"


So you can make your externel ethernet adapter a varriable, which is good when using a cable modem or dsl line with an external address that is dhcped to you.


# Clean up any wierd external packets:
scrub in on $ext_if all


This does some clean up so wierd and truncated packets.


#Don't allow anyone to spoof non-routable addrs.
block in log quick on $ext_if from $NoRouteIPs to any
block in out quick on $ext_if from $NoRouteIPs to any


This makes sure that no one can spoof there way past your firewall by pretending to a computer on your LAN. Since we made the varriable with all of the rfc subnets for internal lan configuration, this should stop the spoofers.


# Now filter stuff.
#Specifically block IP Options.
block in log quick on $ext_if in proto tcp from any to any \
flags { FUP/FUP, SF/SFRA, /SFRA, F/SFRA, U/SFRAU, P }


This blocks some things that can be used by people to get information about your firewall. For example this should stop most NMAP identity scans.


#Default Deny
block in on $ext_if all


This is basically your firewall! Blocks all incoming connecitons unless specfied otherwise. This will block UDP, TCP, ICMP, kittens, farm animals, fast cars, everything.


#Keep States Letting all outgoing traffic out and maintaining states on
#established connections including TCP,UDP, ICMP and create state.
block out on $ext_if all
pass out on $ext_if inet proto tcp all flags S/SA keep state
pass out on $ext_if inet proto udp all keep state
pass out on $ext_if inet proto icmp all keep state


This is the rules that you are interested in. This allows specific traffic from internal computers to go out to the internet, and allows requested information to come back to the computer that requested it. The keep state flag ensures that when your requested info arrives, it will be allowed back in. So in this rule set we allow tcp, udp and icmp to flow out, but nothing else.

So here is the rule set altogether. It is pretty much the rule set that openbsd.org recommends in there FAQ. http://www.openbsd.org/faq/faq6.html#PF



# External ethernet interface, from "ifconfig -a":
ext_if = "xl1"
NoRouteIPs="{ 127.0.0.1/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"

# Clean up any wierd external packets:
scrub in on $ext_if all

#Don't allow anyone to spoof non-routable addrs.
block in log quick on $ext_if from $NoRouteIPs to any
block in out quick on $ext_if from $NoRouteIPs to any

# Now filter stuff.
#Specifically block IP Options.
block in log quick on $ext_if in proto tcp from any to any \
flags { FUP/FUP, SF/SFRA, /SFRA, F/SFRA, U/SFRAU, P }

#Default Deny
block in on $ext_if all

#Keep States Letting all outgoing traffic out and maintaining states on
#established connections including TCP,UDP, ICMP and create state.
block out on $ext_if all
pass out on $ext_if inet proto tcp all flags S/SA keep state
pass out on $ext_if inet proto udp all keep state
pass out on $ext_if inet proto icmp all keep state



Hope this helps.

tarballed
August 9th, 2002, 17:55
Thanks krusty for your reply. I do appreciate it.
I've been learning PF for a little over a week now, trying to consume as much as I can. This is what I have so far for my pf.conf. Let me know what you think:

#Declare interfaces
ext_if = "dc0"
in_int = "dc1"

#scrub on incoming packets
scrub in on $ext_if all

# block and log everything by default
block out log on $ext_if all
block in log on $ext_if all
block return-rst out log on $ext_if inet proto tcp all
block return-rst in log on $ext_if inet proto tcp all
block return-icmp out log on $ext_if inet proto udp all
block return-icmp in log on $ext_if inet proto udp all

# block anything coming form source we have no back routes for
block in from no-route to any

# silently drop broadcasts (cable modem noise)
block in quick on $ext_if from any to 255.255.255.255
block in log quick on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 } to any

# ICMP
pass out on $ext_if inet proto icmp all icmp-type 8 code 0 keep state
pass in on $ext_if inet proto icmp all icmp-type 8 code 0 keep state

# UDP
pass out log on $ext_if inet proto udp all keep state
pass in on $ext_if inet proto udp from any to $ext_if keep state
pass in on $ext_if inet proto udp from any to any keep state

# TCP
pass out on $ext_if inet proto tcp all modulate state
pass out log on $ext_if inet proto tcp from any to any port { www, ftp, smtp, telnet, 110, 119, 443 } keep state


I have to say that my rules are heavily influenced the man pf. I'm still learning all the rules and functions, but I wanted to get up a secure firewall so I can get rolling on my LAN and learn more *BSD and Linux.

I must also add that you are correct in assuming that I only want my LAN to access the internet and certain services (smtp, pop, https etc.) and not allow the big bad internet :) to access my LAN for any services.

Thanks again. I'm sure i'll have more questions. I'm just trying to learn the basics of the rules at the moment and go from there.

Thanks again.

Tarballed

tarballed
August 9th, 2002, 18:00
Also, I like the way you setup your 'spoofed' ip addresses as a variable. I'm going to update my pf.conf with a variable that is similar and then name it something like $spoofed of some sort. Great stuff.

Thanks again

Tarballed

tarballed
August 9th, 2002, 22:16
Hello again...here is a quick update of my pf.conf

Tell me how it looks:

#Declare interfaces
ext_if = "dc0"
in_int = "dc1"
spoofed = "10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32"

#Scrub on incoming packets
scrub in on $ext_if all


# block and log everything by default
block out log on $ext_if all
block in log on $ext_if all
block return-rst out log on $ext_if inet proto tcp all
block return-rst in log on $ext_if inet proto tcp all
block return-icmp out log on $ext_if inet proto udp all
block return-icmp in log on $ext_if inet proto udp all

# block anything coming form source we have no back routes for
block in from no-route to any

# silently drop broadcasts (cable modem noise)
block in quick on $ext_if from any to 255.255.255.255
block in log quick on $ext_if from $spoofed to any
blcok out quick on $ext_if from $spoofed to any

#Block any outgoing and incoming packets they have incorrect source from

# ICMP
pass out on $ext_if inet proto icmp all icmp-type 8 code 0 keep state
pass in on $ext_if inet proto icmp all icmp-type 8 code 0 keep state

# UDP
pass out log on $ext_if inet proto udp all keep state

# TCP
pass out on $ext_if inet proto tcp all modulate state
pass out log on $ext_if inet proto tcp from any to any port { www, ftp, smtp, telnet, 110, 119, 443 } keep state

Thanks again.

Tarballed

KrUsTy!
August 9th, 2002, 23:24
Well, its good, but could be simplified. Remember that usually simpler is better with these things, becuase you can think that you have yourself covered and another rule then opens a hole. The other thing is you need to be carefull about the order in which you have your rules. Order is important.



#Declare interfaces
ext_if = "dc0"
in_int = "dc1"
spoofed = "10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32"

#Scrub on incoming packets
scrub in on $ext_if all



This looks good.


# block and log everything by default
block out log on $ext_if all
block in log on $ext_if all
block return-rst out log on $ext_if inet proto tcp all
block return-rst in log on $ext_if inet proto tcp all
block return-icmp out log on $ext_if inet proto udp all
block return-icmp in log on $ext_if inet proto udp all


I don't think you need the last 4 rules with the return option. Once you have blocked the traffic, why bother returning a reset? You are already blocked it, the reset isn't usefull. I don't think it does anything for you. So I would takes these rules out...

The logging will create MASSIVE logs, of stuff you probably don't need to see. Just to let you know that these logs are going to become big very quickly... I would suggest to make rules for logging of blocked traffic you want to see above the default deny, and then make the default deny a blackhole. That way you see what you want to see without your logs being massive.

For example if you wanted to see attempted ssh connections in the logs, put this rule above the default deny

block in log quick on $ext_if inet proto tcp all from any to any port ssh

The "quick" tells it to use this rule absolutely, and so ensures that all ssh traffic is blocked by this rule and so then logged. It must be above the deafult deny. All the blocking rules above the default deny should contain "quick".


# block anything coming form source we have no back routes for
block in from no-route to any


A good one, but it should be above you default deny rule.


# silently drop broadcasts (cable modem noise)
block in quick on $ext_if from any to 255.255.255.255
block in log quick on $ext_if from $spoofed to any
blcok out quick on $ext_if from $spoofed to any


Okay logging here makes sense, but again you need to put these blocking rules above you default deny. The rule for your broadcast is pointless cause its already covered in your varriable. The blocking out of the spoofed address is good as it will prevent routing mistakes that can lead to "leaking".


# ICMP
pass out on $ext_if inet proto icmp all icmp-type 8 code 0 keep state
pass in on $ext_if inet proto icmp all icmp-type 8 code 0 keep state


You don't need a pass in for ICMP. Passing it out with a keep state will allow returning traffic in. Take that rule out.


# UDP
pass out log on $ext_if inet proto udp all keep state


Good.


# TCP
pass out on $ext_if inet proto tcp all modulate state
pass out log on $ext_if inet proto tcp from any to any port { www, ftp, smtp, telnet, 110, 119, 443 } keep state


Replace this with;
pass out on $ext_if inet proto tcp all flags S/SA keep state

No need to mention all those ports on the passout, with this simpler rule it covers all that traffic. And the keep state ensures that you traffic will come back without delays...

Your doing pretty well, ordering of the rules looks like the biggest thing. Look at the order in the rules that I posted earlier, and deffinately read the openbsd FAQ on pf. Its really good. I sometimes still pick up things from it, and they do a good job in keeping it up to date.

Cheers!

Hope this helps.

KrUsTy!
August 9th, 2002, 23:57
Was you intent to log those ports going out to monitor things on your lan in your following rules?


pass out on $ext_if inet proto tcp all modulate state
pass out log on $ext_if inet proto tcp from any to any port { www, ftp, smtp, telnet, 110, 119, 443 } keep state


Okay, I suppose you could do that, but you should have a keep state rule for all passed out traffic and not just on these ports, if your intent is to let all tcp traffic flow out freely. Not sure what the modulated state does, guess I'll look it up! :oops: Of course if you wanted to be strict with what can come out of your network, that can be done by only passing out the ports you want instead of all. Some people like this, although mostly in a corporate situation, for a cable modem user probably not all that usefull, unless you are paranoid. :wink: Looks like to me you have the second rule purely to try and log that traffic outbound. Let me know if I'm right about that.

Cheers!

tarballed
August 10th, 2002, 00:24
Woow...good stuff. I really appreciate your input. It really helps me learn more and move along.

Let's see here. I tried to modify my rules a bit. Here is a new updated version:

#Declare interfaces
ext_if = "dc0"
in_int = "dc1"
spoofed = "spoofed = "10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32""

#Scrub on incoming packets
scrub in on $ext_if all

# block anything coming form source we have no back routes for
block in from no-route to any

# block and log everything by default
block out log on $ext_if all
block in log on $ext_if all

# silently drop broadcasts (cable modem noise)
block in quick on $ext_if from any to 255.255.255.255
block in log quick on $ext_if from $spoofed to any
blcok out quick on $ext_if from $spoofed to any

# ICMP
pass out on $ext_if inet proto icmp all icmp-type 8 code 0 keep state

# UDP
pass out log on $ext_if inet proto udp all keep state

# TCP
pass out on $ext_if inet proto tcp all flags S/SA keep state

That, I believe should be it. Did I miss anything? See any holes?

Basically, at this point, my goals are to setup my internal LAN and give it access to the internet. Nothing at this point will need any access to my LAN. It's only going to need access to the internet and services.
I plan to eventually add a mail and dns server. For the moment, just need to get the basics down.

Thanks for everyones input. I really do appreciate it!

tarballed

tarballed
August 10th, 2002, 12:39
Hello everyone. Im back again. :)

The more and more I read over this, as well as consult the openbsd man pages for pf.conf, the more it makes sense. Im starting to understand about rule organization on the order it needs to be in. Its starting to sink in how the rules need to be organized and sort. Great stuff! I'm having a blast!


Ok...couple more questions:

Where can I find more information from the following information you entered in a reply:

flags { FUP/FUP, SF/SFRA, /SFRA, F/SFRA, U/SFRAU, P }


Trying to learn all the flags, what they do, and how to implement them.

This is great stuff.

Thanks again for your help. I do appreciate it.

Tarballed

bsdjunkie
August 10th, 2002, 13:55
Id reccomend TCP/IP Illustrated Vol 1 by Richard Stevens.

http://www.amazon.com/exec/obidos/ASIN/0201633469/qid=1028998852/sr=8-1/ref=sr_8_1/103-4871930-6951052

ImpTech
August 10th, 2002, 14:13
Hi,

I'm a bit confused about that flags bit krusty mentioned too. For one thing pf doesn't seem to like it, either as written or substituting inet for in (which I assume is what you meant).

I'm also curious what exactly I'd be disabling with those flags, and whether it would break the services I'm allowing into my machine (http, ssh). It would be very cool to be able to defeat nmap with the firewall.

Any help appreciated!

bsdjunkie
August 10th, 2002, 14:19
Please see my above post, if you are really interested in messing with these flags and "Understanding" them, i highly reccommend that book. Its a must have for any serious networking professional. :roll:

check out Ch. 18, pg 229.

Else theres always the RFC :lol:

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1180.html

|MiNi0n|
August 10th, 2002, 15:01
Please see my above post, if you are really interested in messing with these flags and "Understanding" them, i highly reccommend that book.

For understanding the flags kRusTy! mentioned, I highly recommend the man page for nmap:

http://www.insecure.org/nmap/nmap_manpage.html

Gives you a good idea what role FIN/SYN/ACK and others play in TCP as well as gives you an understanding of how they might work against you, hence you can learn what/why you want to disable :-)

tarballed
August 10th, 2002, 16:21
Here it is: Tell me what you think or whats missing:

#Declare interfaces, ifoncing -a
ext_if = "dc0"
in_int = "dc1"
spoofed = "10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32"

#scrub on incoming packets
scrub in on $ext_if all

# block anything coming from source we have no back routes for
block in from no-route to any

# silently drop broadcasts (cable modem noise) and spoofed IP's
block in quick on $ext_if from any to 255.255.255.255
block in log quick on $ext_if from $spoofed to any
block out quick on $ext_if from $spoofed to any

#Specifically block IP options.
block in log quick on $ext_if in proto tcp from any to any flags { FUP/FUP, SF/SFRA, /SFRA, F/SFRA, U/SFRA, P }

# block and log everything by default
block in on $ext_if all
block out on $ext_if all

# ICMP
pass out on $ext_if inet proto icmp all icmp-type 8 code 0 keep state

# UDP
pass out on $ext_if inet proto udp all keep state

# TCP
pass out on $ext_if inet proto tcp all flags S/SA keep state

Thanks for everyones help!

Tarballed

bsdjunkie
August 10th, 2002, 18:00
#Specifically block IP options.
block in log quick on $ext_if in proto tcp from any to any flags { FUP/FUP, SF/SFRA, /SFRA, F/SFRA, U/SFRA, P }

# block and log everything by default
block in on $ext_if all
block out on $ext_if all

Just wondering, why bother adding all these flags to fool something like nmap. If this is your firewall box, i hope its a proper bastion host and has no services running on it anyways. If you dont want nmap to see you, run it as a transparent bridge. Then no one will know you are there., 8)

tarballed
August 10th, 2002, 18:37
Actually, this is my firewall box and its going to only act as a firewall and gateway. Nothing else is going to be running on it.

I have thought about running the transparent packet firewall.

Is that what you were referring to?

Also, do you have any other suggestions? I'd like to make my network as secure as I can.

Thanks.

Tarballed

bsdjunkie
August 10th, 2002, 19:48
http://cfm.gs.washington.edu/security/firewall/pf-bridge/

if your planning on a transparent bridge, keep this in mind if you plan on using NAT.

http://archives.neohapsis.com/archives/openbsd/2002-04/0517.html

or the following on transparent proxying:
http://www.squid-cache.org/Doc/FAQ/FAQ-17.html



You may also want to install an IDS on the box like Snort. The combination of a firewall and IDS is nice.

http://www.snort.org/

:roll:

tarballed
August 10th, 2002, 21:26
Hmm....do you recommend a transparent bridge on my firewall?

I've thought about it, but I wanted to get my openbsd firewall up and running first, then switch over. From what i'm told and read, its not to hard.

Ya, i'd like to install snort once I have everything up and running.

Any other suggestions/recommendations? Trying to secure my LAN the best that I can.

Thanks everyone.

Tarballed

tarballed
August 10th, 2002, 22:02
Let me ask this:

With my current pf.conf rules and lets say I set up transparent packet filtering on my firewall with these rules, would this be pretty secure?

Is their anything in my current pf.conf rules that might be a problem?

As I said earlier, at this time, I have 4 computers on my internal LAN who will be accessing the internet through my bsd firewall/gateway. I have no servers of sort in my internal LAN. I only need internet access for my internal computers. :)

Any suggestions?

Thanks always,

tarballed

tarballed
August 10th, 2002, 22:08
Actually, if I'm reading the transparent packet filtering firewall needs to work correctly with NAT, my situation will not work.

I'm currently connect via cable modem and receive my IP via DHCP. I dont have static IP, only dynamic.

That correct? :(

If so, what next is the recommendation? :)


Tarballed

elmore
August 10th, 2002, 22:18
A transparent bridge is an excellent Idea. I have one for my home lan. Keep in mind it'll be hard for you to nat on a box with no ip's. On my home cable modem setup I have the following:



|Internet|----|CableModem|----|IP-LessBridge|----|FW/VPN|----|LAN|



With regard to ipopts, one of your initial ruleset posts did have redirects to internal services. ipopts certainly needs to be in use if you are doing this. As Krusty and Minion said to avoid a flat out recognition from nmap. With no services open these aren't necessarily needed as bsdjunkie said. I personally leave all ipopts in every ruleset I use with the "log in quick" keywords so I can see with a little more clarity what exact ipopts are being passed to my box.

I'm glad to see you're having a good time learning all of this. I'd also like to say thanks to everybody posting on this thread for such a "helpful" nature. This is the reason we are here.

tarballed
August 10th, 2002, 22:28
Hmm...I sure am learning alot, thats for sure. :)

Let me see if I can back up here. There is so much information coming in here, its almost overwhelming. :)

Ok...so originally I was just going to have a openbsd firewall/gateway with pf rules in pf.conf. It was going to run NAT with rules in nat.conf. Fair enough.

I've ravamped my rules and posted them in this case. I think they are pretty secure, but i'm not entirely sure. Still learning how to optimize rules as well as spot the 'holes' in rules. At this point, how would my current pf.conf rules work and would the security be pretty tight?

Moving on.
The topic of transparent firewall bridges come up. I've read a couple of articles on this, but I dont know how everything works will all tied together. I read the HOW-TO that was posted in the HOW-TO section on these boards.

However, in my situation, it will be difficult to run the bridge since i'm running NAT. Correct?

::Deep Breath:: :D

First question is: How do my original pf.conf rules look? Ok? need tweaking?

Second question: How could I implement a transparent bridge in my situation?


Boy...im out of breath (or typing)

This is great stuff. Sure is a blast.
I must add, these boards are very cool. I like them alot. Very informative and very nice people indeed.

Thanks again everyone.

The Tarball

bsdjunkie
August 11th, 2002, 14:00
If your not comfortable with bridging yet, a normal firewall will be fine and NAT will be easier. I guess the easiest thing to do would be to use the KISS principle.
The following is from the pf faq and is quite simple and secure. just change the ip's and any services you may want to run.

# Define useful variables
ExtIF="fxp0" # External Interface
IntNet="1.1.1.0/24" # Our internal network
NoRouteIPs="{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"
Services="{ www, https }"

# Clean up fragmented and abnormal packets
scrub in all

# don't allow anyone to spoof non-routeable addresses
block in quick on $ExtIF from $NoRouteIPs to any
block out quick on $ExtIF from any to $NoRouteIPs

# by default, block all incoming packets, except those explicitly
# allowed by further rules
block in on $ExtIF all

# allow others to use http and https
pass in on $ExtIF inet proto tcp from any to any port $Services \
flags S/SA keep state

# and let out-going traffic out and maintain state on established connections
# pass out all protocols, including TCP, UDP and ICMP, and create state,
# so that external DNS servers can reply to our own DNS requests (UDP).
block out on $ExtIF all
pass out on $ExtIF inet proto tcp all flags S/SA keep state
pass out on $ExtIF inet proto udp all keep state
pass out on $ExtIF inet proto icmp all keep state

tarballed
August 11th, 2002, 14:11
Thanks bsdjunkie. I may use that rule to start with until im more comfortable with building my own rules.

Quick question though: I tried the put the following rule into my pf.conf, but when I reloaded the pf rules, I received a error pointing to this line:

block in log quick on $ext_if in proto tcp from any to any flags { FUP/FUP, SF/SFRA, /SFRA, F/SFRA, U/SFRAU, P }

I double checked my typing, but could not see any errors. Any ideas?

Thanks again.

The Tarball

bsdjunkie
August 11th, 2002, 14:23
Like i said above, you really dont need a rule like that if your not running services on the box.. I would set up Snort to detect scans like nmap and whatnot, having a simple/secure firewall ruleset is probably the way to go.

tarballed
August 11th, 2002, 17:32
If I may ask one more question, just so I know im grasping the rules concept and how they work. This little snip is taking from the rules bsdjunkie posted from the pf FAQ. Here it is:

# allow others to use http and https
pass in on $ExtIF inet proto tcp from any to any port $Services \
flags S/SA keep state


Now, correct me if im wrong, but this rule allows the outside world to access the internal LAN for the services specified. In this example (Part of what bsdjunkie posted) http and https. Correct?

Thanks for your help. It is much appreciated.

Tarballed

bsdjunkie
August 11th, 2002, 19:07
Yes, in this case from the FAQ, a web server is running on an internal box in LAN or DMZ and any traffic hitting firewall at that port is being redirected to webserver. Since you are not running web on it, you may just want to put ssh in the services so you can ssh into box, and maybe add a rule where only a specific IP can get in if your even more paranoid thanks to the remote root awhile back found with openssh.

tarballed
August 11th, 2002, 19:15
Cool...thanks bsdjunkie. Just wanted to make sure I was understanding the rules, directions and how they worked.

Thanks again.

Tarballed