Is there any plan to add the time based filtering feature in PF
Hi all, This question is primarily to the PF developers :)) Thankyou so much for all your great work and effort to give us an excellent firewall!! I would like to know if there is any plan among PF developers to add the feature to filter traffic based on time. I mean a way by which I can pass traffic during a particular time period by a rule like pass in on $ext_if proto tcp from any to $comp3 port 80 \ time 05:00 06:00 \ flags S/SA synproxy state May I also know from all who read this how this type of filtering is implemented with OpenBSD presently? Thankyou So much Kind Regards Siju
block return doesn't return rst
I seem to not be getting the intended behavior from a NAT box. What I was
hoping is to limit services to the firewall after allowing a few ports in
(ftp, ssh, http, https, etc). But when I use the following rules, I do not
get RST's when connecting to $wlan_if on any other port (i.e. 54199, etc).
The logs show the connection attempt as being blocked, but the
connecting-host has to wait for the connection to time-out.
Any help is appreciated; I'm running 3.6-CURRENT. Thanks.
##
#; Variables
##
loopbk = lo0
ext_if = de0
wlan_if = fxp0
ipsec_if= enc0
donald = 10.116.131.13
daisy = 10.116.131.14
cirque = 10.116.131.15
broadcast = 255.255.255.255
ps2 = 10.116.131.27
ap = 10.116.131.31
lp = 10.116.131.94
cp = 10.116.131.97
edp = { $cirque }
jap = { $daisy }
tcp_wlanif = { ftp, ssh, http, https }
ps2_wlanif = { ftp, http, https }
table dpu persist { x.4.180, x.4.81.181, \
x.4.81.182, x.4.21.128/29 }
table nxious persist { y.42.42.14, x.4.16.40 }
table olt persist { 110.3.43.1, 110.52.36.84 }
table bogon persist file /etc/bogon.txt
aspf = antispoof log
bi= block in
bo= block out
bil = block in log
biq = block in quick
bol = block out log
boq = block out quick
bilq = block in log quick
bolq = block out log quick
blk = block
pqk = pass quick
pi= pass in
po= pass out
pil = pass in log
piq = pass in quick
pol = pass out log
poq = pass out quick
pilq = pass in log quick
polq = pass out log quick
ks= keep state
ms= modulate state
ss= synproxy state
##
#; Set logging of stats on the given interface.
##
set loginterface $ext_if
set timeout { interval 10, frag 27 }
set limit { frags 45000, states 35000 }
set optimization aggressive
set block-policy return
##
#; NAT/RDR
##
scrub out all no-df random-id max-mss 1440
scrub in all no-df fragment reassemble min-ttl 3
nat on $ext_if from $wlan_if:network to any - ($ext_if)
rdr on $wlan_if proto tcp from any to any port 21 - 127.0.0.1 port 8021
##
#; Rules
##
block return log all label
$nr:$if-block-log
$pqk on lo0 alllabel $nr:$if-pass
$bilq on $ext_if from bogonto any label $nr:$if-bogon
$bilq on $wlan_if from { bogon, !$wlan_if:network } to any label
$nr:$if-bogon
$biq on $ext_if from any to $broadcast label
$nr:$if-broadcast
$poq inet proto tcp all flags S/SA label $nr:$if-pass-synack-out $ms
$poq inet proto tcp alllabel $nr:$if-pass-tcp-out$ks
$poq inet proto udp alllabel $nr:$if-pass-udp-out$ks
$poq inet proto icmp alllabel $nr:$if-pass-icmp-out $ks
$poq alllabel $nr:$if-pass-ip-out
### Allowed from local network to wlan_if
$piq on $wlan_if inet proto tcp \
from $edp to $wlan_if port $tcp_wlanif label $nr:$if-edp-$dstport-in $ms
$piq on $wlan_if inet proto tcp \
from $jap to $wlan_if port $tcp_wlanif label $nr:$if-jap-$dstport-in $ms
$piq on $wlan_if inet proto tcp \
from $ps2 to $wlan_if port $ps2_wlanif label $nr:$if-ps2-$dstport-in $ms
$poq on $wlan_if inet proto tcp \
from $wlan_if to $edp port $tcp_wlanif label $nr:$if-edp-$dstport-out $ms
$piq on $wlan_if inet proto udp \
from any to any port bootps label $nr:$if-bootps-in $ks
$piq on $wlan_if inet proto udp \
from $wlan_if:network to $wlan_if port domain label $nr:$if-domain-udp-in
$ks
$piq on $wlan_if inet proto tcp \
from $wlan_if:network to $wlan_if port domain label $nr:$if-domain-tcp-in
$ms
$piq on $wlan_if inet proto udp \
from $wlan_if:network to $wlan_if port ntplabel $nr:$if-ntp-in
$ks
block return in log quick on $wlan_if inet proto { tcp, udp } \
from $wlan_if:network to $wlan_if label $nr:$if-block-in
$bilq on $wlan_if from $wlan_if:network to $wlan_if label
$nr:$if-block-in
$polq on $wlan_if inet proto icmp \
from $wlan_if:network to $ap icmp-type echoreq label
$nr:$if-accesspoint-icmp-out $ks
$polq on $wlan_if inet proto tcp \
from
Re: block return doesn't return rst
On Fri, Jan 28, 2005 at 03:28:26AM -0600, eric wrote:
bilq = block in log quick
block return log all label
$nr:$if-block-log
$bilq on $wlan_if from { bogon, !$wlan_if:network } to any label
$nr:$if-bogon
The second rule expands to two rules
block in log quick on $wlan_if from bogon to any
block in log quick on $wlan_if from !$wlan_if:network to any
If $wlan_if:network is also in bogon, maybe you see where this is
leading :)
You could add the negation of $wlan_if:network to the bogon table
instead.
If you're wondering what other effect expansion has, take a look at the
output of pfctl -sr. Those are the rules that are really in effect.
Also, pfctl -vvsr prints the rule number for each rule, which pflog
entries refer to. So, if you see a packet logged as blocked but get no
RST, you can look up what rule blocked it (instead of the return-rst
rule you thought should have).
Daniel
Re: Is there any plan to add the time based filtering feature in PF
On Fri, 28 Jan 2005 11:35:33 +0100, Daniel Hartmeier [EMAIL PROTECTED] wrote: On Fri, Jan 28, 2005 at 02:29:36PM +0530, Siju George wrote: I would like to know if there is any plan among PF developers to add the feature to filter traffic based on time. I don't think so. There's an endless number of criteria outside of packet contents that someone finds useful to filter on in some case, like CPU load, memory usage, disk usage, geographic location delivered by a GPS receiver, existance of some process, etc. Instead of cluttering the syntax with more and more (obscure) keywords, the better approach seems to be to explain how do this in a generic way, see below ... ... The main ruleset is not affected by this, you can edit and reload pf.conf at any time without destroying the current contents of the anchor. Daniel Thankyou so much Danny!!! That was a very detailed reply!!! i greatly appreciate the fact that you took time to give me a detailed reply in your busy schedule!!! Thankyou so much :))) good luck kind Regards Siju
Re: Is there any plan to add the time based filtering feature in PF
* Siju George [EMAIL PROTECTED] [2005-01-28 10:50]: I would like to know if there is any plan among PF developers to add the feature to filter traffic based on time. no. cron. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
PF suddenly stops allowing certain connections through
Hope everyone is doing well... My question is a little difficult to word, and thus its been impossible for me to find other instances of it by searching this list or google, so hopefully someone can help. We are running pf on v3.4 and for the most part it has worked perfectly for 6 months (with only 2 hard crashes). However, twice now in the past week we've seen it suddenly stop allowing certain connections through, while others come through just fine. The state table is nowhere near even 35% full, and its always just one port that wont get through. In this case it was ssh that was suddenly not allowed. We have these three rules: pass in log on $ext_if proto tcp from xx.xx.xx.xx/24 to any port 22 keep state pass in log on $ext_if proto tcp from any to any port 25 keep state pass in log on $ext_if proto tcp from any to any port 80 keep state Where xx.xx.xx.xx/24 is our class C at our office. Now the problem we see is that all of a sudden ssh is no longer allowed through. There are no entries in the log about connections actually being blocked, but nothing gets through. From multiple IPs on our C block we can hit SMTP and HTTP, just not SSH. Does anyone have any ideas? Anywhere I can look? Need any more information? Thanks, Lyle Worthington
new feature
hello all, Is it (or will be) possible to set different state timeouts for different rules? For example, if I'm using http, and I need to keep the state for 10 minutes because of an e-commerce session, and I dont want to keep the state for smtp for more than 30 seconds. Something like: - set timeout 60 #default timeout # http rule pass out on fxp0 proto tcp from any to any port www keep state timeout 600 # smtp rule pass out on fxp0 proto tcp from any to any port smtp keep state timeout 30 Cheers ;)
Re: new feature
On Fri, Jan 28, 2005 at 10:37:44AM -0800, Gustavo A. Baratto wrote: hello all, Is it (or will be) possible to set different state timeouts for different rules? For example, if I'm using http, and I need to keep the state for 10 minutes because of an e-commerce session, and I dont want to keep the state for smtp for more than 30 seconds. Something like: - set timeout 60 #default timeout # http rule pass out on fxp0 proto tcp from any to any port www keep state timeout 600 # smtp rule pass out on fxp0 proto tcp from any to any port smtp keep state timeout 30 you can do that today: pass out on fxp0 proto tcp from any to any port = www \ keep state (tcp.established 600) pass out on fxp0 proto tcp from any to any port = smtp \ keep state (tcp.established 30) man 5 pf.conf for more details. -j -- Asleep at the switch? I wasn't asleep, I was drunk! --The Simpsons
Re: new feature
On Fri, 28 Jan 2005 10:37:44 -0800, Gustavo A. Baratto [EMAIL PROTECTED] wrote: Is it (or will be) possible to set different state timeouts for different rules? Like this? pass in on vlan101 from vlan101:network to any keep state (max 5000, source-track rule, max-src-states 50, tcp.established 60, tcp.closing 5)
Traffic shaping Q's
I am working on a traffic shaper to simulate modems and other devices, is there a way to add a delay to the packets as they come in and out using pf to simulate latency? I am trying to simulate ADSL connections and I need someway to simulate latency that is inherent from them. I am using a bridge to do it with pf ;). Also as far as using pfstat or a similar program, when using queueing, in order to get the % of the queue's bandwidth being used over a period of time, would you monitor the outgoing interface or is there no way to do this? Amir Mesry [EMAIL PROTECTED] Cadillac Jack, Inc. http://www.cadillacjack.com/ Network Systems Administrator 2420 Meadowbrook Parkway Duluth, GA 30096 770-865-0034
Re: block return doesn't return rst
On Fri, Jan 28, 2005 at 11:44:08AM -0600, eric wrote: Jan 28 11:23:38.565478 rule 40/0(match): block in on fxp0: 10.116.131.15.11723 10.116.131.1.7357: SWE 4179382606:4179382606(0) win 16384 mss 1460,nop,nop,sackOK,[|tcp] [tos 0x10] (ttl 64, id 44969) Jan 28 11:23:44.557060 rule 40/0(match): block in on fxp0: 10.116.131.15.11723 10.116.131.1.7357: S 4179382606:4179382606(0) win 16384 mss 1460,nop,nop,sackOK,[|tcp] [tos 0x10] (ttl 64, id 45638) Look closely at the TCP flags part of those two packets, they are not identical. The first one has SWE set, that means it's SYN with the ECN bits ECE and CWR set. You must have enabled ECN on the client, check # sysctl net.inet.tcp.ecn When ECN is enabled, a host will try to negotiate ECN for outgoing TCP connections. That is, it sets the flags SWE in the initial SYN. If the reply is a RST, it doesn't know for sure whether the peer is not accepting connections on the port at all or whether it just doesn't understand ECN and sent the RST because of the WE flags. Hence, the host will automatically try again without the ECN bits. Because of this automatic retry you get a delayed 'connection refused' error only after the second RST is received. This is a normal effect of ECN support. But when I connect to the host from the outside world to de0 (ext_if), the reset happens immediately. Jan 28 11:24:35.447744 rule 0/0(match): block in on de0: 207.227.243.193.3435 67.175.80.217.7357: S 1276381594:1276381594(0) win 16384 mss 1460,nop,nop,sackOK,[|tcp] (ttl 54, id 22646) The external client seems to have ECN support not enabled in the first place, so it begins with a plain SYN and aborts on the first RST. That should explain it entirely, unless sysctl doesn't agree with the theory :) Daniel
Re: block return doesn't return rst
On Fri, 2005-01-28 at 23:37:37 +0100, Daniel Hartmeier proclaimed... Look closely at the TCP flags part of those two packets, they are not identical. The first one has SWE set, that means it's SYN with the ECN bits ECE and CWR set. You must have enabled ECN on the client, check # sysctl net.inet.tcp.ecn When ECN is enabled, a host will try to negotiate ECN for outgoing TCP connections. That is, it sets the flags SWE in the initial SYN. If the reply is a RST, it doesn't know for sure whether the peer is not accepting connections on the port at all or whether it just doesn't understand ECN and sent the RST because of the WE flags. Hence, the host will automatically try again without the ECN bits. Because of this automatic retry you get a delayed 'connection refused' error only after the second RST is received. This is a normal effect of ECN support. D'oh! Yep, I've been using it for some testing but didn't think much of it (though the SWE caught my eye as something I haven't seen before). The external client seems to have ECN support not enabled in the first place, so it begins with a plain SYN and aborts on the first RST. That should explain it entirely, unless sysctl doesn't agree with the theory :) Everything agrees, many thanks! - Eric
