OpenBSD help - final revision of my pf.conf file

[xyyz]

tell me if this is workable?

-----------------------------------

###################################
# $OpenBSD: pf.conf 11/9/2003
###################################

#####################################
### macros
#####################################

### IP addresses
ext_ip = "10.10.100.2" # external address
int_ip = "192.168.150.253" # internal address
dmz_ip = "172.16.200.1" # DMZ address
lab_ip = "172.16.100.1" # lab address

### servers
web_server = "172.16.200.2" # webserver

### physical interfaces
int_int = "hme0" # internal interface
ids_int = "hme1" # IDS sensor interface
svr_int = "hme2" # server interfaces
lab_int = "hme3" # router lab interface
ext_int = "hme4" # external interface
all_int = "{ hme0, hme1, hme2, hme3, hme4}" # all interfaces

### networks
OUTSIDE = "10.10.100.0/30" # External LAN
SOL = "192.168.150.240/28" # Internal LAN
DMZ = "172.16.200.0/30" # DMZ LAN
LAB = "172.16.100.0/29" # LAB LAN

### hosts
venus = "192.168.150.242" # Hosts
saturn = "192.168.150.243" #
mercury = "192.168.150.249" #
uranus = "192.168.150.253" #
hosts = "{" venus saturn mercury uranus "}"

### Services
www = "{ 80, 443}" # http/https

### Private addresses
spoof_ips= "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }" # private addresses

##################################################################
### Options: tune the behavior of pf
##################################################################

### Sets the interface for which PF should gather statistics such as bytes in/out and packets passed/blocked
### Optimize PF for one of the following network environments
### packet is silently dropped
### set require-order yes

set loginterface hme4
set optimization normal
set block-policy drop
set fingerprints "/etc/pf.os"

##########################
Packet Filtering Table
##########################

### rule format
### action direction [log] [quick] on int [af] [proto protocol] from src_addr [port src_port] to dst_addr [port dst_port] [tcp_flags] [state]

### Clean up fragmented packets and abnormal packets
scrub in all fragment reassemble

### nat: packets going out through $ext_int with source address $hosts will
### get translated as coming from the address of $ext_int, a state is created for
### such packets, and incoming packets will be redirected to the internal address.
nat on $ext_int from $hosts to any -> $ext_ip

### default deny policy
block all log

### activate spoofing protection for the internal interface
antispoof for $int_int inet

### pass traffic on the loopback interface in either direction
pass out on lo0 from $all_int to any modulate state

### pass tcp, udp, and icmp out on the external (Internet) interface. keep state on udp and icmp and modulate state on tcp.
pass in on $int_int from $hosts proto tcp to any modulate state
pass in on $int_int from $hosts proto { udp, icmp } to any keep state

### webserver access
pass in on $dmz_int proto tcp from $ext_ip to $web_server port $www keep state

### lab access
pass in on $lab_int proto tcp from $ext_ip to $LAB port telnet keep state

### allow ssh connections in on the external interface as long as they're NOT destined for the firewall (ie, they're
### destined for a machine on the local network). log the initial packet so that we can later tell who is trying to connect.
pass in log on $ext_int proto tcp from any to { !$ext_int, !$int_int } port ssh flags S/SA keep state

 

[Sunner]

Doesn't that one look kinda funny?
LAB = "172/168/100.0/29" # LAB LAN

Or is that some new syntax? Even though my fw is running 3.3 the rulebase dates back to 3.0 so Im not very up to date on some of the newer stuff 🙂

 

[Barnaby W. Füi]

also, shouldn't:

hosts = "{" venus, saturn, mercury, uranus "}"

be:

hosts = "{ venus, saturn, mercury, uranus }"

?

 

[Sunner]

Yep, that's correct, missed that one.

 

[xyyz]

Originally posted by: BingBongWongFooey
also, shouldn't:

hosts = "{" venus, saturn, mercury, uranus "}"

be:

hosts = "{ venus, saturn, mercury, uranus }"

?

no... these are nested... so you need to put the "" on the inside as well.

everything else okay...?

 

[cleverhandle]

I replied to your original post in Networking here but never heard back from you. The last two points there still hold, as far as I can see.

 

[xyyz]

I replied to your original post in Networking here but never heard back from you. The last two points there still hold, as far as I can see.

i did address what you mentioned. that's why the "misc" stuff was deleted.

i think the problem is that i'm not understanding the formatting.

let's address the core issue:

### pass tcp, udp, and icmp out on the external (Internet) interface. keep state on udp and icmp and modulate state on tcp.
pass out on $int_int from $hosts proto tcp from any to any modulate state
pass out on $int_int from $hosts proto { udp, icmp } from any to any keep state

First off, this can't be right conceptually. Did you swap ext for int? What this line intends is to allow internal hosts to initiate a connection. But that means the first packet would be inbound (toward the router) on the internal interface. Alternatively, you could pass in on $int, and keep state on the packet as it leaves the router - outbound (away from the router) on the external interface.

i think i'm having an issue with the logic.

this is what the first line reads like to me:

"pass out on the internal interface all specified hosts from any to any modulate and keep state"

reading this back i'm confused with the "any to any." i've already speficied that all noted hosts should be allowed to pass traffic out of the firewall's internal interface, which is the gateway for the workstations. so why do we have any repeated twice? shouldn't it read like the following:

"pass out on $int_int from $hosts proto tcp to any modulate state"

which says that all hosts should be allowed to pass traffic outside of the the interface on their subnet? i figure, this because you can't specify an interface that isn't part of the subnet, because the hosts won't know how to get there.

second:

Second, this is very trusting - I wouldn't so quickly assume that all traffic originating from the inside is friendly. What I prefer is to explicitly pass out traffic that I expect - maybe something like outgoing 80 and 443 from everyone, outgoing 25 from the mail server, and outgoing 53 from the DNS server. Then, after that, use the above statement along with a log directive - thus I log all outbound traffic that doesn't fit my expected pattern.

what you say is a virtually air-tight way of doing things, however, i don't know all the ports that are used. i dunno what ports my games use and what ports various other applications use. this is why i kept if this way. i guess i can look at some common ports that trojans use and expressly block those ports.

finally:

# allow ssh connections in on the external interface as long as they're
# NOT destined for the firewall (ie, they're destined for a machine on
# the local network). log the initial packet so that we can later tell
# who is trying to connect.
pass in log on $ext_interface proto tcp from any to { !$ext_interface, !$int_interface } port ssh flags S/SA keep state

This doesn't make sense. Unless you're forwarding port 22 (which so far you're not), an inbound SSH packet will never be routed to your internal network, because it's a private block. That is, unless the routers on 10./8 know that your firewall routes for 192.168.100.240/28. And if they do, then you shouldn't be NAT'ing. So something is confused here. And if you don't want SSH's on the external interface, I'd personally handle that in the sshd config - your PF rules will get complicated enough already.

i want ssh access to my internal solaris box. i do not want to allow an SSH connection from outside of the innermost lan to access the firewall. i plan to connect to the solaris machine and then ssh again to the firewall.

sorry i didn't respond earlier, i was just so confused after reading what you wrote, that kinda' started over again. after reading your post a few more times, i got a little more of what you were saying.

 

[n0cmonkey]

hosts = "{" venus, saturn, mercury, uranus "}"

Missing $s? Extra commas?

Macros can be defined recursively. Since macros are not expanded within quotes the following syntax must be used:

host1 = "192.168.1.1"
host2 = "192.168.1.2"
all_hosts = "{" $host1 $host2 "}"

The macro $all_hosts now expands to 192.168.1.1, 192.168.1.2.

 

[cleverhandle]

Originally posted by: xyyz
...so why do we have any repeated twice? shouldn't it read like the following:

"pass out on $int_int from $hosts proto tcp to any modulate state"

which says that all hosts should be allowed to pass traffic outside of the the interface on their subnet?

Correct, in this regard. I missed the extra "from." You're right - you only need one.

But, you're still confused about "out" and "in." Put it this way - a router is dumb. It doesn't have any idea which of its interfaces is the "outside world" - labels like "ext_int" exist purely for you, not for it. "Out" means a direction of traffic, not a destination. Any packet, on any interface, going from the router to a wire is going "out." Any packet coming from a wire to the router is going "in." So, again, if you want to pass traffic coming from your internal network, the router will see those packets as coming "in" - from a wire to itself.

I think that was clearer than the first try. We'll see...

second:

what you say is a virtually air-tight way of doing things, however, i don't know all the ports that are used. i dunno what ports my games use and what ports various other applications use. this is why i kept if this way. i guess i can look at some common ports that trojans use and expressly block those ports.

Well, it's not that airtight - malicious traffic can still hide on a well-known port. But it's a nice extra layer of watchfulness. In any event, you don't need to set that up all at once. Log all the outgoing connections, let it run for an hour, and check the (enormous) logs. You'll see what the common ports are - add rules without logging for that traffic. Rinse and repeat. After the first couple rounds, you'll have logs of manageable size, and then you can gradually figure out what the less common traffic is.

You say you don't know all the ports that are used. Fine, for now. But you're setting up a packet filter, so it's time to start learning - this is precisely the kind of work where you need to know your ports.

i want ssh access to my internal solaris box. i do not want to allow an SSH connection from outside of the innermost lan to access the firewall. i plan to connect to the solaris machine and then ssh again to the firewall.

OK, I may be missing some details - you've got a lot of networks involved here. But from what I see, that Solaris box has an address in 192.168.100.240/28. Yes? If so, how are you going to SSH to a private address from outside the LAN?.

 

[xyyz]

i think we should start with the diagram first

*internet*----------------router-----------------firewall------------------*various networks*

as you can see, i have a total of 5 interfaces on the firewall.

the router, as far as i can tell is locked tight. i have reflexive access-lists on the outside interfaces and cbac on the internal interface. i'm planning to get connectivity to the router using a VPN client. once i have established an inwards connection, the firewall will have a single hole to allow for an ssh session to ONLY the solaris box. i guess, i'm looking to do port mapping. i'll map the ssh port to the ip address of the solaris box.

also, i'm restricting all traffic to the webserver subnet to allow connection to http or https.

finally, i want to allow only inbound telnet access to the lab subnet (the plan is to have a lab that anyone can use to do some CCNA/CCNP labs). this poses a bit of a problem though, since i have 5 routers and only 1 ip address. i suppose i can allow telnet access to 5 non-standard ports, which i'll map to 5 addresses on the lab subnet... or i can just save up some money and get an access server, which would probably be a better way of doing this.

 

[cleverhandle]

Originally posted by: xyyz
i think we should start with the diagram first

*internet*----------------router-----------------firewall------------------*various networks*

as you can see, i have a total of 5 interfaces on the firewall.

Ah... I didn't realize the whole setup was behind another router. That clarifies things a bit.

the router, as far as i can tell is locked tight. i have reflexive access-lists on the outside interfaces and cbac on the internal interface. i'm planning to get connectivity to the router using a VPN client.

Is this the only way you're allowing incoming traffic? That is, the only incoming connections on the router's external, "real" IP are VPN connects? All web, SSH, and telnet traffic is through the VPN IP?

once i have established an inwards connection, the firewall will have a single hole to allow for an ssh session to ONLY the solaris box. i guess, i'm looking to do port mapping. i'll map the ssh port to the ip address of the solaris box.

Yes, you need to forward the port. Something like...

rdr on $ext_int proto tcp from any to $ext_ip port ssh -> $solaris_ip
pass in log on $ext_int proto tcp from any to $solaris_ip port ssh flags S/SAFR keep state

...should work.

also, i'm restricting all traffic to the webserver subnet to allow connection to http or https.

If this traffic is coming in via the VPN, then you would handle it like the SSH above. If it's coming in via the router's public IP, then you'll either have to forward ports twice or set an extra route on the router.

finally, i want to allow only inbound telnet access to the lab subnet (the plan is to have a lab that anyone can use to do some CCNA/CCNP labs). this poses a bit of a problem though, since i have 5 routers and only 1 ip address. i suppose i can allow telnet access to 5 non-standard ports, which i'll map to 5 addresses on the lab subnet... or i can just save up some money and get an access server, which would probably be a better way of doing this.

I do hope this is via VPN. Allowing plaintext passwords to machines designed to reroute packets and behind your firewall is a Really Bad Idea. Again, forward ports as above.

 

[xyyz]

the router, as far as i can tell is locked tight. i have reflexive access-lists on the outside interfaces and cbac on the internal interface. i'm planning to get connectivity to the router using a VPN client.

Is this the only way you're allowing incoming traffic? That is, the only incoming connections on the router's external, "real" IP are VPN connects? All web, SSH, and telnet traffic is through the VPN IP?

also, i'm restricting all traffic to the webserver subnet to allow connection to http or https.

If this traffic is coming in via the VPN, then you would handle it like the SSH above. If it's coming in via the router's public IP, then you'll either have to forward ports twice or set an extra route on the router.[/quote]

that's right... i need to poke holes for telnet, http, and https on the external interface. this will be for general access (telnet to the lab, and www services on the webserver). ssh connectivity will be allowed once i create the VPN tunnel. will encapsulating the ssh connection with an additional level of encryption cause problems?

finally, i want to allow only inbound telnet access to the lab subnet (the plan is to have a lab that anyone can use to do some CCNA/CCNP labs). this poses a bit of a problem though, since i have 5 routers and only 1 ip address. i suppose i can allow telnet access to 5 non-standard ports, which i'll map to 5 addresses on the lab subnet... or i can just save up some money and get an access server, which would probably be a better way of doing this.

I do hope this is via VPN. Allowing plaintext passwords to machines designed to reroute packets and behind your firewall is a Really Bad Idea. Again, forward ports as above.

well these router will be for public use. sorta a free router pod for those who need to use one. another thing i need to do is block multicasts and other routing protocols from leaving the lab subnet. i plan to only allow incomming telnet access to the routers... other than that, nothing goes out.

 

[cleverhandle]

Originally posted by: xyyz
that's right... i need to poke holes for telnet, http, and https on the external interface. this will be for general access (telnet to the lab, and www services on the webserver). ssh connectivity will be allowed once i create the VPN tunnel. will encapsulating the ssh connection with an additional level of encryption cause problems?

So... you're VPN'ing the SSH, but not telnet/http? Why would you do that? SSH is already secure - there's no reason to encapsulate it further. If you're going to allow incoming telnet and http on the real external IP, the VPN is a needless complication, since you'll need to forward ports on the router's external interface already.

well these router will be for public use. sorta a free router pod for those who need to use one.

I admire the motivation. But if you're not VPN'ing the telnet sessions, this is still a Really Bad Idea.

 

[xyyz]

So... you're VPN'ing the SSH, but not telnet/http? Why would you do that? SSH is already secure - there's no reason to encapsulate it further. If you're going to allow incoming telnet and http on the real external IP, the VPN is a needless complication, since you'll need to forward ports on the router's external interface already.

the reason why... is because i dont want to give everyone the cisco vpn client software when they want ot use my lab. i plan to have something like TTLexceeded's or free-labs.com, on a much smaller scale though. i'll have my webserver that will run phpbb or something like that on it. it's for anyone to come look, write, use... etc.

as for why i wanna do the ssh and the vpn... well this is more of a learning excercise than anything else. this is the home setup. something to do i guess. 🙂 those who have no buiness accessing anything other than the lab routers and going on the webserver... have no business doing anything else there. so i rather just close off any ports on the external router that don't need to be used by anyone other than me.

well these router will be for public use. sorta a free router pod for those who need to use one.

I admire the motivation. But if you're not VPN'ing the telnet sessions, this is still a Really Bad Idea.



ummm... other than this... and i've made the corrections... is the config something that will work?
maybe i'm not seeing what you're seeing. why is it a bad idea to telnet to the routers? i don't have anything secret on any of them. people can do what they want with them. so sending the cleartext passwords won't impact anything, since they'll be for personal labs.