Re: pf rules
Doug Hardie wrote:
1. pf allows short cuts, but these also makes it more difficult to debug. I'd
separate NAT from filtering,
Ok. I guess you want some white space between them? Here it is with the white
space and comments:
ext_if=dc0
table blackhole persist file /etc/blackhole
table spamd persist
table spamd-white persist
table spamd-white-local persist file /etc/mail/whitelist
MAILHOSTS = {zool.lafn.org}
# NAT/RDR Rules
no rdr on { lo0, lo1 } from any to any
no rdr inet proto tcp from spamd-white-local to any port smtp
no rdr inet proto tcp from spamd-white to any port smtp
rdr pass log inet proto tcp from any to any port smtp - 127.0.0.1 port spamd
# Filter Rules
pass in log inet proto tcp to $MAILHOSTS port smtp keep state
pass in log on sis0 reply-to (sis0 192.168.25.1) proto tcp from any to any port
75 keep state
block in quick log on $ext_if from blackhole to any
Other than the comments I don't see the difference.
you didn't separate nat from filtering, and you didn't add interfaces on
your rdr rules. When you make these shortcuts, maybe your ruleset
becomes more compact, maybe it works, but it becomes more difficult to
debug.
that is never use rdr pass even though pf allows it. You also need to
understand when rdr takes place to write your filtering rules.
That would be really helpful if that information were available somewhere it could be found. I have not been able to find that anywhere.
Basically, for rdr, the address translation takes place before the
packet is parsed by the filter rules. For nat, it takes place after the
filtering. For binat, you can think of it as nat in one direction rdr in
the other.
This is for the first packet, keep state and you don't have to worry
about the rest.
se also,
http://www.openbsd.org/faq/pf/rdr.html
http://www.openbsd.org/faq/pf/nat.html
2. you can deploy one of two policies: Default block with a whitelist or
default pass with a black list. Mixing these is a bad idea.
This is one thing you should see to clarify in your ruleset above. When
you have both whitelist and blacklist what happens to those that are in
neither? what happens to those that are in both.
Which default policy makes sense depends on the service. You may want to
use black lists for smtp but whitelist for ssh for example.
anyway, to interpret the output of pflog, you need the output from pfctl -sr
and pfctl -sn rather than your config file.
zool# pfctl -sr
No ALTQ support in kernel
ALTQ related functions disabled
pass in log inet proto tcp from any to 206.117.18.7 port = smtp flags S/SA keep
state
pass in log on sis0 reply-to (sis0 192.168.25.1) inet proto tcp from any to any
port = 75 flags S/SA keep state
block drop in log quick on dc0 from blackhole to any
so your filter rules are numbered 0, 1, 2
zool# pfctl -sn
No ALTQ support in kernel
ALTQ related functions disabled
no rdr on lo0 all
no rdr on lo1 all
no rdr inet proto tcp from spamd-white-local to any port = smtp
no rdr inet proto tcp from spamd-white to any port = smtp
rdr pass log inet proto tcp from any to any port = smtp - 127.0.0.1 port 8025
your rdr rules are numbered 0, .. 4, but you only have log in rule 4.
So, when you see matches in your pflog, rule 0 .. 2 are filter rules and
rule 4 is rdr rule, which you can also see from the action logged, pass,
block or rdr. That seems to explain why you have no matches for rule 3.
So, to solve your problem, separate first NAT and filtering. Things becomes so
much more clear.
Repeated: Get rid of that rdr pass make an rdr rule and a pass rule.
Yes, it's the rule recommended by the spamd man page, but if you want to
see and understand what's going on, that kind of rules can really make
things obscure.
BR, Erik
--
Erik Nørgaard
Ph: +34.666334818/+34.915211157 http://www.locolomo.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf rules
Doug Hardie wrote:
This is quite interesting. I can't figure out the rules on my system.
Maybe try to simplify, clean up and structure your rules :)
Here is the pf.conf file with all comments removed:
table blackhole persist file /etc/blackhole
table spamd persist
table spamd-white persist
table spamd-white-local persist file /etc/mail/whitelist
MAILHOSTS = {zool.lafn.org}
no rdr on { lo0, lo1 } from any to any
no rdr inet proto tcp from spamd-white-local to any port smtp
no rdr inet proto tcp from spamd-white to any port smtp
rdr pass log inet proto tcp from any to any port smtp - 127.0.0.1 port spamd
pass in log inet proto tcp to $MAILHOSTS port smtp keep state
pass in log on sis0 reply-to (sis0 192.168.25.1) proto tcp from any to any port
75 keep state
block in quick log on $ext_if from blackhole to any
1. pf allows short cuts, but these also makes it more difficult to
debug. I'd separate NAT from filtering, that is never use rdr pass
even though pf allows it. You also need to understand when rdr takes
place to write your filtering rules.
2. you can deploy one of two policies: Default block with a whitelist or
default pass with a black list. Mixing these is a bad idea.
3. $ext_if = dc0?
4. rdr needs an interface, I'm surprised that pf will parse the above,
and have no idea what it does with it. pfctl -sn should show you the nat
rules.
5. Organize your rules as scetched in last mail, grouping rules for each
interface, it really helps locating where things go wrong.
I have log statements and catch all rules to ensure that if these are
triggered there is something in my ruleset I haven't taken into account.
I avoid using any except in default rules.
Note: the blackhole file is empty as is the whitelist file. There is an entry
for 216.54.240.150 in spamd database. This is a test system.
Here is the output of tcpdump where I have only taken one entry for each rule.
I have listed the rule number at the front of each line:
Rule 0: 14:01:27.133320 rule 0/0(match): pass in on dc0: 216.54.240.150.55782
206.117.18.7.25: S 2501333595:2501333595(0) win 65535 mss 1460,nop,nop,sackOK
Rule 1: 02:26:44.755650 rule 1/0(match): pass in on sis0: 71.109.144.133.40864
192.168.25.7.75: S 3941268770:3941268770(0) win 65535 mss 1460,nop,wscale
3,nop,nop,timestamp[|tcp]
Rule 2: 10:44:45.037918 rule 2/0(match): block in on dc0: 71.109.162.173.39529
206.117.18.7.75: . ack 145 win 65535 nop,nop,timestamp 705571170 1951648775
Rule 4: 13:51:16.022700 rule 4/0(match): rdr in on dc0: 216.54.240.150.49821
127.0.0.1.8025: S 2371633783:2371633783(0) win 65535 mss 1460,nop,nop,sackOK
I found no entries for rule 3. There is virtually no traffic on this system
other than from me.
As I look at pf.conf and tie the rules to the entries I get (rule number at
beginning of line):
no rdr on { lo0, lo1 } from any to any
no rdr inet proto tcp from spamd-white-local to any port smtp
0 - no rdr inet proto tcp from spamd-white to any port smtp
4 - rdr pass log inet proto tcp from any to any port smtp - 127.0.0.1 port
spamd
pass in log inet proto tcp to $MAILHOSTS port smtp keep state
1 - pass in log on sis0 reply-to (sis0 192.168.25.1) proto tcp from any to any
port 75 keep state
block in quick log on $ext_if from blackhole to any
I have no clue which one is rule 2. The only block is the last entry but that
should never be used because the blackhole file is empty. pfctl shows the
table is empty also.
The ordering seems to make no sense either. I also note that the man page for
pf.conf indicates in the BNF grammar for pf.conf that log is a valid entry for
no rdr. However, that always generates a syntax error. Apparently there is no
way to log the use of no rdr rules.
see, things seems to have been swapped around somehow, that rule 4 rdr
is really rule 0 again only now matches for the rdr action, in rule 0 it
matches pass action. or so it appears.
anyway, to interpret the output of pflog, you need the output from pfctl
-sr and pfctl -sn rather than your config file.
So, to solve your problem, separate first NAT and filtering. Things
becomes so much more clear.
Regards, Erik
--
Erik Nørgaard
Ph: +34.666334818/+34.915211157 http://www.locolomo.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf rules
On 23 January 2010, at 04:18, Erik Norgaard wrote:
Doug Hardie wrote:
This is quite interesting. I can't figure out the rules on my system.
Maybe try to simplify, clean up and structure your rules :)
Here is the pf.conf file with all comments removed:
table blackhole persist file /etc/blackhole
table spamd persist
table spamd-white persist
table spamd-white-local persist file /etc/mail/whitelist
MAILHOSTS = {zool.lafn.org}
no rdr on { lo0, lo1 } from any to any
no rdr inet proto tcp from spamd-white-local to any port smtp
no rdr inet proto tcp from spamd-white to any port smtp
rdr pass log inet proto tcp from any to any port smtp - 127.0.0.1 port spamd
pass in log inet proto tcp to $MAILHOSTS port smtp keep state
pass in log on sis0 reply-to (sis0 192.168.25.1) proto tcp from any to any
port 75 keep state
block in quick log on $ext_if from blackhole to any
1. pf allows short cuts, but these also makes it more difficult to debug. I'd
separate NAT from filtering,
Ok. I guess you want some white space between them? Here it is with the white
space and comments:
ext_if=dc0
table blackhole persist file /etc/blackhole
table spamd persist
table spamd-white persist
table spamd-white-local persist file /etc/mail/whitelist
MAILHOSTS = {zool.lafn.org}
# NAT/RDR Rules
no rdr on { lo0, lo1 } from any to any
no rdr inet proto tcp from spamd-white-local to any port smtp
no rdr inet proto tcp from spamd-white to any port smtp
rdr pass log inet proto tcp from any to any port smtp - 127.0.0.1 port spamd
# Filter Rules
pass in log inet proto tcp to $MAILHOSTS port smtp keep state
pass in log on sis0 reply-to (sis0 192.168.25.1) proto tcp from any to any port
75 keep state
block in quick log on $ext_if from blackhole to any
Other than the comments I don't see the difference.
that is never use rdr pass even though pf allows it. You also need to
understand when rdr takes place to write your filtering rules.
That would be really helpful if that information were available somewhere it
could be found. I have not been able to find that anywhere.
2. you can deploy one of two policies: Default block with a whitelist or
default pass with a black list. Mixing these is a bad idea.
3. $ext_if = dc0?
I added that back in above. Somehow it got deleted with the comments.
4. rdr needs an interface, I'm surprised that pf will parse the above, and
have no idea what it does with it. pfctl -sn should show you the nat rules.
zool# pfctl -sn
No ALTQ support in kernel
ALTQ related functions disabled
no rdr on lo0 all
no rdr on lo1 all
no rdr inet proto tcp from spamd-white-local to any port = smtp
no rdr inet proto tcp from spamd-white to any port = smtp
rdr pass log inet proto tcp from any to any port = smtp - 127.0.0.1 port 8025
It seems to understand it just fine and it works properly. See man spamd:
The following pf.conf(5) example is suggested:
table spamd-white persist
rdr pass inet proto tcp from !spamd-white to any \
port smtp - 127.0.0.1 port spamd
5. Organize your rules as scetched in last mail, grouping rules for each
interface, it really helps locating where things go wrong.
Other than the whitespace and comments they are.
I have log statements and catch all rules to ensure that if these are
triggered there is something in my ruleset I haven't taken into account. I
avoid using any except in default rules.
Note: the blackhole file is empty as is the whitelist file. There is an
entry for 216.54.240.150 in spamd database. This is a test system.
Here is the output of tcpdump where I have only taken one entry for each
rule. I have listed the rule number at the front of each line:
Rule 0: 14:01:27.133320 rule 0/0(match): pass in on dc0:
216.54.240.150.55782 206.117.18.7.25: S 2501333595:2501333595(0) win 65535
mss 1460,nop,nop,sackOK
Rule 1: 02:26:44.755650 rule 1/0(match): pass in on sis0:
71.109.144.133.40864 192.168.25.7.75: S 3941268770:3941268770(0) win 65535
mss 1460,nop,wscale 3,nop,nop,timestamp[|tcp]
Rule 2: 10:44:45.037918 rule 2/0(match): block in on dc0:
71.109.162.173.39529 206.117.18.7.75: . ack 145 win 65535
nop,nop,timestamp 705571170 1951648775
Rule 4: 13:51:16.022700 rule 4/0(match): rdr in on dc0:
216.54.240.150.49821 127.0.0.1.8025: S 2371633783:2371633783(0) win 65535
mss 1460,nop,nop,sackOK
I found no entries for rule 3. There is virtually no traffic on this system
other than from me.
As I look at pf.conf and tie the rules to the entries I get (rule number at
beginning of line):
no rdr on { lo0, lo1 } from any to any
no rdr inet proto tcp from spamd-white-local to any port smtp
0 - no rdr inet proto tcp from spamd-white to any port smtp
4 - rdr pass log inet proto tcp from any to any port smtp - 127.0.0.1 port
spamd
pass in log inet proto tcp to $MAILHOSTS port smtp keep state
1 - pass in log on sis0 reply-to (sis0 192.168.25.1) proto tcp
Re: pf rules
hi kalin,
my question is: are you telnet-ing to/from/through this machine with the
specified pf rules?
From: kalin m ka...@el.net
To: freebsd-questions@freebsd.org
Sent: Fri, January 22, 2010 8:12:00 AM
Subject: pf rules
hi all...
doing testing with pf...
how is it possible that if i have these rules below in pf.conf if i do:
telnet that.host.org 25
i get:
Trying xx.xx.xx.xx...
Connected to that.host.org.
Escape character is '^]'.
... etc ...
pf.conf contetns:
tcp_in = { www, https }
ftp_in = { ftp }
udp = { domain, ntp }
ping = echoreq
set skip on lo
scrub in
antispoof for eth0 inet
block in all
pass out all keep state
pass proto udp to any port $udp
pass inet proto icmp all icmp-type $ping keep state
pass in inet proto tcp to any port $tcp_in flags S/SAF synproxy state
pass proto tcp to any port ssh
thanks...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf rules
kalin m wrote:
tcp_in = { www, https }
ftp_in = { ftp }
udp = { domain, ntp }
ping = echoreq
set skip on lo
scrub in
antispoof for eth0 inet
block in all
pass out all keep state
pass proto udp to any port $udp
pass inet proto icmp all icmp-type $ping keep state
pass in inet proto tcp to any port $tcp_in flags S/SAF synproxy state
pass proto tcp to any port ssh
To debug pf rules:
- always add direction to the rule, pass or block, add interface to all
rules except default policy, keep state on all pass rules
- group your rules per direction, then per interface
- add log to all rules and watch pflog to see which rule blocks or
passes traffic.
- use keyword quick for any decisive rule
- check the parsing of your ruleset, pfctl -sr
then come back and ask for help.
BR, Erik
--
Erik Nørgaard
Ph: +34.666334818/+34.915211157 http://www.locolomo.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf rules
Erik Norgaard wrote:
kalin m wrote:
tcp_in = { www, https }
ftp_in = { ftp }
udp = { domain, ntp }
ping = echoreq
set skip on lo
scrub in
antispoof for eth0 inet
block in all
pass out all keep state
pass proto udp to any port $udp
pass inet proto icmp all icmp-type $ping keep state
pass in inet proto tcp to any port $tcp_in flags S/SAF synproxy state
pass proto tcp to any port ssh
To debug pf rules:
- always add direction to the rule, pass or block, add interface to all
rules except default policy, keep state on all pass rules
- group your rules per direction, then per interface
- add log to all rules and watch pflog to see which rule blocks or
passes traffic.
- use keyword quick for any decisive rule
- check the parsing of your ruleset, pfctl -sr
then come back and ask for help.
BR, Erik
See sample pf firewall rules in manual
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf rules
On 22 January 2010, at 01:45, Erik Norgaard wrote: To debug pf rules: - always add direction to the rule, pass or block, add interface to all rules except default policy, keep state on all pass rules - group your rules per direction, then per interface - add log to all rules and watch pflog to see which rule blocks or passes traffic. - use keyword quick for any decisive rule - check the parsing of your ruleset, pfctl -sr then come back and ask for help. Where do you find the rule information in the pflog output from tcpdump? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf rules
Doug Hardie wrote: On 22 January 2010, at 01:45, Erik Norgaard wrote: To debug pf rules: - always add direction to the rule, pass or block, add interface to all rules except default policy, keep state on all pass rules - group your rules per direction, then per interface - add log to all rules and watch pflog to see which rule blocks or passes traffic. - use keyword quick for any decisive rule - check the parsing of your ruleset, pfctl -sr then come back and ask for help. Where do you find the rule information in the pflog output from tcpdump? a snip: alpha# tcpdump -n -e -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 11:55:20.910140 rule 81/0(match): block in on vr1: 172.16.1.127.52444 172.16.0.1.23: tcp 44 [bad hdr length 0 - too short, 20] rule 81 blocks. Now, problem is that your rules may be more compact, you'll find the rule with pfctl -sr. Now admittedly, I got: pass in quick on vr1 inet proto udp from 172.16.0.0/23 to local_ip port = secret_service keep state ofcourse, that rule didn't block. But two lines down I found: block return in log quick on vr1 inet from 172.16.0.0/23 to local_ip This makes sence, so why the offset 2? The first line of the output from pfctl -sr is scrub all fragment reassemble that shouldn't count as a rule. And then, if pflog starts counting with 0 while vi counts from 1 that explains it. Yet another reason to check the rules as parsed using pfctl -sr. Anyway, not trying to cut corners is the first step, then add log so you can see whats going on, use quick to avoid some packet fall through and being matched by a different rule than intended, organizes your rules so you can easily separate things out. My rules are grouped together like this: # default policy block all block in log general condition pass in quick some packets keep state block in log quick general condition block out log general condition pass out quick some packets keep state block out log quick general condition # Default policy catch all should never apply block log all the conditions for the pass rules should match those of the first block and then be more specific, say, only apply to one port. Doing so, the pf rule parser will optimize the ruleset. Even if I know that a given rule can only match packets on the vr0 interface, I explicitly state the interface. It makes it clear what's going on. Once the ruleset is debugged and working you can remove the log statements. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf rules
On 1/22/10, kalin m ka...@el.net wrote:
hi all...
doing testing with pf...
how is it possible that if i have these rules below in pf.conf if i do:
telnet that.host.org 25
i get:
Trying xx.xx.xx.xx...
Connected to that.host.org.
Escape character is '^]'.
... etc ...
pf.conf contetns:
tcp_in = { www, https }
ftp_in = { ftp }
udp = { domain, ntp }
ping = echoreq
set skip on lo
scrub in
antispoof for eth0 inet
block in all
pass out all keep state
pass proto udp to any port $udp
pass inet proto icmp all icmp-type $ping keep state
pass in inet proto tcp to any port $tcp_in flags S/SAF synproxy state
pass proto tcp to any port ssh
pfctl -s info
Look for the fact it says Enabled (near the top of the screen)
and you're blocking inbound all, but since you're passing out all,
telnetting out will work. You aren't very clear on which side you
have the pf loaded on, the email indicates it's the client-side you
have pf enabled. Please clarify.
--TJ
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf rules
On Fri, Jan 22, 2010 at 8:12 AM, kalin m ka...@el.net wrote: how is it possible that if i have these rules below in pf.conf if i do: telnet that.host.org 25 i get: Trying xx.xx.xx.xx... Connected to that.host.org. Escape character is '^]'. you probably don't load pf. pfctl -sa | grep Status echo 'pf_enable=YES' etc/rc.conf /etc/rc.d/pf restart -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf rules
On 22 January 2010, at 03:14, Erik Norgaard wrote: Doug Hardie wrote: On 22 January 2010, at 01:45, Erik Norgaard wrote: To debug pf rules: - always add direction to the rule, pass or block, add interface to all rules except default policy, keep state on all pass rules - group your rules per direction, then per interface - add log to all rules and watch pflog to see which rule blocks or passes traffic. - use keyword quick for any decisive rule - check the parsing of your ruleset, pfctl -sr then come back and ask for help. Where do you find the rule information in the pflog output from tcpdump? a snip: alpha# tcpdump -n -e -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 11:55:20.910140 rule 81/0(match): block in on vr1: 172.16.1.127.52444 172.16.0.1.23: tcp 44 [bad hdr length 0 - too short, 20] rule 81 blocks. Now, problem is that your rules may be more compact, you'll find the rule with pfctl -sr. Now admittedly, I got: pass in quick on vr1 inet proto udp from 172.16.0.0/23 to local_ip port = secret_service keep state ofcourse, that rule didn't block. But two lines down I found: block return in log quick on vr1 inet from 172.16.0.0/23 to local_ip This makes sence, so why the offset 2? The first line of the output from pfctl -sr is scrub all fragment reassemble that shouldn't count as a rule. And then, if pflog starts counting with 0 while vi counts from 1 that explains it. Yet another reason to check the rules as parsed using pfctl -sr. Anyway, not trying to cut corners is the first step, then add log so you can see whats going on, use quick to avoid some packet fall through and being matched by a different rule than intended, organizes your rules so you can easily separate things out. My rules are grouped together like this: # default policy block all block in log general condition pass in quick some packets keep state block in log quick general condition block out log general condition pass out quick some packets keep state block out log quick general condition # Default policy catch all should never apply block log all the conditions for the pass rules should match those of the first block and then be more specific, say, only apply to one port. Doing so, the pf rule parser will optimize the ruleset. Even if I know that a given rule can only match packets on the vr0 interface, I explicitly state the interface. It makes it clear what's going on. Once the ruleset is debugged and working you can remove the log statements. Thanks. That is really helpful. The key is that the rule information is in the link layer. I never guessed that. Now I see it just fine. This approach sure beats monitoring the statistics and the input and trying to correlate them. That was the approach I was using. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf rules
On 22 January 2010, at 03:14, Erik Norgaard wrote:
Doug Hardie wrote:
On 22 January 2010, at 01:45, Erik Norgaard wrote:
To debug pf rules:
- always add direction to the rule, pass or block, add interface to all
rules except default policy, keep state on all pass rules
- group your rules per direction, then per interface
- add log to all rules and watch pflog to see which rule blocks or
passes traffic.
- use keyword quick for any decisive rule
- check the parsing of your ruleset, pfctl -sr
then come back and ask for help.
Where do you find the rule information in the pflog output from tcpdump?
a snip:
alpha# tcpdump -n -e -i pflog0
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96
bytes
11:55:20.910140 rule 81/0(match): block in on vr1: 172.16.1.127.52444
172.16.0.1.23: tcp 44 [bad hdr length 0 - too short, 20]
rule 81 blocks. Now, problem is that your rules may be more compact, you'll
find the rule with pfctl -sr. Now admittedly, I got:
pass in quick on vr1 inet proto udp from 172.16.0.0/23 to local_ip port =
secret_service keep state
ofcourse, that rule didn't block. But two lines down I found:
block return in log quick on vr1 inet from 172.16.0.0/23 to local_ip
This makes sence, so why the offset 2? The first line of the output from
pfctl -sr is
scrub all fragment reassemble
that shouldn't count as a rule. And then, if pflog starts counting with 0
while vi counts from 1 that explains it.
Yet another reason to check the rules as parsed using pfctl -sr.
Anyway, not trying to cut corners is the first step, then add log so you can
see whats going on, use quick to avoid some packet fall through and being
matched by a different rule than intended, organizes your rules so you can
easily separate things out.
My rules are grouped together like this:
# default policy
block all
block in log general condition
pass in quick some packets keep state
block in log quick general condition
block out log general condition
pass out quick some packets keep state
block out log quick general condition
# Default policy catch all should never apply
block log all
the conditions for the pass rules should match those of the first block and
then be more specific, say, only apply to one port. Doing so, the pf rule
parser will optimize the ruleset.
Even if I know that a given rule can only match packets on the vr0 interface,
I explicitly state the interface. It makes it clear what's going on.
Once the ruleset is debugged and working you can remove the log statements.
BR, Erik
--
This is quite interesting. I can't figure out the rules on my system. Here is
the pf.conf file with all comments removed:
table blackhole persist file /etc/blackhole
table spamd persist
table spamd-white persist
table spamd-white-local persist file /etc/mail/whitelist
MAILHOSTS = {zool.lafn.org}
no rdr on { lo0, lo1 } from any to any
no rdr inet proto tcp from spamd-white-local to any port smtp
no rdr inet proto tcp from spamd-white to any port smtp
rdr pass log inet proto tcp from any to any port smtp - 127.0.0.1 port spamd
pass in log inet proto tcp to $MAILHOSTS port smtp keep state
pass in log on sis0 reply-to (sis0 192.168.25.1) proto tcp from any to any port
75 keep state
block in quick log on $ext_if from blackhole to any
Note: the blackhole file is empty as is the whitelist file. There is an entry
for 216.54.240.150 in spamd database. This is a test system.
Here is the output of tcpdump where I have only taken one entry for each rule.
I have listed the rule number at the front of each line:
Rule 0: 14:01:27.133320 rule 0/0(match): pass in on dc0: 216.54.240.150.55782
206.117.18.7.25: S 2501333595:2501333595(0) win 65535 mss
1460,nop,nop,sackOK
Rule 1: 02:26:44.755650 rule 1/0(match): pass in on sis0: 71.109.144.133.40864
192.168.25.7.75: S 3941268770:3941268770(0) win 65535 mss 1460,nop,wscale
3,nop,nop,timestamp[|tcp]
Rule 2: 10:44:45.037918 rule 2/0(match): block in on dc0: 71.109.162.173.39529
206.117.18.7.75: . ack 145 win 65535 nop,nop,timestamp 705571170 1951648775
Rule 4: 13:51:16.022700 rule 4/0(match): rdr in on dc0: 216.54.240.150.49821
127.0.0.1.8025: S 2371633783:2371633783(0) win 65535 mss 1460,nop,nop,sackOK
I found no entries for rule 3. There is virtually no traffic on this system
other than from me.
As I look at pf.conf and tie the rules to the entries I get (rule number at
beginning of line):
no rdr on { lo0, lo1 } from any to any
no rdr inet proto tcp from spamd-white-local to any port smtp
0 - no rdr inet proto tcp from spamd-white to any port smtp
4 - rdr pass log inet proto tcp from any to any port smtp - 127.0.0.1 port
spamd
pass in log inet proto tcp to $MAILHOSTS port smtp keep state
1 - pass in log on sis0 reply-to (sis0
pf rules
hi all...
doing testing with pf...
how is it possible that if i have these rules below in pf.conf if i do:
telnet that.host.org 25
i get:
Trying xx.xx.xx.xx...
Connected to that.host.org.
Escape character is '^]'.
... etc ...
pf.conf contetns:
tcp_in = { www, https }
ftp_in = { ftp }
udp = { domain, ntp }
ping = echoreq
set skip on lo
scrub in
antispoof for eth0 inet
block in all
pass out all keep state
pass proto udp to any port $udp
pass inet proto icmp all icmp-type $ping keep state
pass in inet proto tcp to any port $tcp_in flags S/SAF synproxy state
pass proto tcp to any port ssh
thanks...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
PF rules evaluation
Hello. Is there some tool to test rules-file for PF with arbitrary packets without need for real traffic? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF rules evaluation
Michael Lednev wrote: Hello. Is there some tool to test rules-file for PF with arbitrary packets without need for real traffic? Yes. It's called netcat (nc on most systems). -- Jay Chandler / KB1JWQ Living Legend / Systems Exorcist Today's Excuse: Second-system effect ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF rules evaluation
Jay Chandler пишет: Michael Lednev wrote: Hello. Is there some tool to test rules-file for PF with arbitrary packets without need for real traffic? Yes. It's called netcat (nc on most systems). Very funny. It will create real traffic which I want to avoid. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
DHCP client and PF rules
My desktop PC get its IP address from a PPPoA modem connected with ethernet. I started logging DHCP in PF, to make sure I wasn't dropping anything, but the *only* packets I'm seeing are incoming broadcast: pass in on vr0: 10.0.0.2.67 255.255.255.255.68: BOOTP/DHCP, Reply, length: 548 I presume that the DHCP client is bypassing the firewall, but I'm wondering about these incoming broadcast packets - whether they have already been seen (and can be dropped) or not. The sessions are renewing without any specific DHCP rules. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
What is wrong with these pf rules?
binat on $dig_if from $dmz_srv to any - $dig_ip2
binat on $dsl1_if from $dmz_srv to any - $dsl1_ip2
binat on $dsl2_if from $dmz_srv to any - $dsl2_ip2
rdr on $dig_if inet proto tcp from any to $dig_ip2 port { 25, 80, 81,
110 } - $dmz_srv
rdr on $dsl1_if inet proto tcp from any to $dsl1_ip2 port { 25, 80, 110
} - $dmz_srv
rdr on $dsl2_if inet proto tcp from any to $dsl2_ip2 port { 25, 80, 110
} - $dmz_srv
$dig_if, $dsl1_if, dsl2_if are all connected to the net via routers.
The rule works for whichever interface the default route points to.
How can i get pf to return incoming connections out the same interface
they arrived on?
--
Regards
Leon
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF RULES! But mine doesn't ...
It's a question of letting DNS traffic _in_ to your nameserver:
pass in on $ext_if inet proto { tcp, udp } \
from any to ($ext_if) port 53
^^^ that lets the traffic in
pass out on $ext_if inet proto { tcp, udp } \
from ($ext_if) port 53 to any
^^^ and that lets it back out.
If you add the query-source address * port 53; to your named.conf
options section, that'll suffice; additionally, since your DNS query
source port is then predictable, you can drop it from the DNS and NTP
rule.
Hello again, Jan!
Well, I tried applying what you said now as well as last time you
said it -- but the problem is still there. Unless I uncomment the default
deny policy nothing seems to work. The problem must lie elsewhere in my
ruleset:
int_if=ep0
ext_if=lnc0
# *** Options
#
set block-policy drop
# *** Scrub incoming packets
#
scrub in all
# *** NAT
#
nat on $ext_if from $int_if:network to any - ($ext_if)
rdr on $int_if proto tcp from any to any \
port 21 - 127.0.0.1 port 8021
# *** Default deny policy
#
# block drop log all
# *** Pass loopback traffic
#
passquick on { lo0 $int_if }
# *** Outgoing
#
passout on $ext_if inet proto { tcp, udp, icmp } \
from ($ext_if) to any keep state
# *** DNS
#
passin on $ext_if inet proto { tcp, udp } \
from any to ($ext_if) port 53
passout on $ext_if inet proto { tcp, udp } \
from ($ext_if) port 53 to any
# *** NTP
#
passout on $ext_if inet proto udp \
from ($ext_if) to any port { 53, 123 } keep state
# *** SSH, HTTP and Ident
#
passin on $ext_if inet proto tcp \
from any to ($ext_if) port { 22, 80, 113 } flags S/SA keep state
# *** Active FTP
#
passin on $ext_if inet proto tcp \
from port 20 to ($ext_if) user proxy flags S/SA keep state
# *** Private FTP
#
passin on $ext_if proto tcp \
from any to any port 31337 keep state
passin on $ext_if proto tcp \
from any to any port 5:5
--
Fafa Hafiz Krantz
Research Designer @ http://www.home.no/barbershop
Enlightened @ http://www.home.no/barbershop/smart/sharon.pdf
--
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF RULES! But mine doesn't ...
Correction: Unless I COMMENT the default deny policy nothing seems to work. -- Fafa Hafiz Krantz Research Designer @ http://www.home.no/barbershop Enlightened @ http://www.home.no/barbershop/smart/sharon.pdf -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF RULES! But mine doesn't ...
It's a question of letting DNS traffic _in_ to your nameserver:
pass in on $ext_if inet proto { tcp, udp } \
from any to ($ext_if) port 53
^^^ that lets the traffic in
pass out on $ext_if inet proto { tcp, udp } \
from ($ext_if) port 53 to any
^^^ and that lets it back out.
Ok, after having added that it seems that my DNS works.
The same goes for my WWW and mail server.
SSH servers are all OK to connect to.
I have to wait like 5 minutes after booting my computer
before I can connect to those certain FTP sites. What's
that all about?
If you add the query-source address * port 53; to your named.conf
options section, that'll suffice; additionally, since your DNS query
source port is then predictable, you can drop it from the DNS and NTP
rule.
What do you mean by that?
Anyway, it's pretty close to perfection now :)
Jan, any idea how I can simplify my ruleset?
Also, I'm wondering if I can move the NAT part down below the Outgoing
so I can combine it with the Active FTP ruleset so they don't have to be
spread troughout the conf. Thanks!
--
Fafa Hafiz Krantz
Research Designer @ http://www.home.no/barbershop
Enlightened @ http://www.home.no/barbershop/smart/sharon.pdf
--
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF RULES! But mine doesn't ...
On Tue, 10 May 2005, Fafa Hafiz Krantz wrote:
Ok, after having added that it seems that my DNS works.
The same goes for my WWW and mail server.
SSH servers are all OK to connect to.
I have to wait like 5 minutes after booting my computer
before I can connect to those certain FTP sites. What's
that all about?
If you add the query-source address * port 53; to your named.conf
options section, that'll suffice; additionally, since your DNS query
source port is then predictable, you can drop it from the DNS and NTP
rule.
What do you mean by that?
The rules I suggested are so that external machines can talk to your DNS
server (querying about the domain it is authoritative for), and so that
responses can get back to those machines.
Your nameserver, however, may also be trying to get requests out. When
it does this, by default, it will use a random source-port. By
specifying
options {
query-source address * port 53;
}
in your named.conf, your nameserver will _also_ use port 53 as the
source port on any requests _that it originates_. (That's the
distinction). If you do this, then you won't need port 53 mentioned in
your other keep state rule.
I suspect that this might actually be the cause of your transient FTP
concern; you should try modifying your nameserver config before you go
any further.
(This assumes that your resolv.conf is configured to use the local
machine as a nameserver in the first instance. If that is not the case,
then you will still need the port 53 clause in your DNS and NTP
section, because other programs will use random ports in an attempt to
get DNS queries out into the wild.)
Anyway, it's pretty close to perfection now :)
Jan, any idea how I can simplify my ruleset?
Also, I'm wondering if I can move the NAT part down below the Outgoing
so I can combine it with the Active FTP ruleset so they don't have to be
spread troughout the conf. Thanks!
Your ruleset looks pretty simple, to be honest.
I'm afraid that where the specifics of PF are concerned, I know nothing:
the advice I've given you is just generic firewall stuff :-/ It looks to
me like your PF config is set up to use some kind of FTP proxy running
on localhost:8021. On the other hand, I could be barking up the wrong
tree completely; I've pretty much run out of useful things to say about
this config.
Cheers,
jan
--
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44 (0)117 9287088 (with luck) http://ioctl.org/jan/
Prolog in JavaScript: http://ioctl.org/logic/prolog-latest
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF RULES! But mine doesn't ...
On 2005-05-10 05:09, Fafa Hafiz Krantz [EMAIL PROTECTED] wrote:
It's a question of letting DNS traffic _in_ to your nameserver:
pass in on $ext_if inet proto { tcp, udp } \
from any to ($ext_if) port 53
^^^ that lets the traffic in
pass out on $ext_if inet proto { tcp, udp } \
from ($ext_if) port 53 to any
^^^ and that lets it back out.
If you add the query-source address * port 53; to your named.conf
options section, that'll suffice; additionally, since your DNS
query source port is then predictable, you can drop it from the DNS
and NTP rule.
Hello again, Jan!
Well, I tried applying what you said now as well as last time you
said it -- but the problem is still there. Unless I uncomment the default
deny policy nothing seems to work. The problem must lie elsewhere in my
ruleset:
Show us the output of:
# pfctl -sr
[snip ruleset]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF RULES! But mine doesn't ...
- Original Message -
From: Giorgos Keramidas [EMAIL PROTECTED]
To: Fafa Hafiz Krantz [EMAIL PROTECTED], Jan Grant [EMAIL PROTECTED]
Subject: Re: PF RULES! But mine doesn't ...
Date: Tue, 10 May 2005 13:50:27 +0300
On 2005-05-10 05:09, Fafa Hafiz Krantz [EMAIL PROTECTED] wrote:
It's a question of letting DNS traffic _in_ to your nameserver:
pass in on $ext_if inet proto { tcp, udp } \
from any to ($ext_if) port 53
^^^ that lets the traffic in
pass out on $ext_if inet proto { tcp, udp } \
from ($ext_if) port 53 to any
^^^ and that lets it back out.
If you add the query-source address * port 53; to your named.conf
options section, that'll suffice; additionally, since your DNS
query source port is then predictable, you can drop it from the DNS
and NTP rule.
Hello again, Jan!
Well, I tried applying what you said now as well as last time you
said it -- but the problem is still there. Unless I uncomment the default
deny policy nothing seems to work. The problem must lie elsewhere in my
ruleset:
Show us the output of:
# pfctl -sr
[snip ruleset]
Hello!
# pfctl -sr
No ALTQ support in kernel
ALTQ related functions disabled
scrub in all fragment reassemble
block drop log all
pass quick on lo0 all
pass quick on ep0 all
pass out on lnc0 inet proto tcp from (lnc0) to any keep state
pass out on lnc0 inet proto udp from (lnc0) to any keep state
pass out on lnc0 inet proto icmp from (lnc0) to any keep state
pass in on lnc0 inet proto tcp from any to (lnc0) port = domain
pass in on lnc0 inet proto udp from any to (lnc0) port = domain
pass out on lnc0 inet proto tcp from (lnc0) port = domain to any
pass out on lnc0 inet proto udp from (lnc0) port = domain to any
pass out on lnc0 inet proto udp from (lnc0) to any port = domain keep state
pass out on lnc0 inet proto udp from (lnc0) to any port = ntp keep state
pass in on lnc0 inet proto tcp from any to (lnc0) port = ssh flags S/SA keep
state
pass in on lnc0 inet proto tcp from any to (lnc0) port = http flags S/SA keep
state
pass in on lnc0 inet proto tcp from any to (lnc0) port = auth flags S/SA keep
state
pass in on lnc0 inet proto tcp from any port = ftp-data to (lnc0) user = 62
flags S/SA keep state
pass in on lnc0 proto tcp from any to any port = 31337 keep state
pass in on lnc0 proto tcp from any to any port 5:5
About the ALTQ thing, it should be in the kernel.
I just recompiled it with:
# *** Internet family options
#
device pf # OpenBSD PF firewall
device pflog # Logging support interface
device altq# Alternate queuing
device gif # IPv6 and IPv4 tunneling
device faith # IPv6-to-IPv4 translation
device bpf # Berkeley Packet Filter
Thanks!
--
Fafa Hafiz Krantz
Research Designer @ http://www.home.no/barbershop
Enlightened @ http://www.home.no/barbershop/smart/sharon.pdf
--
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF RULES! But mine doesn't ...
The rules I suggested are so that external machines can talk to your DNS
server (querying about the domain it is authoritative for), and so that
responses can get back to those machines.
Your nameserver, however, may also be trying to get requests out. When
it does this, by default, it will use a random source-port. By
specifying
options {
query-source address * port 53;
}
in your named.conf, your nameserver will _also_ use port 53 as the
source port on any requests _that it originates_. (That's the
distinction). If you do this, then you won't need port 53 mentioned in
your other keep state rule.
I suspect that this might actually be the cause of your transient FTP
concern; you should try modifying your nameserver config before you go
any further.
Great :) Thanks man, I'll try that.
Isn't this something that ought to be in every named.conf?
What ports do it go to by default?
(This assumes that your resolv.conf is configured to use the local
machine as a nameserver in the first instance. If that is not the case,
then you will still need the port 53 clause in your DNS and NTP
section, because other programs will use random ports in an attempt to
get DNS queries out into the wild.)
No, my resolv.conf contains my ISP's nameservers.
Your ruleset looks pretty simple, to be honest.
I've heard many experts say 'your ruleset looks like shit',
maybe because they're jealous of my nice headers ;)
Ok, so now my named.conf's option looks like this:
options {
directory /etc/namedb;
pid-file /var/run/named/pid;
query-source address * port 53;
};
Should I specify where to log to?
Because it doesn't log.
I'm afraid that where the specifics of PF are concerned, I know nothing:
the advice I've given you is just generic firewall stuff :-/ It looks to
me like your PF config is set up to use some kind of FTP proxy running
on localhost:8021. On the other hand, I could be barking up the wrong
tree completely; I've pretty much run out of useful things to say about
this config.
Well you do seem to me like a jack of all trades.
Have a wonderful day! :)
--
Fafa Hafiz Krantz
Research Designer @ http://www.home.no/barbershop
Enlightened @ http://www.home.no/barbershop/smart/sharon.pdf
--
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF RULES! But mine doesn't ...
On 2005-05-10 07:19, Fafa Hafiz Krantz [EMAIL PROTECTED] wrote: Giorgos Keramidas [EMAIL PROTECTED] wrote: Show us the output of: # pfctl -sr [snip ruleset] Hello! # pfctl -sr scrub in all fragment reassemble block drop log all pass quick on lo0 all pass quick on ep0 all Good so far. pass out on lnc0 inet proto tcp from (lnc0) to any keep state pass out on lnc0 inet proto udp from (lnc0) to any keep state pass out on lnc0 inet proto icmp from (lnc0) to any keep state pass in on lnc0 inet proto tcp from any to (lnc0) port = domain pass in on lnc0 inet proto udp from any to (lnc0) port = domain pass out on lnc0 inet proto tcp from (lnc0) port = domain to any pass out on lnc0 inet proto udp from (lnc0) port = domain to any pass out on lnc0 inet proto udp from (lnc0) to any port = domain keep state pass out on lnc0 inet proto udp from (lnc0) to any port = ntp keep state pass in on lnc0 inet proto tcp from any to (lnc0) port = ssh flags S/SA keep state pass in on lnc0 inet proto tcp from any to (lnc0) port = http flags S/SA keep state pass in on lnc0 inet proto tcp from any to (lnc0) port = auth flags S/SA keep state pass in on lnc0 inet proto tcp from any port = ftp-data to (lnc0) user = 62 flags S/SA keep state pass in on lnc0 proto tcp from any to any port = 31337 keep state pass in on lnc0 proto tcp from any to any port 5:5 There are at least two problems with the above rules: 1. You are using (lnc0) on all the rules below. 2. There are no address mapping rules (nar or binat). The reason why (1) may cause problems is that they assume that all packets that come *in* on the lc0 interface have as their source or destination address one of the IP addresses of that interface. This may not be true if you have packet forwarding enabled. Especially when NAT is not enabled; which is not, in your ruleset. Even if NAT _is_ enabled, I think that packets that come in on ep0 will still have the same source address as they go in lnc0 and will only change their source address en route through lnc0, as the NAT rules are applied. Pay very close attention to the following example from the pf.conf manpage itself. It may help a bit to explain what I said above: In the example below, the machine sits between a fake internal 144.19.74.* network, and a routable external IP of 204.92.77.100. The no nat rule excludes protocol AH from being translated. # NO NAT no nat on $ext_if proto ah from 144.19.74.0/24 to any nat on $ext_if from 144.19.74.0/24 to any - 204.92.77.100 Both number (1) and (2) are not problems if you have public, routable IP addresses on all the hosts visible through the ep0 interface. The fact that you do have a problem suggests that the IP addresses of the ep0 interface (not visible above) are all parts of unroutable, private address blocks. Another problem that is easily noticed is that you have lots of redundant rules that serve only as a waste of CPU cycles. For instance, these sets of rules will match a common set of IP packets. You may find it useful to note that the *first* rule of each group matches a superset of the packets that the rest match, so you can keep just the first rule of each group for exactly the same effect! pass out on lnc0 inet proto tcp from (lnc0) to any keep state pass out on lnc0 inet proto tcp from (lnc0) port = domain to any pass out on lnc0 inet proto udp from (lnc0) to any keep state pass out on lnc0 inet proto udp from (lnc0) port = domain to any pass out on lnc0 inet proto udp from (lnc0) to any port = domain keep state - Giorgos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
PF RULES! But mine doesn't ...
Hello.
My ruleset is all twisted.
Unless I disable the default deny policy, this is what happens:
* My nameserver setup goes disfunctional.
* My web, mail and fileserver goes disfunctional.
* I cannot SSH and FTP into certain servers.
* I cannot ping my IP from the outside.
Can anyone tell what's wrong?
And maybe also how I can simplify my ruleset?
int_if=ep0
ext_if=lnc0
# *** Options
#
set block-policy drop
# *** Scrub incoming packets
#
scrub in all
# *** NAT
#
nat on $ext_if from $int_if:network to any - ($ext_if)
rdr on $int_if proto tcp from any to any \
port 21 - 127.0.0.1 port 8021
# *** Default deny policy
#
# block drop log all
# *** Pass loopback traffic
#
passquick on { lo0 $int_if }
# *** Outgoing
#
passout on $ext_if inet proto { tcp, udp, icmp } \
from ($ext_if) to any keep state
# *** Bootstrap
#
passout on $ext_if inet proto udp \
from any port 68 to any port 67 keep state
# *** DNS and NTP
#
passout on $ext_if inet proto udp \
from ($ext_if) to any port { 53, 123 } keep state
# *** SSH, HTTP and Ident
#
passin on $ext_if inet proto tcp \
from any to ($ext_if) port { 22, 80, 113 } flags S/SA keep state
# *** Active FTP
#
passin on $ext_if inet proto tcp \
from port 20 to ($ext_if) user proxy flags S/SA keep state
Thank you so much.
Keep in touch!
--
Fafa Hafiz Krantz
Research Designer @ http://www.bleed.no
--
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF RULES! But mine doesn't ...
On Sun, 8 May 2005, Fafa Hafiz Krantz wrote:
Hello.
My ruleset is all twisted.
Unless I disable the default deny policy, this is what happens:
* My nameserver setup goes disfunctional.
* My web, mail and fileserver goes disfunctional.
* I cannot SSH and FTP into certain servers.
* I cannot ping my IP from the outside.
Can anyone tell what's wrong?
And maybe also how I can simplify my ruleset?
It's a question of letting DNS traffic _in_ to your nameserver:
int_if=ep0
ext_if=lnc0
# *** Options
#
set block-policy drop
# *** Scrub incoming packets
#
scrub in all
# *** NAT
#
nat on $ext_if from $int_if:network to any - ($ext_if)
rdr on $int_if proto tcp from any to any \
port 21 - 127.0.0.1 port 8021
# *** Default deny policy
#
# block drop log all
# *** Pass loopback traffic
#
passquick on { lo0 $int_if }
# *** Outgoing
#
passout on $ext_if inet proto { tcp, udp, icmp } \
from ($ext_if) to any keep state
# *** Bootstrap
#
passout on $ext_if inet proto udp \
from any port 68 to any port 67 keep state
# *** DNS and NTP
#
passout on $ext_if inet proto udp \
from ($ext_if) to any port { 53, 123 } keep state
# *** SSH, HTTP and Ident
#
passin on $ext_if inet proto tcp \
from any to ($ext_if) port { 22, 80, 113 } flags S/SA keep state
pass in on $ext_if inet proto { tcp, udp } \
from any to ($ext_if) port 53
^^^ that lets the traffic in
pass out on $ext_if inet proto { tcp, udp } \
from ($ext_if) port 53 to any
^^^ and that lets it back out.
If you add the query-source address * port 53; to your named.conf
options section, that'll suffice; additionally, since your DNS query
source port is then predictable, you can drop it from the DNS and NTP
rule.
# *** Active FTP
#
passin on $ext_if inet proto tcp \
from port 20 to ($ext_if) user proxy flags S/SA keep state
--
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44 (0)117 9287088 (with luck) http://ioctl.org/jan/
Usenet: The separation of content AND presentation - simultaneously.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF RULES! But mine doesn't ...
Fafa Hafiz Krantz wrote:
Hello.
My ruleset is all twisted.
Unless I disable the default deny policy, this is what happens:
* My nameserver setup goes disfunctional.
* My web, mail and fileserver goes disfunctional.
* I cannot SSH and FTP into certain servers.
* I cannot ping my IP from the outside.
Can anyone tell what's wrong?
And maybe also how I can simplify my ruleset?
int_if=ep0
ext_if=lnc0
# *** Options
#
set block-policy drop
# *** Scrub incoming packets
#
scrub in all
# *** NAT
#
nat on $ext_if from $int_if:network to any - ($ext_if)
rdr on $int_if proto tcp from any to any \
port 21 - 127.0.0.1 port 8021
# *** Default deny policy
#
# block drop log all
# *** Pass loopback traffic
#
passquick on { lo0 $int_if }
# *** Outgoing
#
passout on $ext_if inet proto { tcp, udp, icmp } \
from ($ext_if) to any keep state
# *** Bootstrap
#
passout on $ext_if inet proto udp \
from any port 68 to any port 67 keep state
# *** DNS and NTP
#
passout on $ext_if inet proto udp \
from ($ext_if) to any port { 53, 123 } keep state
# *** SSH, HTTP and Ident
#
passin on $ext_if inet proto tcp \
from any to ($ext_if) port { 22, 80, 113 } flags S/SA keep state
# *** Active FTP
#
passin on $ext_if inet proto tcp \
from port 20 to ($ext_if) user proxy flags S/SA keep state
Thank you so much.
Keep in touch!
--
Fafa Hafiz Krantz
Research Designer @ http://www.bleed.no
Perhaps you should check the archives. :)
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF RULES! But mine doesn't ...
Fafa Hafiz Krantz wrote: Perhaps you should check the archives. :) What do you mean? There are many archives out there ... Please tell me which one? Thanks! -- Fafa Hafiz Krantz Research Designer @ http://www.home.no/barbershop Enlightened @ http://www.home.no/barbershop/smart/sharon.pdf Did you happen to notice the smile [ :) ] at the end of my post. That was my weak attempt at humor. Some actually found it humorous. Perhaps you need to lighten up and work on your sense of humor. It would go a long way on this list and elsewhere in this world. On that note, I think the entire world and especially the politicians need to lighten up and try to have some fun. If we can not laugh at ourselves then we have no right to laugh at all. Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
