Re: dump pflog to a database
i am working on an app for this right now (with a web-based monitoring tool), though it should be a short while until i get it done, due to other constraints there is a conversion tool that takes pf logs and formats them to xml output, if that is of any use to you (http://monkey.org/~jose) - as referenced in a recent post to this list scott On Tue, 18 Mar 2003, Sid Keller wrote: Is there an easy way to get pflog information into a database? I don't need for pf to log directly to a database, I would just like to be able to take data from the pflog file and load it into a database, specifically a postgresql database. Any ideas or thoughts on how to do this? -- Sid
Re: problem with port 443 traffic
port 443 (ms sql server traffic) is being blocked because you dont have a
rule to pass it in
your ruleset allows only smtp, ssh, and https to come in, everything else
is being blocked
is that the only problem you are having? or is the email not functioning
properly either?
scott
On Tue, 18 Mar 2003, Sid Keller wrote:
I having some problems with my rulesets for an email server. The server
is not behind a firewall but I have pf enabled on the server. Here is
my ruleset.
###
#--
# Variable Section
#--
int_if=fxp0
nonroute={ 192.168.1.0/24, 172.16.0.0/12, 127.0.0.0/8, 10.0.0.0/8,
0.0.0.0/8 }
approved_mgmt_net={ x.x.x.x }
server_ip={ x.x.x.x }
#
#
#Firewall Rulebase Begin
#
#
#
#--
#Packet Normalization (deny fragmented packets)
#--
scrub in all
#--
#Default Deny
#--
block in log all
#--
#Allow Loopback Packets
pass in quick on lo0 all
pass out quick on lo0 all
#--
#Drop Spoofed Packets
#--
block in log quick on $int_if from $nonroute to any
block out log quick on $int_if from any to $nonroute
#--
#Drop wrong TCP Flags
#--
block in quick on $int_if inet proto tcp from any to any flags FUP/FUP
#--
#--
#Firewall RULES
#--
pass in quick on $int_if inet proto tcp from $approved_mgmt_net to
$server_ip port ssh
pass in quick on $int_if inet proto tcp from any to $server_ip port
https flags S/SA modulate state
pass in quick on $int_if inet proto tcp from any to $server_ip port {
smtp } flags S/SA modulate state
#--
#Allow Return Traffic and Connection From Firewall
#--
pass out on $int_if inet proto { tcp, udp, icmp } all keep state
Here is a snippet from my pflog file using tcpdump -n -e -ttt.
Mar 07 10:58:10.177507 rule 1/0(match): block in on fxp0:
user.ip.address.1501 my.ip.address.443: F 71818460:71818460(0) ack
3194040235 win 5549 (DF)
Mar 07 10:58:10.183314 rule 1/0(match): block in on fxp0:
user.ip.address.1502 my.ip.address.443: F 71819657:71819657(0) ack
963312026 win 5549 (DF)
Mar 07 11:52:59.986506 rule 1/0(match): block in on fxp0:
user.ip.address.1586 my.ip.address.443: R 75169994:75169994(0) win 0 (DF)
Mar 07 11:52:59.990614 rule 1/0(match): block in on fxp0:
user.ip.address.1585 my.ip.address.443: R 75170656:75170656(0) win 0 (DF)
I'm curious as to why the above traffic is being block on port 443.
Thanks for your help. Any other suggestions concerning my ruleset would
be greatly appreciated.
--
Sid Keller
Re: problem with port 443 traffic
as for why they are getting blocked: dont modulate state, keep state on the https this works for me jack the timeouts up (use the conservative optimization level). IIS and IE do some funky shit with how they honor the tcp FIN flag. the default timeouts could drop the connection after 15 minutes of idle time if one endpoint doesn't honor the other endpoints close request (FIN flag). alternatately, you could put a flags S/SA on the 'modulate state' rule and return-rst non S/SA packets. that _should_ work (it may depend on the browser). .mike
pf(4) schemantics
While working on a pf(4) tutorial/article, I started wondering about the following,
1. What's the reason why packets 'travel' across an interface twice
(both in and out)? This makes, IMHO, writing very tight rules a bit
tricky. Especially if you want to start off with 'block all'.
2. Say I 'block all' and then want to pass some traffic from $net_a to
$net_b. First, I need 2 rules to allow {in,out} traffic from $net_a and
then 2 rules to allow {in,out} traffic back from $net_b. Sure, you can
group the {in,out} rules in one, i.e. pass from $net_a to $net_b.
Now, what could be very nice is to pf(4) behave more like the following,
- from pf(4) point of view, there is only inbound traffic from an
interface. I.e. all traffic originating from $net_a towards other
networks is always inbound for pf(4).
- when I write a rule like 'pass from $net_a to $net_b', I don't need
to write another rule saying 'pass from $net_b to $net_a'. pf(4) takes
care of that (we are statefull, right?)
- say I have 5 interfaces (or 10 VLANs) I filter on. However, not all of
the networks need to talk to each other. I.e. I could have a $net_c
that will not talk to $net_a, but will talk to $net_b. It could be
nice to be able to define this. Otherwise, the traffic never gets
routed by pf(4).
People that know a certain commerical firewall will recognize this
behaviour. Don't get me wrong, I love pf(4), but there might be room for
improvement.
Comments?
// haver
Re: Routing private networks
On Wed, Mar 19, 2003 at 01:37:35PM -0800, Bryan Irvine wrote: What I want is for the 192.168.0.* and 10.0.*.* networks to see each other just fine. Which is possible to do with routing, but then for these networks to get onto the internet I have to turn on NAT (or do I?) which makes the 2 networks invisible to each other except via rdr rules, which won't work for this scenario. Look at 'no nat ...' in pf.conf(5). You can define a rule saying, if 192.168.0.* and 10.0.*.* need to talk to public addresses, nat them, otherwise, don't.
Re: Routing private networks
So would I need to turn on RIP at all? Or would it just know because it's a directly connected interface? --Bryan On Wed, 2003-03-19 at 14:07, Srebrenko Sehic wrote: On Wed, Mar 19, 2003 at 01:37:35PM -0800, Bryan Irvine wrote: What I want is for the 192.168.0.* and 10.0.*.* networks to see each other just fine. Which is possible to do with routing, but then for these networks to get onto the internet I have to turn on NAT (or do I?) which makes the 2 networks invisible to each other except via rdr rules, which won't work for this scenario. Look at 'no nat ...' in pf.conf(5). You can define a rule saying, if 192.168.0.* and 10.0.*.* need to talk to public addresses, nat them, otherwise, don't.
Re: pf(4) schemantics
On Wed, Mar 19, 2003 at 11:04:26PM +0100, Srebrenko Sehic wrote:
While working on a pf(4) tutorial/article, I started wondering about the following,
1. What's the reason why packets 'travel' across an interface twice
(both in and out)? This makes, IMHO, writing very tight rules a bit
tricky. Especially if you want to start off with 'block all'.
?
they come in on one interface and eventually go out on an interface. might
be the same, might be different, depending on routing table and destination.
2. Say I 'block all' and then want to pass some traffic from $net_a to
$net_b. First, I need 2 rules to allow {in,out} traffic from $net_a and
then 2 rules to allow {in,out} traffic back from $net_b. Sure, you can
group the {in,out} rules in one, i.e. pass from $net_a to $net_b.
Now, what could be very nice is to pf(4) behave more like the following,
- from pf(4) point of view, there is only inbound traffic from an
interface. I.e. all traffic originating from $net_a towards other
networks is always inbound for pf(4).
- when I write a rule like 'pass from $net_a to $net_b', I don't need
to write another rule saying 'pass from $net_b to $net_a'. pf(4) takes
care of that (we are statefull, right?)
eek?
- say I have 5 interfaces (or 10 VLANs) I filter on. However, not all of
the networks need to talk to each other. I.e. I could have a $net_c
that will not talk to $net_a, but will talk to $net_b. It could be
nice to be able to define this. Otherwise, the traffic never gets
routed by pf(4).
what? pf never routes traffic until explicitely told to route via route-to.
then what you want in these cases with a shitload of (probably
vlan-)interfaces, is to define the policy on each. wait, ascii art.
---
vlan1| |
vlan2| |
vlan3| |-uplink1
vlan4| |
vlan5| OpenBSD |
vlan6| |
vlan7| |-uplink2
vlan8| |
vlan9| |
vlan0| |
---
hmm, suprise, that looks exactly like my setup ;-)
so, let's go on. in vlan01, you have just a webserver. the policy is easy:
pass out on vlan1 proto tcp to $vlan1_webserver port { 80 443 } \
keep state
pass in on vlan1 proto { tcp udp } to $resolvers port 53 \
keep state
that's it, basically. might want to add ssh.
in vlan02, you have just a smtp server, and apply similar rules.
on the external interfaces, let's call them dc0 and dc1, you just do spoof
protection.
int_nets={ vlan1-network vlan2-network .. vlan10-network }
ext_ifs={ dc0 dc1 }
block on $ext_ifs
pass on lo0 quick
block in quick to self
pass in on $ext_ifs to $int_nets keep state
pass out on $ext_ifs from $int_nets keep state
that's it, basically. add some rules to allow some icmp, the box itself to
reach its resolvers etc, and you are done.
with hammering the policy for each vlan on the vlan interface, you have
something very nice achieved. if a box on vlan1 wants to reach a box in
vlan7, it needs to pass the outgoing policy for vlan1 as well as the
incoming one for vlan7.
the only little confusing thing is that all directions are logically
backwards. passing traffic to a webserver _IN_ results in a rule like pass
_OUT_ on vlan1 ... (emphasis added, of course). but that you get used to
quickly.
so, I really don't get what you are proposing.
People that know a certain commerical firewall will recognize this
behaviour. Don't get me wrong, I love pf(4), but there might be room for
improvement.
sure, there always is.
Comments?
explain better ;-)
--
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)
Re: pf(4) schemantics
On Thu, Mar 20, 2003 at 12:19:13AM +0100, Srebrenko Sehic wrote:
On Wed, Mar 19, 2003 at 11:27:26PM +0100, Henning Brauer wrote:
1. What's the reason why packets 'travel' across an interface twice
(both in and out)? This makes, IMHO, writing very tight rules a bit
tricky. Especially if you want to start off with 'block all'.
they come in on one interface and eventually go out on an interface. might
be the same, might be different, depending on routing table and destination.
Well, yeah, they do, but why have pf(4) look at them both on in and out
and on the same interface?
who says same interface here??
2. Say I 'block all' and then want to pass some traffic from $net_a to
$net_b. First, I need 2 rules to allow {in,out} traffic from $net_a and
then 2 rules to allow {in,out} traffic back from $net_b. Sure, you can
group the {in,out} rules in one, i.e. pass from $net_a to $net_b.
Now, what could be very nice is to pf(4) behave more like the following,
- from pf(4) point of view, there is only inbound traffic from an
interface. I.e. all traffic originating from $net_a towards other
networks is always inbound for pf(4).
- when I write a rule like 'pass from $net_a to $net_b', I don't need
to write another rule saying 'pass from $net_b to $net_a'. pf(4) takes
care of that (we are statefull, right?)
eek?
No clear? Let me rephrase. Why not filter on inbound traffic only, even
though you have 'block all' in your ruleset?
this is like asking why your car engine doesn't work even given you have
fuel in a tank on the seat.
if you want that, you don't do block all, but block in all and let
outgoing traffic pass unconditionally. easy, eh?
The commerical firewall I was talking about previously is Cisco PIX.
The first PIX was cool: you could install OpenBSD on it without trouble ;-)
net_a -- pf(4) --- net_b, and _not_
net_a - pf(4) --- net_b
yeah, and IPF behaved the same, and this behaviour is stopid. makes the
setup I drawed below impossible. you can have the same with pf by passing
outbond unconditionally.
- say I have 5 interfaces (or 10 VLANs) I filter on. However, not all of
the networks need to talk to each other. I.e. I could have a $net_c
that will not talk to $net_a, but will talk to $net_b. It could be
nice to be able to define this. Otherwise, the traffic never gets
routed by pf(4).
what? pf never routes traffic until explicitely told to route via route-to.
then what you want in these cases with a shitload of (probably
vlan-)interfaces, is to define the policy on each. wait, ascii art.
Of course, kernel does, pf(4) only looks at the traffic. However, it
might be useful is certain situations. Like, 10 VLAN's, but I only want
to filter on 5. With a rule 'block all', all 10 VLAN traffic would be
blocked, right?
so block only on those interfaces you wanna filter on? like, this is
obvious, hmm?
To rephrase, it could be nice if I could define which interfaces pf(4)
should care about. Something like,
set filter interface {vlan01, vlan02, vlan03}
indeed I have something like this in mind, but purely for performance
reasons. might add that after 3.3. perhaps not. we'll see.
and assuming you have 'block all'. Right?
no, read on.
and HELL, you say all the time you do not want block all, so why are you
doing block all in your ruleset???
Well, you managed to confuse me now. Let's throw in some simplified
ascii and sample rules,
$ext_if - pf(4) $int_if
ext_if = fxp0
int_if = fxp1
ext_net = 192.168.0.0/24
int_net = 192.168.1.0/24
webserver = 192.168.1.2/32
block in all
block out all
## allow traffic on $ext_if to $webserver on 80/tcp and 443/tcp
pass in on $ext_if proto tcp from any to $webserver port {80, 443} \
keep state
This would not work. Why? We need to pass out on $ext_if as well (since
pf(4) filters on both directions). Not only that, we need to pass in/out
on $int_if as well, since 'block in/out all' applies to all interfaces.
ARRRGGG!
s/block out all// and you are done! you obviously do not want to block
outgoing, so why do you tell pf to do so? why?
What could be nice is to have this kind of rule working. pf(4) could
allow traffic back from $webserver, even though I have 'block in/out
all'. This is how PIX works.
and this is how ipf worked, and it was majorly stupid, because the setuop I
described is no more possible then, while you just pass outgoing
unconditionally and HAVE what you are asking already, and that since the
first pf incarnation in OpenBSD 3.0.
Am I being a bit more clear now? Or am I _totally_ misunderstanding
pf(4) innerworkings? ;)
you are just thinking very wrong. you are telling pf to block traffic which
goes OUT on an interface, and complain that pf blocks traffic which is
outgoing on one interface. but you told pf to! so don't tell it to, pass
poutgoing unconditionally, case
Re: pf(4) schemantics
On Wednesday, Mar 19, 2003, at 15:19 US/Pacific, Srebrenko Sehic wrote:
block in all
block out all
## allow traffic on $ext_if to $webserver on 80/tcp and 443/tcp
pass in on $ext_if proto tcp from any to $webserver port {80, 443} \
keep state
This would not work. Why? We need to pass out on $ext_if as well (since
pf(4) filters on both directions).
In this specific case, the keep state option will allow traffic back
out on $ext_if, from $webserver, provided it is related to the original
tcp port {80, 443} traffic that triggered it. You do not need any other
pass out on $ext_if rules for $webserver for this purpose.
Are you unsure what stateful behavior is?
Re: Testing 3.3: ackpri = /etc/pf.conf
* Max Laier [EMAIL PROTECTED] [030319 19:10]: I think you should add this _cool_ feature to the sample pf.conf in /etc ... it's hidden in /usr/share/pf/ in the current snapshot and in order to announce it some more you should maybe put an exsample in the /etc/pf.conf file for everybody to see. btw, a link to your tutorial and motivation (http://www.benzedrine.cx/ackpri.html) in /usr/share/pf/ackpri couldn't hurt. I don't think this should go in /etc/pf.conf. The example /etc/pf.conf should be as minimal and simple as possible, while giving examples of each type of statement. We don't want to overwhelm the user with many different things. The default file should be very basic. That said, some of the other developers may have a differing opinion. Also, it's not really hidden. The first sentence of /etc/pf.conf says See pf.conf(5) and /usr/share/pf for syntax and examples. What I would really like to see is people contribute some more examples for /usr/share/pf. If anybody has a really interesting ruleset then post it and we'll see if it's worth including there. David
