Re: IP accounting.
Derrick MacPherson wrote:
My setup:
Just about to upgrade the OS from openbsd 2.9 running ipf, to 3.2
running pf.
Upgrade to 3.3beta! It's stable and has more features!
internet
|
firewall
// | \\ (internal networks, each on it's own interface
plus DMZ)
My quest(ion):
I need to track all traffic from each internal network (interfaces de0,
de1, de2 and de3) to and from the internet, plus traffic to and from the
internet for the 2 servers in the DMZ. There is 2 companies, each with a
server in the DMZ, and I need to be able to show for billing the
companies total traffic (in + out for their network + their server in
the DMZ), if I could show incoming and outgoing that would be awesome,
but not absolutely mission critical
What software would you people recommend? I know of ipaudit and ipa, not
sure if they are the right tool, but am looking for any and all input.
There is probably many ways to do that.
Like looking at rule counters.
One thing new in 3.3 that might be useful, is to use the
new table feature and the in/out counters in it.
For example, you could do something like that:
table persist { $ip_dmz_a, $ip_dmz_b }
pass out on $dmz_if from any to
pass in on $dmz_if from to any
After that, doing a "pfctl -t dmz -vvTs" will
give you in/out statistics of your 2 servers usage
in the DMZ. You could do that every day.
Reloading your ruleset will not kill the statistics data.
Cedric
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
IP accounting.
My setup: Just about to upgrade the OS from openbsd 2.9 running ipf, to 3.2 running pf. internet | firewall // | \\ (internal networks, each on it's own interface plus DMZ) My quest(ion): I need to track all traffic from each internal network (interfaces de0, de1, de2 and de3) to and from the internet, plus traffic to and from the internet for the 2 servers in the DMZ. There is 2 companies, each with a server in the DMZ, and I need to be able to show for billing the companies total traffic (in + out for their network + their server in the DMZ), if I could show incoming and outgoing that would be awesome, but not absolutely mission critical What software would you people recommend? I know of ipaudit and ipa, not sure if they are the right tool, but am looking for any and all input. If you want to respond offline, I will submit my final decisions to the list(s).. Thanks everyone. Derrick
Testing 3.3: ackpri => /etc/pf.conf
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. that's all for the moment Max
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: 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 comp
Re: pf(4) schemantics
On Wed, Mar 19, 2003 at 04:30:37PM -0700, [EMAIL PROTECTED] wrote:
> > Well, yeah, they do, but why have pf(4) look at them both on in and out
> > and on the same interface?
>
> Well, among other reasons, because traffic can originate on the firewall.
>
> > set filter interface {vlan01, vlan02, vlan03}
> >
> > The rest is invisible to pf(4).
>
> er:
>
> set trusted_ifs {vlan04, vlan05, ..., vlan09, lo0}
> pass in quick on $trusted_ifs all
> pass out quick on trusted_ifs all
>
> am I missing something?
no ;-)
well, to mimic the PIX even more close, just
pass out all
--
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
> Well, yeah, they do, but why have pf(4) look at them both on in and out
> and on the same interface?
Well, among other reasons, because traffic can originate on the firewall.
> set filter interface {vlan01, vlan02, vlan03}
>
> The rest is invisible to pf(4).
er:
set trusted_ifs {vlan04, vlan05, ..., vlan09, lo0}
pass in quick on $trusted_ifs all
pass out quick on trusted_ifs all
am I missing something?
-kj
Re: pf(4) schemantics
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?
> > 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?
The commerical firewall I was talking about previously is Cisco PIX. It
behaves likes this. Ascii art comming,
net_a --> pf(4) <--- net_b, and _not_
net_a <-> pf(4) <---> net_b
> > - 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?
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}
The rest is invisible to pf(4).
> ---
> vlan1||
> vlan2||
> vlan3||-uplink1
> vlan4||
> vlan5| OpenBSD |
> vlan6||
> vlan7||-uplink2
> vlan8||
> vlan9||
> vlan0||
> ---
nice art ;)
> 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
What's your external inteface (assuming vlan01 is behing a firewall)?
Say it's vlan11. Hence, you need
pass in on vlan11 proto tcp to $vlan1_webserver port { 80 443} \
keep state
pass out on vlan11 proto tcp to $vlan1_webserver port { 80 443} \
keep state
and assuming you have 'block all'. Right?
> 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
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: Routing private networks
On Wed, Mar 19, 2003 at 02:15:10PM -0800, Bryan Irvine wrote: > So would I need to turn on RIP at all? Or would it just "know" because > it's a directly connected interface? Sure, if those 2 interfaces are directly connected, then pf(4) can filter/route traffic (and do translation) without problems. No need for rip.
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: 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.
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
Routing private networks
Is there a way to have an OpenBSD router route to the internet and also rout private IP's between interfaces? ie: (INTERNET CLOUD)-(ROUTER)(OBSD FIREWALL)(DMZ) | | | | | (subnetted 10.0.*.*) | (192.168.0.*) 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. Any ideas? Help! 192.168.0.* is down to 1 IP address and we need to get a new network turned on ASAP!! --Bryan
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
Re: problem with port 443 traffic
oops, sorry bout that, was a long nite last nite... got my ports all
fuxored
as for why they are getting blocked:
dont modulate state, keep state on the https
this works for me
as for the why:
not sure, my guess is it has something to do with the duration of time.
since modulate state changes the sequence numbers, if the connection loses
state (they write a really long email), then the sequence will not be
found when trying to match and thus need to re-init the connection (but i
would also think the same would happen when keep state is dropped)
(i am no expert, and that explanation is very suspect, and im sure someone
else can explain it better) the blind leading the blind...
scott
On Wed, 19 Mar 2003, Sid Keller wrote:
> This box contains both the web and email server. Our employees only
> access the email server via a web client through https (port 443, ms sql
> server is 1433 and 1434). Everyone can connect however some people get
> a "Page cannot be displayed" message with Internet Explorer when trying
> to send an email. I think this is happening because pf is blocking some
> of the port 443 traffic and I don't know why.
>
> Thanks,
>
> Sid
>
>
> [EMAIL PROTECTED] wrote:
> > 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.
Re: problem with port 443 traffic
This box contains both the web and email server. Our employees only
access the email server via a web client through https (port 443, ms sql
server is 1433 and 1434). Everyone can connect however some people get
a "Page cannot be displayed" message with Internet Explorer when trying
to send an email. I think this is happening because pf is blocking some
of the port 443 traffic and I don't know why.
Thanks,
Sid
[EMAIL PROTECTED] wrote:
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
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: 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 > >
