RE: Solution Request: I need to initiate outbound PPTP requests thru FreeBSD firewall
-Original Message-
From: Chris Willis
Sent: Sunday, March 12, 2006 10:23 AM
To: 'Melameth, Daniel D.'
Subject: RE: Solution Request: I need to initiate outbound PPTP requests
thru FreeBSD firewall
This is what fwbuilder is creating.
set limit { frags 5000, states 1 }
set timeout adaptive.start 8000
set timeout adaptive.end 1
set optimization Normal
#
# Scrub rules
#
scrub in all fragment reassemble
scrub out all random-id
#
# Rule 0 (NAT)
# force mail server to NAT using same IP as incoming mail # nat on fxp0
proto {tcp udp icmp} from 192.168.254.253 to any -> 64.62.37.227 # #
Rule 1 (NAT) # force outbound vpn traffic to source port 500 # nat on
fxp0 proto {tcp,udp} from 192.168.0.0/16 to any port 500 -> 64.62.37.226
port 500 # # Rule 2 (NAT) # NAT all 1928 LAN clients to an IP address
on the external NIC # nat on fxp0 proto {tcp udp icmp} from
192.168.0.0/16 to any -> 64.62.37.226 # # Rule 3 (NAT) # Port Forward
services to DC1 # rdr on fxp0 proto tcp from any to 64.62.37.226 port
3389 -> 192.168.254.254 port 3389 rdr on fxp0 proto tcp from any to
64.62.37.226 port 1723 -> 192.168.254.254 port 1723 rdr on fxp0 proto
udp from any to 64.62.37.226 port 500 -> 192.168.254.254 port 500 rdr on
fxp0 proto 47 from any to 64.62.37.226 -> 192.168.254.254 rdr on fxp0
proto 51 from any to 64.62.37.226 -> 192.168.254.254 rdr on fxp0 proto
50 from any to 64.62.37.226 -> 192.168.254.254 rdr on fxp0 proto tcp
from any to 64.62.37.226 port 22 -> 192.168.254.254 port 22 # # Rule 4
(NAT) # Port Forward Services to MAIL1 # rdr on fxp0 proto tcp from any
to 64.62.37.227 port 110 -> 192.168.254.253 port 110 rdr on fxp0 proto
tcp from any to 64.62.37.227 port 443 -> 192.168.254.253 port 443 rdr on
fxp0 proto tcp from any to 64.62.37.227 port 3389 -> 192.168.254.253
port 3389 rdr on fxp0 proto tcp from any to 64.62.37.227 port 80 ->
192.168.254.253 port 80 # # Rule 5 (NAT) # port forward to the store
camera # rdr on fxp0 proto tcp from any to 64.62.37.228 port 80 ->
192.168.202.96 port 80 # # Rule 6 (NAT) # # rdr on fxp0 proto tcp from
any to 64.62.37.226 port 23 -> 192.168.200.11 port 23 # # Rule 7 (NAT)
# # rdr on fxp0 proto tcp from any to 64.62.37.229 port 11001 ->
192.168.200.38 port 11001 rdr on fxp0 proto udp from any to 64.62.37.229
port 11001 -> 192.168.200.38 port 11001 # # Rule 8 (NAT) # # rdr on
fxp0 proto tcp from any to 64.62.37.229 port 11002 -> 192.168.202.19
port 21 # # Rule 9 (NAT) # # rdr on fxp0 proto tcp from any to
64.62.37.230 port 3389 -> 192.168.254.255 port 3389
# Tables: (3)
table { 224.0.0.0/4 , 169.254.0.0/16 , 127.0.0.0/8 ,
10.0.0.0/8 , 192.168.0.0/12 , 192.0.2.0/24 , 0.0.0.0/8 } table
{ 64.62.37.226 , 64.62.37.227 , 64.62.37.228 ,
64.62.37.229 , 64.62.37.230 , 192.168.200.89 , 192.168.200.40 } table
{ 192.168.0.0/16 , 66.134.48.170 }
#
# Rule 0 (fxp0)
# anti-spoof rule for external interfaces #
block in log quick on fxp0 inet from to any label
"RULE 0 -- DROP "
#
# Rule 0 (lo0)
# allow loopback to all - required to log onto box #
pass in log quick on lo0 inet from any to any keep state label
"RULE 0 -- ACCEPT "
pass out log quick on lo0 inet from any to any keep state label
"RULE 0 -- ACCEPT "
#
# Rule 0 (global)
# deny bad combinations of TCP flags
#
block in log quick inet proto tcp from any to any flags U/UA label
"RULE 0 -- DROP "
block in log quick inet proto tcp from any to any flags RF/RF
label "RULE 0 -- DROP "
block in log quick inet proto tcp from any to any flags RS/RS
label "RULE 0 -- DROP "
block in log quick inet proto tcp from any to any flags SF/SF
label "RULE 0 -- DROP "
block in log quick inet proto tcp from any to any flags
UAPRSF/UAPRSF label "RULE 0 -- DROP "
block in log quick inet proto tcp from any to any flags /UAPRSF
label "RULE 0 -- DROP "
block in log quick inet proto tcp from any to any flags UPF/UAPRSF
label "RULE 0 -- DROP "
block in log quick inet proto tcp from any to any flags UPSF/UAPRSF
label "RULE 0 -- DROP "
block in log quick inet proto tcp from any to any flags
UARSF/UAPRSF label "RULE 0 -- DROP "
block out log quick inet proto tcp from any to any flags U/UA label
"RULE 0 -- DROP "
block out log quick inet proto tcp from any to any flags RF/RF
label "RULE 0 -- DROP "
block out log quick inet proto tcp from any to any flags RS/RS
label "RULE 0 -- DROP "
block out log quick inet proto tcp from any to any flags SF/SF
label "RULE 0 -- DROP "
block out log quick inet proto tcp from any to any flags
UAPRSF/UAPRSF label "RULE 0 -- DROP "
block out log quick inet proto tcp from any to any flags /UAPRSF
label "RULE 0 -- DROP "
block out log quic
RE: Solution Request: I need to initiate outbound PPTP requests thru FreeBSD firewall
Ok, this is not a PPTP connection from the internet TO a box on the internal LAN. This is a problems with making a PPTP connection from the internal LAN to any PPTP server out on the internet. Thus, TCP 1723 and GRE are not the issue. I am passing ALL from the internal LAN to the internet. I used FWBuilder to create the policy for the FreeBSD box. When I install Linux 2.6 in place of the freebsd box, and use the exact same FWBuilder ruleset, then outbound PPTP works great. Any other thoughts? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Melameth, Daniel D. Sent: Saturday, March 11, 2006 12:27 AM To: pf@benzedrine.cx Subject: RE: Solution Request: I need to initiate outbound PPTP requests thru FreeBSD firewall Chris Willis wrote: > I have setup a FreeBSD box running PF for a client. It is the > 'firewall' for their internal LAN. > > I cannot make an outbound VPN connection from their LAN to any other > microsoft PPTP VPN server. > > The VPN connections work fine from any machine that plugs in to the > hub in FRONT of the firewall (static public IP), but that obviously > isn't the solution. > > What changes need to be made to the ruleset to allow outbound PPTP > connections? Here is the existing NAT rule I though might work based > on browsing the Archives: > > nat on fxp0 proto udp from 172.16.0.0/16 port = 500 to any -> > 206.135.37.226 port 500 > > But it didn't help at all. I put that rule both in front of, and > behind, the regular NAT rule for outbound network traffic. I hate to say it Chris, but have you bothered to even find out what ports/protocols PPTP actually uses? Perhaps TCP 1723 and GRE?
Solution Request: I need to initiate outbound PPTP requests thru FreeBSD firewall
I have setup a FreeBSD box running PF for a client. It is the 'firewall' for their internal LAN. I cannot make an outbound VPN connection from their LAN to any other microsoft PPTP VPN server. The VPN connections work fine from any machine that plugs in to the hub in FRONT of the firewall (static public IP), but that obviously isn't the solution. What changes need to be made to the ruleset to allow outbound PPTP connections? Here is the existing NAT rule I though might work based on browsing the Archives: nat on fxp0 proto udp from 172.16.0.0/16 port = 500 to any -> 206.135.37.226 port 500 But it didn't help at all. I put that rule both in front of, and behind, the regular NAT rule for outbound network traffic. Chris Willis Director of Technology & Services Castellan Inc. - Microsoft GOLD Certified Partner 818-789-0088 x203 www.castellan.net [EMAIL PROTECTED]
RFC - my firewall ruleset
I would like to know what I can do to improve my firewall ruleset. This exact set
protects my own internal LAN (8 computers), and includes P2P rules. I have similar
rulesets protecting other networks I have worked on, none with more than 300 clients
though.
# pF.conf working for Wall
# Variables & Tables
int_dev="xl0" # Internal network device.
ext_dev="ep0" # External network device.
cwork="{ bunch of IPs here }"
overpeer="{ 64.15.228.160/27 }"
max_mss="1432"
unrouteable="{ 0/8, 10/8, 127/8, 169.254/16, 172.16/12, 192.0.2/24, 192.168/16 }"
ext_bandwidth="1544Kb"
# Options
set optimization conservative
set loginterface $ext_dev
# Normalize (defragment) packets on External Interface
scrub in on $ext_dev all fragment reassemble
scrub out on $ext_dev all max-mss $max_mss fragment reassemble
# NAT Rules
# only internal LAN gets NAT currently
nat on $ext_dev from 192.168.1.0/24 to any -> $ext_dev
# Port Forwarding Rules
rdr on $ext_dev proto tcp from any to any port 443 -> 192.168.1.2 port 443
rdr on $ext_dev proto tcp from any to any port 892 -> 192.168.1.2 port 892
rdr on $ext_dev proto udp from any to any port 4665 -> 192.168.1.2 port 4665
rdr on $ext_dev proto tcp from any to any port 4662 -> 192.168.1.2 port 4662
rdr on $ext_dev proto tcp from any to any port 2000 -> 192.168.1.2 port 2000
rdr on $ext_dev proto tcp from any to any port 222 -> 192.168.1.2 port 222
rdr on $ext_dev proto tcp from any to any port 6774 -> 192.168.1.2 port 6774
rdr on $ext_dev proto tcp from any to any port 3389 -> 192.168.1.2 port 3389
rdr on $ext_dev proto tcp from any to any port 6699 -> 192.168.1.2 port 6699
rdr on $ext_dev proto udp from any to any port 6257 -> 192.168.1.2 port 6257
rdr on $ext_dev proto udp from any to any port 1494 -> 192.168.1.2 port 1494
# Deny all connections - default packet filter rule
block in log on $ext_dev from any to any label "block_in_all"
# pass all loopback traffic
pass in quick on lo0 all
pass out quick on lo0 all
# block out all Microsoft AD & Netbios traffic
# mainly a paranoia rule
block out log quick on $ext_dev inet proto tcp from any to any port 445
block out log quick on $ext_dev inet proto udp from any to any port { 138, 137, 139
}
# Outbound Connection Rules for External Interface
pass out quick on $ext_dev proto tcp all modulate state
pass out quick on $ext_dev proto udp all keep state
pass out quick on $ext_dev proto icmp all keep state
# Block in all invalid combos of TCP flags & Log them
# these rules exist mainly to log these packets so I can curse at the bad people
block in log quick on $ext_dev inet proto tcp from any to any flags /UAPRSF
block in log quick on $ext_dev inet proto tcp from any to any flags F/AF
block in log quick on $ext_dev inet proto tcp from any to any flags P/AP
block in log quick on $ext_dev inet proto tcp from any to any flags U/UA
block in log quick on $ext_dev inet proto tcp from any to any flags RF/RF
block in log quick on $ext_dev inet proto tcp from any to any flags SF/SF
block in log quick on $ext_dev inet proto tcp from any to any flags RS/RS
block in log quick on $ext_dev inet proto tcp from any to any flags UPF/UAPRSF
block in log quick on $ext_dev inet proto tcp from any to any flags UPSF/UAPRSF
block in log quick on $ext_dev inet proto tcp from any to any flags UARSF/UAPRSF
block in log quick on $ext_dev inet proto tcp from any to any flags UAPRSF/UAPRSF
# Rules to allow incoming traffic for internal services & P2P traffic
pass in quick on $ext_dev proto tcp from any to 192.168.1.2 port
{443,892,222,1494,3389,2000} flags S/SA modulate state
pass in quick on $ext_dev proto tcp from any to $ext_dev port=22 flags S/SA modulate
state
pass in log quick on $ext_dev proto tcp from any to $ext_dev port=25 flags S/SA
modulate state
pass in on $ext_dev proto udp from any to 192.168.1.2 port {4665,6257} keep state
pass in on $ext_dev proto tcp from any to 192.168.1.2 port {4662,6774,6699} modulate
state
# block and log incoming packets from reserved address space and invalid addresses
block in log on $ext_dev inet from $unrouteable to any
# properly respond to ident protocol also
block return-rst in proto tcp from any to any port { 111, 6000, 6667 }
block return-icmp in proto udp from any to any port { 137 }
# block Overpeer shit
block in on $ext_dev inet from $overpeer to any
Re: Newbie Question (one of many to come)
I did not want to discuss the particular application, as it was developed by an outside vendor for us to use. It is a confidential app. Besides, the application is not of consequence. The logistical problems don't seem that big of a deal. If the server records that 192.168.100.100 sends out tcp 5000 packets to 20.20.20.20, then it should have no problem knowing that udp 4900-1 should go back to 192.168.100.100. Heck, it probably isn't even much extra code. You can translate all you wish - that is not my fault that you are putting words into my email that I never typed. Actually, the mod that I proposed would be great with the majority of IM and P2P clients out there, wouldn't it? And finally, you say that sysadmins would ruin rulesets? Why are you so intent on treating people like children? You should operate on the assumption that people are perfectly capable of writing a good ruleset. When you operate on the assumption that people are incompetent, you just come off as very arrogant. I certainly don't enjoy dealing with arrogant people. -Original Message- From: Jolan Luff <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Mon, 12 Aug 2002 13:38:17 -0400 Subject: Re: Newbie Question (one of many to come) > On Mon, Aug 12, 2002 at 10:16:34AM -0700, Chris Willis wrote: > > I am puzzled still. No one can explain why it is bloated junk. It > would > > assist people who need to handle complex applications with their > firewall. > > Daniel gave a rather good explanation as to the logistical problems to > implement something such as this. He also pointed out why it is > somewhat pointless. Adding complexities such as this to pf for little > gain means bloat. Think of it as "cost benefit analysis". > > When you say "It would assist people..." I translate that as "me". > When you say "handle complex applications" I translate that as "create > a good method for system administrators to ruin rulesets". > > Of course, if you took the time to reply to Daniel's last e-mail on the > subject and explained in more detail what the particulars of this > application are, maybe people would be more receptive. > > - jolan
Re: Newbie Question (one of many to come)
I am puzzled still. No one can explain why it is bloated junk. It would assist people who need to handle complex applications with their firewall. Anyways, it isn't a big deal. I understand that netfilter on Linux can perform this functionality. I will simply switch over to a Linux box as my firewall. Thanx everyone! Chris -Original Message- From: Henning Brauer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Mon, 12 Aug 2002 10:25:24 +0200 Subject: Re: Newbie Question (one of many to come) > On Sat, Aug 10, 2002 at 06:21:26PM -0700, Chris Willis wrote: > > enet = ne3 > > inet = xl0 > > X=192.168.100.100 > > If port 5000 from $X to any on $inet then > > pass all in $enet udp 4900-4901 > > rdr udp 4900-4901 to $X > > else block in all in $enet udp 4900-4901 > > > > X should be variable (depending on what machine is trying to do the > > outbound traffic) > > enet is my external network card (attached to a router on the > internet) > > inet is my internal LAN (192.168.100.1) > > > > This would not require any authentication, since my internal > workstation > > is a trusted entity already (its my own computer). > > > > This would be VERY useful functionality to have in pF. > > No. That's bloated junk. >
RE: Newbie Question (one of many to come)
Why would an attacker fine-tune a firewall? Do you mean that this would be a fine way to fine-tune an attack on a firewall? Sure, I guess it would - all you would have to do is port scan a machine over and over again, until you see those ports open up, then attack the machine thru those ports. But since you can attack thru existing ports anyways (web, ftp, etc..) then who cares if additional ports are open once in a while or not? If the individual admin is OK with the addtional risk, they why would you guys care? -Original Message- From: "Ed White" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Sun, 11 Aug 2002 13:33:58 +0200 Subject: RE: Newbie Question (one of many to come) > > I think it would be an EXCELLENT way for a corporate administrator to > fine-tune their firewall > > to their particular environment. > > I think it would be an EXCELLENT way for an attacker to fine-tune their > firewall to his particular environment. > This is "Security" Through Obscurity. > > Ed >
Re: Newbie Question (one of many to come)
Sorry if this is too wordy. And let me know if it doesn't make any sense. I think I didn't communicate my thoughts clearly. If my Internal Workstation (192.168.100.100) has a stateful connection to the internet (tcp 5000 to 20.20.20.20) that is already open and in your state table(s), then I want pF to allow UDP ports 4900-4901 back to my internal workstation (192.168.100.100). If my internal workstation doesn't have that tcp 5000 port open to an internet address, then I don't want pF to leave 4900&4901 open. Sort of like this (this isn't proper syntax, just my attempt to show the logic behind what I am asking about): enet = ne3 inet = xl0 X=192.168.100.100 If port 5000 from $X to any on $inet then pass all in $enet udp 4900-4901 rdr udp 4900-4901 to $X else block in all in $enet udp 4900-4901 X should be variable (depending on what machine is trying to do the outbound traffic) enet is my external network card (attached to a router on the internet) inet is my internal LAN (192.168.100.1) This would not require any authentication, since my internal workstation is a trusted entity already (its my own computer). This would be VERY useful functionality to have in pF. By having pF look for a trigger port (in this case, a connection outbound on tcp/5000) BEFORE it opens ports for the inbound traffic, you can setup complex rules that only activate when a certain application is requesting communications thru the firewall. I don't think this would be feature bloat - I think it would be an EXCELLENT way for a corporate administrator to fine-tune their firewall to their particular environment. Chris -Original Message- From: Daniel Hartmeier <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Sat, 10 Aug 2002 23:00:14 +0200 Subject: Re: Newbie Question (one of many to come) > On Sat, Aug 10, 2002 at 09:37:15AM -0700, Chris Willis wrote: > > > I would like to create a filter that allows 4900&4901 inbound to the > > machine that already has tcp 5000 open. If tcp 5000 isn't open, then > I > > do not want the UDP ports to be open inbound. > > Short answer: you can't. > > I know this is possible with Linux' netfilter, but I don't think it's a > feature that can be used securely. If you think about it, how does the > existing TCP connection authenticate the peer in any way that makes you > trust him more than the rest of the world? Anyone could establish that > TCP connection first and get access to the other ports. If you're not > allowing the whole world to establish the TCP connection (by blocking > on > peer address), you could use the same restrictions for the other ports. > > Ok, someone spoofing the source address couldn't complete a TCP > handshake, so the established TCP connection excludes that. But a > source > spoofer could just as well pick an address that is likely to have a TCP > connection already established with you and use that to send UDP > packets. > > There is a way to open ports after peers have truely authenticated > themselves: authpf(8). Logging in via ssh might seem overly > complicated, > but what you get in exchange is a real authentication, as compared to > security by obscurity that the 'related' (or whatever it's called in > netfilter) feature offers. > > Daniel
Newbie Question (one of many to come)
How can I setup a packet filter that works with a trigger? Example: I have an app that uses TCP 5000 for its connection state info, and UDP 4900 & 4901 for the actual work. I would like to create a filter that allows 4900&4901 inbound to the machine that already has tcp 5000 open. If tcp 5000 isn't open, then I do not want the UDP ports to be open inbound. Thanx! Chris
