A PF lecture/tutorial - work in progress
Hi, I've completed an English version of my PF lecture manuscript (with slight updates) originally written for a 1 1/2-2 hour session at BLUG. The material is available in various formats, English: http://www.bgnett.no/~peter/pf/en/pf-firewall.pdf (full manuscript, pdf) http://www.bgnett.no/~peter/pf/en/ (full manuscript, html) http://www.bgnett.no/~peter/pf/en/foils/ (foils, html) Norwegian: http://www.bgnett.no/~peter/pf/no/pf-brannmur.pdf (full manuscript, pdf) http://www.bgnett.no/~peter/pf/no/ (full manuscript, html) http://www.bgnett.no/~peter/pf/no/foils/ (foils, html) At this point I'm not confident it's publishing quality, but I'd love to hear comments of any kind. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Bastion host
Martin Randall <[EMAIL PROTECTED]> writes: > 2) Allow inbound ssh from anywhere Than you need to change this bit pass in quick on $ext_if inet proto tcp \ from ($ext_if) \ to ($ext_if) port 22 \ flags S/SA synproxy state - which says only packets with a source address equal to your external interface's possibly dynamic IP address is to pass - to something more like pass in quick on $ext_if inet proto tcp \ from any \ to ($ext_if) port 22 \ flags S/SA synproxy state -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: OBSD Bridge Help
This looks like a rather complicated setup, so I think it would be useful to ask, what did the last working setup look like? A couple of things which strike me as odd are - the RFC1918 table looks to me like it includes rather more than the rfc1918 addresses the bad tcp flags section contains quite a number of permutations which may or may not be tripping you up, others which may be redundant you have a quick rule which I think would block traffic from the internal network to the world (block out log quick on $ext_if from ! $ext_if to any) My advice would be to roll back to the last version which was able to pass at least some traffic, then introduce rules one at a time from there, testing each change. That way you will be in a much better position to see what breaks, if it does. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Sample ruleset for dividing LANs
Steven Bowers <[EMAIL PROTECTED]> writes:
> I've been running a small LAN for some time with just two nics, one
> for the external DSL router and the other to my personal LAN. Recently
> I moved to a nicer apartment complex and would like to share my DSL to
> some of the residents. I've added a third nic and attached a Linksys
> WRT54G to it. Before I open it up to the complex I was trying to setup
> a ruleset that restricted traffic on that network from my own. Could
> someone give me a brief outline of how to keep the residents on the
> network I've setup for them?
>
> My LAN runs on 192.168.1.0/16 and I'm planning to put them on 192.168.21.0/16
This is probably a situation where block all, then specifying pass rules
specific to the interfaces makes for the most readable rule set.
Something along the lines of
mylan = "192.168.1.0/16"
otherlan "192.168.21.0/16"
my_if = defineme0
other_if = defineme1
ext_if = defineme2
scrub in all
block all
## do your nat
nat on $ext_if from { $mylan, $otherlan } to any -> ($ext_if)
## other rdr as needed
pass in on my_if from $mylan to any
pass out on ext_if from $mylan to any keep state
pass in on other_if from $otherlan to any
pass out on ext_if from $otherlan to any keep state
- with the addition of some restriction on which ports and a few other
embellishments - could be what you need.
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Still no answer on my bridge question -- resolved
Russell Fulton <[EMAIL PROTECTED]> writes: > Yet another illustration of the rule that one should post config files > when asking questions. simply exposing your rule set to a fresh set of eyes sometimes has wonderful problem solving capability. seriously, the real risk of embarrasment along the lines of "now what on g*d's green earth are you doing that for?" is a lot less than you think. Posting your config along with your problem description is always good. Obfuscate if you have to. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Insufficient benzed.... err caffiene
"Rod.. Whitworth" <[EMAIL PROTECTED]> writes: > On the target /var/log/messages says: > Apr 8 19:46:20 puffy -authpf: cannot open packet filter device > (Permission denied) Strange. Could it be your kernel and userland are out of sync? -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Pfctl for non-root users
Jason Dixon <[EMAIL PROTECTED]> writes: > Is the ability to run pfctl (via sudo) as a non-root user still > broken? I've tested this on a 3.6 -release system, and /dev/pf is > still unavailable for non-root users. [EMAIL PROTECTED]:~$ ls -l /dev/pf crw--- 1 root wheel 73, 0 Oct 19 00:02 /dev/pf It certainly looks like being a member of wheel is a distinct advantage, at least. What kinds of operations did you have in mind? Would eg a sensible authpf setup help achieve what you want to do? -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Pfctl for non-root users
Jason Dixon <[EMAIL PROTECTED]> writes: > # su - hatchet > $ pfctl -vsr > pfctl: /dev/pf: Permission denied > $ whoami > hatchet > $ groups > hatchet wheel You asked about running pfctl via sudo, but there's no trace of sudo here. I would think a reasonable sudo config is what you want. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Pfctl for non-root users
Ian <[EMAIL PROTECTED]> writes: > just an observation, but the /dev/pf is user root, group wheel, with > no explicit permissions set on the group there, only rw for the user, > root. Yes, so I noticed a few moments after posting (there are apparently situations where coffee has no measurable effect). So being a wheel member doesn't really matter in this case. A correct sudoers file is probably all that's needed for the OP, the exact contents would of course be up to whatever is appropriate at the site. That, and actually using sudo instead of su - ;) -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Feature request - setting TOS
Kimi Ostro <[EMAIL PROTECTED]> writes: > I would not usually ask for a feature. Anyway, the proposal would be > that you could set the TOS on TCP/UDP packets like so: Sounds somewhat like you could achieve at least some of the same effect via altq, with a set of queues and priorities. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Feature request - setting TOS
Kevin <[EMAIL PROTECTED]> writes: > I believe the idea here is to set TOS bits on the packets as they pass > through the OpenBSD gateway, so *other* routers in the path can act > accordingly, using their own queues and priorities. The two are not necessarily mutually exclusive. I tend to put a bit more faith in the things I can control, on my own gear. Setting TOS values is useful, but only to the extent they are actually honored further down the track. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Firewalling with PF manuscript updated, BSD-licensed
I have put an updated version of the Firewalling with PF manuscript up at http://www.bgnett.no/~peter/pf/ with links to the various versions (btw the old links will still work). This is roughly what I'll be presenting in Oslo tonight. Highlights: * Various minor corrections including typos * Added network hygiene section - scrub, block-policy, antispoof * Added NetBSD info * Doc available as single html file * License is now BSD It's still a work in progress which I will keep maintaining and possibly expand as time goes by. Thanks are due to everyone who sent me comments and suggestions, and to the excellent PF developers, OpenBSD and elsewhere. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: tunneling over HTTPS
alex wilkinson <[EMAIL PROTECTED]> writes: > Is it possible to detect users tunneling out over HTTPS i.e through a > firewall. > e.g. users using something like corkscrew ssh over a HTTPS tunnel. Possible? Yes, with some qualification. Available out of the box with default PF config? No. You could for example set up a pf rule to redirect https traffic to a content analyzer of your choice, with smart pattern matching software which runs on something with lots and lots of processing power, before letting the traffic pass on to wherever it was going in the first place. The effort involved would be non-trivial to say the least. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: tunneling over HTTPS
alex wilkinson <[EMAIL PROTECTED]> writes: > Is it possible to disguise this behaviour ? From a client perspective. Assuming you have the near-infinite processing resources it would take to make the decrypting and pattern recognition happen without noticeable delay, sure. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: tunneling over HTTPS
Lars Hansson <[EMAIL PROTECTED]> writes: > I dont think that's possible with *ANY* software or hardware > solution, at least not one that is readily available and > wont cost you your first-born child. I considered inserting "your name is The Department of Homeland Security, the National Security Agency or the Central Intelligence Agency" on the list of prerequisites, but thought I'd better not, since that might trigger all sorts of stupidity. oh bummer. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Dude about route-to
"Pasky.Org" <[EMAIL PROTECTED]> writes:
> So i want that general traffic (inbound and outgoing) use the ext_if1
> asymmetrical, and only the smtp traffic, defined by an address and port rule,
> must use the ext_if2 symmetrical.
One possible approach would be to altq on both interfaces, directing
smtp traffic to the queue on ext_if2 only, something along the lines of
altq on $ext_if1 priq bandwidth $if1_bw queue { q_all, q_def1 }
queue q_pri priority 7
queue q_def1 priority 1 priq(default)
altq on $ext_if2 priq bandwidth $if2_bw queue { q_smtp, q_def2 }
queue q_smtp priority 7
queue q_def2 priority 1 priq(default)
pass on $ext_if1 proto tcp to any port $allowedports flags S/SA keep state
queue (q_all, q_def1)
pass on $ext_if2 proto tcp to $mail_address port smtp flags S/SA keep state
queue (q_smtp, q_def2)
untested, bound to contain at least one fatal error, but you get the idea.
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Need help in per user basis bandwidth sharing
Porkodi <[EMAIL PROTECTED]> writes: > Please help me in per user basis bandwidth sharing. > Is there any way in pf with altq? authpf with per user rules which assign the user's traffic to queues should be possible. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: limitation of PF while forwarding ports --help
Siju George <[EMAIL PROTECTED]> writes: > Is PF not capable of letting two users ( with two > differrent computers with 2 differrent IP from the RFC1918 range ) in > the LAN to connect to the Same Windows 2003 remote > desktop server on the Internet and work on it simultaneously??? > > The only workaround to connect to Windows Remote Desktop Server > through PF I know of now is to > use an rdr rule to do port forwarding something like. > > code: > rdr pass on $ext_if inet proto tcp from $Windows_RDServer to any port > 3389 -> $WRD_client1 port 3389 I may be revealing the true abysses of my ignorance here, but would not a reasonable NAT combined with something like pass inet proto tcp from $localnet to $Windows_RDServer port 3389 keep state 'just work'? Does the server need to start connections which are not taken care of by the state information back to the clients? -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: How-to block all adresses except a few
Håkan Kvist <[EMAIL PROTECTED]> writes:
> I want to only let certain ip-ranges to have SSH-access.
So far so good.
> So I typed in the following rule:
>
> pass in quick on $ext proto tcp from { xx.xx.xx.xx/xx , xx.xx.xx.xx/xx \
> xx.xx.xx.xx/xx , ... } to xx.xx.xx.xx/xx port 22 keep state
Meaning, some ranges get to connect on port 22.
> And that works fine, however incoming connections dosn't get blocked, i.e
> ssh hangs for a while when trying to connect.
You mean other connections from the ones not in your rule get through?
Well, to properly diagnose, we need the rest of your rule set. The quick
rule means the rest of the rules are never evaluated if a connection
matches. If you have other rules after this allowing others in (or for
that matter a too permissive pass rule before it), you could be letting
others connect.
> nmap also says the port is in state filtered.
I don't see why not. Have you tried using nmap from an address in your
pass rule?
> Can I get pf to report the port as closed instead or would that be unwise?
nmap and pf are separate things. I assume a scan from somewhere blocked
will show it as closed.
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: natting static IP's
David Hill <[EMAIL PROTECTED]> writes:
> nat on sis0 inet from ! sis0:0 to any -> (sis0)
This sounds a bit too inclusive for my tastes. I assume the address
range your DHCP deamon uses is known as well as the fixed addreses, so
why not use those instead, ie
myranges = { 192.168.100.0/24, 192.168.101.0/24 }
nat on $ext_if from $myranges to any -> ($ext_if)
just my NOK 0.02
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: single box Newbie ques
[EMAIL PROTECTED] (Gene) writes: > I have installed Obsd 3.5 on my 2nd hd and configured ppp but I > am unable to find any pf conf examples which deal with only one > computer. (no network card) Is there a macro name to use that does > not point to a nic? I suppose what you are saying is, "which interface, if any, should I filter on for PPP?". The answer is then "tun0" unless I'm very mistaken. Then again, you may not need to reference the interface name at all in a single computer setup. It's possible you would find my PF tutorial at http://www.bgnett.no/~peter/pf/ useful. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Kinds of Attacks
arun kumarn <[EMAIL PROTECTED]> writes: > I want to know which are the type of attacks that are taken care in > current version of OpenBSD Pf. I would think that the answer to this depends crucially on the contents of your configuration. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: pf versions
ed <[EMAIL PROTECTED]> writes: > On an openbsd 3.7 install the following rule will work yet not on a 3.6, > is there a difference in the way the rule should be declared, or if pf > can be upgraded, how should I do this? Your rule uses features which were introduced in 3.7. Your best bet is to upgrade to 3.7. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Internal SSH connection refused when Ext_if dies
"hillbilly1980" <[EMAIL PROTECTED]> writes: > I have a cable connection which i have hardcoded my dhclient ip and > gateway to the ext_if. However when my provider sometimes will reassign > my ip to someone else and will refuse to route my traffic when this > happens. It's fairly easy to construct a NAT setup to compensate for dynamic, and possibly changing, IP addresses on your external interface: nat on $ext_if from $int_if:network to any -> ($ext_if) then add options and flags as needed. The () notation should help. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: filtering logmein with pf
Siju George <[EMAIL PROTECTED]> writes: > https://secure.logmein.com/ > > How do I prevent usage of such software with PF while permitting http > access from the LAN at the same time through PF to the Internet??? As far as I can dechipher the marketbabble on the "how it works" pages, it looks like the system is based on clients "calling home" via https, and "home" then uses the connection just established to keep in touch. I think it's https you need to worry about. You could try limiting allowed https contact to a list of known good hosts (do remember to include your boss' online bank in the list). -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: What do you think about PF filtering for encapsulated protocols (e.g pppoe) ?
mzozd <[EMAIL PROTECTED]> writes: > we were thinking of patching PF to filter on encapsulated traffic (pppoe > in particular). I may be missing something important (extremely low caffeine levels at the moment), but filtering pppoe on the TCP/IP level is already quite doable without patching. You simply filter on the tun interface (usually tun0, but of course you may have more than one). For bridging, look into the brconfig and bridgename.if manpages - the bridge plus pf combination is quite flexible. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Firewalling with PF, AUUG2005 edition
I've updated the Firewalling with PF manuscript, mainly for the tutorial I gave at the AUUG2005 conference. So far only the English version with slides is available. I will get the Norwegian updated as soon as possible, but presumably not until next week or so. Comments welcome as always. And yes, it's still BSD licensed. Highlights: New sections: Info on bruteforce protection Wireless net setup authpf with wireless net updates to the spamd section updates to traceroute section The updated versions are up at http://www.bgnett.no/~peter/pf/en/ - full text, html, English http://www.bgnett.no/~peter/pf/en/long-firewall.html - full text, one html file, English http://www.bgnett.no/~peter/pf/en/pf-firewall.pdf - full text, pdf, English http://www.bgnett.no/~peter/pf/en/foils/ -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Is a 'PF default to block' setting outside pf.conf a desirable feature?
Over in the comp.unix.bsd.freebsd.misc news group, there's a discussion about what happens when PF loads, specifically a perceived 'window of opportunity' for an attacker in the interval between PF getting enabled and the rule set loading, and what happens if the rule set you load at boot time is an empty or invalid rule set. On FreeBSD, it is possible to compile your kernel with options to make 'block all' the default in absence of a rule set. This apparently works for all the other firewall systems supported by FreeBSD, but not PF. You should not be surprised to learn that there are people who feel that this feature, described as 'booting to a safe state regardless of failure or success of ruleset load' is a necessary feature of 'any firewall worthy of the name'. I'm trying to make up my mind whether some way to set PF to 'block all' default outside of the rule set itself is a desirable feature. For a bit of context, the thread in question starts at <[EMAIL PROTECTED]> -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Is a 'PF default to block' setting outside pf.conf a desirable feature?
Jon Hart <[EMAIL PROTECTED]> writes: > Unless I'm being completely mislead, this feature is already in place > with OpenBSD. See /etc/rc. Now that you mention it, it does look like the good people who ported PF over to FreeBSD did not bring with them all of the PF related bits from OpenBSD's /etc/rc. The minimal default rule set AFAICS is the smart solution to the problem. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Is a 'PF default to block' setting outside pf.conf a desirable feature?
Damien Miller <[EMAIL PROTECTED]> writes: > Why is setting a "block all" before any interfaces are configured up > not sufficient? The original poster's problem is that it looks like the rc scripts on FreeBSD do not include the PF initialization code which does that. Probably not terribly hard to fix if you know your way around rcNG. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Is a 'PF default to block' setting outside pf.conf a desirable feature?
Damien Miller <[EMAIL PROTECTED]> writes: > And the important thing to note is that this ruleset is applied before > any interfaces are activated. No active interfaces == no packets > making it to the kernel. Yes, my point exactly. I probably did not write it that well, since OP went off complaining, though. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: pf security - is pf failsafe if config file invalid?
"Travis H." <[EMAIL PROTECTED]> writes:
> Lots of things in the startup scripts will fail to work or hang
> indefinitely if you block outbound stuff. I find it necessary to
> allow at least outbound DNS in order for the machine to boot in
> reasonable time.
The OpenBSD /etc/rc has this code to initialize PF before any interfaces
are up:
if [ "X${pf}" != X"NO" ]; then
RULES="block all"
RULES="$RULES\npass on lo0"
RULES="$RULES\npass in proto tcp from any to any port 22 keep state"
RULES="$RULES\npass out proto { tcp, udp } from any to any port 53 keep
state"
RULES="$RULES\npass out inet proto icmp all icmp-type echoreq keep
state"
if ifconfig lo0 inet6 >/dev/null 2>&1; then
RULES="$RULES\npass out inet6 proto icmp6 all icmp6-type
neighbrsol"
RULES="$RULES\npass in inet6 proto icmp6 all icmp6-type
neighbradv"
RULES="$RULES\npass out inet6 proto icmp6 all icmp6-type
routersol"
RULES="$RULES\npass in inet6 proto icmp6 all icmp6-type
routeradv"
fi
RULES="$RULES\npass proto { pfsync, carp }"
case `sysctl vfs.mounts.nfs 2>/dev/null` in
*[1-9]*)
# don't kill NFS
RULES="scrub in all no-df\n$RULES"
RULES="$RULES\npass in proto udp from any port { 111, 2049 } to
any"
RULES="$RULES\npass out proto udp from any to any port { 111,
2049 }"
;;
esac
echo $RULES | pfctl -f - -e
fi
- and after dealing with the contents of /etc/sysctl.conf and
/etc/mixerctl.conf,
# set hostname, turn on network
echo 'starting network'
. /etc/netstart
if [ "X${pf}" != X"NO" ]; then
if [ -f ${pf_rules} ]; then
pfctl -f ${pf_rules}
fi
fi
then of courrse the rest of what you expect from a startup script.
Which means essentially an empty or invalid pf.conf will leave you with
a system where you are able to log in, unless of course you managed to
break your network in other ways.
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Is a 'PF default to block' setting outside pf.conf a desirable feature?
Daniel Hartmeier <[EMAIL PROTECTED]> writes: > Believe it or not, we now survived more than four years without that > feature, and noone ever complained (much less called it a 'fatal flaw'), > so you'll have to excuse me for, well, *yawn*. OpenBSD does not have a problem as far as I can see. The problem seems to be that the /FreeBSD/ PF port for some reason did not bring over the pre network interface rc bits from OpenBSD. I haven't checked the others (NetBSD, DragonFlyBSD), so I'm not sure what the status is there. Anyway the 'window of opportunity' would be ahem, rather small. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: pf and Microsoft Exchange IMAPS
"Raphael GRUNDRICH" <[EMAIL PROTECTED]> writes: > rdr on $ext_if proto tcp from any to any port 993 -> 192.168.1.1 > pass in quick on $ext_if \ > proto tcp \ > from any to 192.168.1.15 port imaps flags S/SA synproxy state assuming the exchange server is somewhere in $int_if:network, do you pass imaps on $int_if as well? -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: pf and Microsoft Exchange IMAPS
> I'm trying to redirected outside traffic to internal Exchange Server using > IMAPS protocol : when you manage to get it working, I would be interested in hearing about it. it might be a useful addition to my PF tutorial. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
spamd vs the sober worm
When the mainstream press started reporting stories like "You are not under FBI surveillance" about the newest windows worm variety, I started checking my logs for signs of what the stories described. Nothing of the sort reported had reached any windows machine on our network, so I started looking at the gateway's logs. The result is a very preliminary draft which I've put at http://www.bgnett.no/~peter/pf/spamd-vs-sober-prelim.txt My problem is that the sample size is so tiny. If I am to turn this into a publishable article, I need more data. Would anyone running pf plus spamd in greylisting mode volunteer to do the same tests and send me their results (or raw data for that matter)? Any other feedback would be welcome of course, and truly useful data will merit at least a mention in the thanks to list if this gets published. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: PF will not redirect to internal boxes
Elijah Savage <[EMAIL PROTECTED]> writes: > #pass traffic from the net to internal host > pass in on $ext_if proto tcp from any to $www_mail port 25 flags S/SA > synproxy state > pass in on $ext_if proto tcp from any to $www_mail port $web_ports flags S/SA > synproxy state hm. looks like you may have copied my incomplete tutorial rule set. You either need to pass on $prv_if as well or say simply pass proto tcp from any to $www_mail port 25 flags S/SA synproxy state pass proto tcp from any to $www_mail port $web_ports flags S/SA synproxy state I probably should update that part of the tutorial. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: PF will not redirect to internal boxes
Elijah Savage <[EMAIL PROTECTED]> writes:
> Peter I actually have not seen your tutorial
I'm a bit relieved it was not my fault (however unlikely).
Under any circumstances in my tute I try to stress ruleset keeping the
rules as readable as possible as a way to keeping the configuration
maintainable.
> The old file was so huge and a lot of stuff was not needed so I was
> going to start fresh with the basic services then build up to get more
> secure.
Things tend to accumulate, and some times it's easier to just start
over. Best of luck with your rebuild!
PS a minimally updated tutorial is up at the usual spot
(http://www.bgnett.no/~peter/pf/ - Norwegians will have to wait a
bit more)
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: seeking advice on anti-lockout config
Peter <[EMAIL PROTECTED]> writes: > I am looking for guidance on (3.8) pf configuraton that will help > prevent remote SSH access from being blocked due to the loading of a bad > ruleset. The obvious advice is, "don't write lockout rules" and "don't flush your old rules before loading fresh ones unless you've tested the new rules". Then again, you could go for a "back out to last known good" approach by testing your rule sets with a script that loads your new rule set but, always assuming you have saved your previous config somewhere accessible, backs out to your last working version after a few minutes. On OpenBSD, the default rule set which gets loaded before your network interfaces are configured lets you ssh in. This is extremely useful in you manage to create an invalid rule set and reboot. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: IP accounting (with ipa)
Peter <[EMAIL PROTECTED]> writes: > I am looking for IP accounting software to use with pf on 3.8. My first impulse would be to use pf labels. Randal L. Schwarz has written a nice and useful article about how he does his traffic monitoring and accounting at http://www.samag.com/documents/s=9053/sam0403j/0403j.htm Then again, the packages you mention may be better suited to your particular needs. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: PF Connection Throttling (prevent DoS)
Forrest Aldrich <[EMAIL PROTECTED]> writes: > Are there any ways to detect and/or limit the number of connections > coming in per IP, or act according to some other action (maybe a > script watching the SMTP logs). You could use the overflow keyword in your pass rules. The description in http://www.bgnett.no/~peter/pf/en/bruteforce.html is written mainly with SSH bruteforcers in mind, but with a few trivial adjustments would apply equally well to SMTP. On the other hand, I would risk a wild guess that the bots all run a certain family of operating systems, in which case Randal's altq based solution (also in my tutorial as http://www.bgnett.no/~peter/pf/en/altqsmtp.html) would be equally effective. > I'm also using PF on FreeBSD-6, FYI. FreeBSD 6 should have all the PF goodies up to OpenBSD 3.7 level, so both approaches should work. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: ssh bruteforce attempts and timeout of table w/ persist keyword
Tr0go <[EMAIL PROTECTED]> writes: > Is there a way to set timeout setting for a given pf > table ? On my list of things to look into Real Soon Now is a utility which should fit the bill: expiretable. expiretable lives at http://expiretable.fnord.se/ and has made it into the ports system. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: ssh bruteforce attempts and timeout of table w/ persist keyword
Tr0go <[EMAIL PROTECTED]> writes: > My ISP is resetting the line every 20 hours. So it run > automatically ppp.linkdown which restart pf with new > parameters as tun0 get a new IP address and pf rules > need to be updated... and THAT is the problem. Isn't that what the (interface) notation is supposed to take care of? as in ext_if = "tun0" # macro for external interface - use tun0 for PPPoE int_if = "xl1" # macro for internal interface # ext_if IP address could be dynamic, hence ($ext_if) nat on $ext_if from $int_if:network to any -> ($ext_if) -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: OpenBSD PF firewall on linux
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > I would like to put PF on my laptop and thought there was a linux port > available. I cannot find it. IIRC there have been occasional messages from people who have claimed that they have started working on a port of PF to Linux[1], but none claiming that the effort had been completed. > This is so I can use rules and report generators I am already familiar > with to protect my laptop, particularly in wireless mode. You would either need to adjust to Linuxish tools, or swithch your laptop to either OpenBSD or FreeBSD (lots more packages available). [1] For some odd reason these messages were not as easy to find as I had thought, but I'm pretty sure they're in the archives somewhere -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: PF Feature request: graceful handling of non-lookupable hosts.
[EMAIL PROTECTED] writes: > PF sqawcks if a hostname in any of it's files are not currently > findable. Is there a reasonable way to have it gracefully skip missing > hosts and carry on? Putting host names in your PF config files is a practice that comes with warnings in large, friendly, red and flashing letters attached. The whys and a few suggestions for workarounds have been discussed on the pf mailing list within the last few months. The main reason you do not want to make your firewall config depend on a name service being available is that, as you have already discovered, it makes your config a bit more brittle than otherwise. The workaround involves setting up a local name resolution with a cache that's persistent enough to survive reboots. In simple configs, that would possibly mean putting the ones you need in /etc/hosts, adding to your general admin checklist. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: Debugging/troubleshooting rule sets.
[EMAIL PROTECTED] writes: > Is there an online guide giving details about how to verify that a rule > set does what you want, and how to figure out what's wrong when it's > doing something else? To my knowledge, not specifically. Some people have reported finding the official PF docs a bit more accessible after spending some time with my PF tutorial at http://www.bgnett.no/~peter/pf/ (see events.html at the openbsd site for live performances of a slightly revised version). "debugging PF rule sets" might actually be a good tutorial topic. Noted for later. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: PF Feature request: graceful handling of non-lookupable hosts.
"Travis H." <[EMAIL PROTECTED]> writes: > The TTL is controlled by the authoritative name server, though. And > what about dynamic DNS? I wouldn't want to go there. The domain name system is fairly good at what it was designed to do, unfortunately firewall configs did not enter into the equation at the time. > That is a good idea. I also have been thinking of equipping > dfd_keeper with a periodic refreshing of rules (which would force > periodic lookups to catch changes in dynamic DNS hosts). This would still be vulnerable to failure in name resolution unless handled properly. Done right it sounds rather attractive though. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: Solution Request: I need to initiate outbound PPTP requests thru FreeBSD firewall
"Chris Willis" <[EMAIL PROTECTED]> writes: > What changes need to be made to the ruleset to allow outbound PPTP > connections? Here is the existing NAT rule I though might work based on > browsing the Archives: googlemancy on PF NAT PPTP seems to indicate that some sort of proxying (see eg http://undeadly.org/cgi?action=article&sid=20041009000521) and letting gre traffic pass is needed. I actually downloaded and started fiddling with frickin rather soon after it was announced, but before I had a working setup, the users who wanted to use a "Microsoft VPN" for something or other thought of some other way to do what they needed. (Microsoft - no, there's always an easier way :)) -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: Solution Request: I need to initiate outbound PPTP requests thru FreeBSD firewall
"Chris Willis" <[EMAIL PROTECTED]> writes: > I used FWBuilder to create the policy for the FreeBSD box. When I > install Linux 2.6 in place of the freebsd box, and use the exact same > FWBuilder ruleset, then outbound PPTP works great. To me, this sounds like FWBuilder's PF rule generator is buggier than its iptables script generator. You may not be aware that something or other did something seriously ugly to your rule set before it made it out to us. Recovering the format was not pleasant. Reading your rule set, a few things jump out at once (that is, after inserting sensible line breaks): * logic: have you checked that the address ranges in the tables you 'block quick' do not overlap with the address ranges you are actually using yourself? Rule evaluation order could be tripping you up. * logic: why do you list which protocols to NAT? If you NAT, you want to NAT everything, but limit what to *pass*. * logic: why is every filter rule a quick rule? * readability: why is every 'pass in' paired with a matching 'pass out' rule? * readability: why do you go for protocol numbers in your rdr rules, not names? This is certainly not a comprehensive analysis, but do look into the logic issues here. The readability issues are probably byproducts of using a GUI tool, so I won't beat you over the head with them just yet. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: ftp-proxy, and one nic: oh my...
"frederick thomas" <[EMAIL PROTECTED]> writes: > i've have had no luck in getting damn thing to ftp. not trying to be rude or anything, are you getting it to do anything at all? That is with > dhcp = "10.118.160.1" does this mean your IP address is in the 10.mumble range too? if so, > block drop in log quick on $extif from $privnets to any > > block drop out log quick on $extif from any to $privnets means you are dropping your own traffic. also, if you make every rule a quick rule, you are not making debugging any easier. you could try my tutorial at http://www.bgnett.no/~peter/pf/ for a gentle walkthrough. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Firewalling with PF tutorial, March 2006 update
Some of you may have heard that I gave a Firewalling with PF tutorial (aka Packet Filtering for Fun and Profit) at the UKUUG Spring 2006 conference in Durham, UK this week. The updated manuscript is now available for reading and downloading from the usual place, see below. This is essentially what I presented in Durham with a few obvious typos corrected. The useful suggestions from a few delegates there have not yet been integrated, however. Highlights: * A more thorough and hopefully useful discussion of icmp handling in your rule sets * The public services on local net section (rdr tricks) updated * A little info on the new (3.9) ftp-proxy * A little more background for the wireless examples * Expanded logging discussion * A bit more on spamd fun * The source files are now fetchable even by non-psychics If you spot any errors or feel something is in need of improvement, please let me know. Comments of all kinds are welcome. And yes, the manuscript is set to evolve a bit further for BSDCan and SANE, those updates will appear on-line, BSD licensed, after the conferences too. The files are at http://www.bgnett.no/~peter/pf/, or can be accessed directly as http://www.bgnett.no/~peter/pf/en/ - full text, html, English http://www.bgnett.no/~peter/pf/en/long-firewall.html - full text, one html file, English http://www.bgnett.no/~peter/pf/en/pf-firewall.pdf - full text, pdf, English http://www.bgnett.no/~peter/pf/en/pf-firewall_en.tar.gz - source files, for the above, nicely archived http://www.bgnett.no/~peter/pf/en/foils/ - foils, html, English Please note what it says at http://www.bgnett.no/~peter/pf/en/webhome.html#SUPPPORTTHEPROJECT Note: the Norwegian files at http://www.bgnett.no/~peter/pf/ are not yet in sync. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: Confuse with PF rules..
IMS <[EMAIL PROTECTED]> writes: > How to write rule to allow private network to access external website..??.. Assuming your you have posted your complete rule set, I see at least two things you would want to look into: - you are using nonrouteable addresses on your local nets. You probably want a NAT rule in your config as well. - have you enabled gatewaying (sysctl net.inet.ip.forwarding=1)? -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: Confuse with PF rules..
IMS <[EMAIL PROTECTED]> writes: > I 've already enable gatewaying and NAT rule on my firewall. If I allow > all traffic pass the pf (pass all). All connection work well. Pass all should not be necessary, unless, of course, really want to. However, I tend to argue that rules should be interface specific only if they really need to be. Your rule pass in quick on $inh_if proto tcp \ from $inh_addr to $stg_addr port 80 keep stat really only passes traffic to the gateway, and won't do you much good unless there's also a rule which lets the traffic pass out through $stg_if to $stg_addr. For cases like this, rolling it all into one rule would possibly meet your functional specs and help make your rule set more readable and maintainable in the long run. That is, I have a felling something like pass proto tcp from $inh_addr to $stg_addr port http keep state would serve you better in the end. My rant about this is at http://www.bgnett.no/~peter/pf/en/basicgw.html (part of a PF tutorial). -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: Migration document for people coming from IPFilter?
[EMAIL PROTECTED] writes: > Is there a document that describes how to translate common IPFilter > constructs to pf? To my knowledge, no such document exists, at least not any for public consumption. You're not the first one to suggest that writing a IPF to PF or IPFW to PF migration guide would be useful, though, so it's one of several possible projects. > Specifically, I'm looking for the pf equivalent of IPFilter's > > map $ext_if 192.168.10.0/24 -> 1.2.3.4/32 proxy port 500 ipsec/udp > map $ext_if 192.168.10.0/24 -> 1.2.3.4/32 proxy port 1 ipsec/tcp > map $ext_if 192.168.10.0/24 -> 1.2.3.4/32 portmap tcp/udp 1025:65000 > map $ext_if 192.168.10.0/24 -> 1.2.3.4/32 browsing the IPF howto briefly, I think you should be able to get those done via rdr constructs and matching pass rules. The finer details escape me, though. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: Migration document for people coming from IPFilter?
[EMAIL PROTECTED] (mouss) writes: > map != rdr. ipf != pf. .? -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: Migration document for people coming from IPFilter?
[EMAIL PROTECTED] writes: > Thanks Peter and mouss for the replies. Oh, you're welcome, > But I'm still puzzled. I read the description of the rdr directive a > number of times and looked at some of the examples but it's still not > clear to me how the above proxy and portmap subcommands translate into > pf's rdr command. It really looks like there is no equivalent for these > commands in pf... My own response was based on reading the IPF documentation rather quickly (it's been a while since I tried using IPF in earnest), so I may be missing one or more significant bits. It would probably be easier to help if you could explain what you want to do (ie make sure service Y requests from network Z reach computer X in my NATed LAN). -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: Migration document for people coming from IPFilter?
[EMAIL PROTECTED] writes: > The configuration is used to allow internet access with nat and > incoming connections on a /29 net. this sounds like a relatively straightforward NATed setup. PF handles NAT itself, so something along the lines of [ pf.conf snippet starts ] ext_if = "tx1" int_if = #whatever your internal interface is localnet = # your local net; "addr/mask" or "if:network" notation # ext_if IP address could be dynamic, hence ($ext_if) nat on $ext_if from $localnet to any -> ($ext_if) [ pf.conf snippet ends ] should take care of > # provide internet access from the NATted LAN > map tx1 192.168.1.0/24 -> 1.2.3.4/31 portmap tcp/udp 1025:65000 > map tx1 192.168.1.0/24 -> 1.2.3.4/31 For the ftp access > # make ftp service request reach the internet from the NATted LAN > map tx1 192.168.1.0/24 -> 1.2.3.6/32 proxy port ftp ftp/tcp running ftp-proxy is recommended. The traditional one runs from inetd, while the new (OpenBSD 3.9 onwards) is a standalone daemon. Both are covered in my tutorial[1], some details differ. > # let port 3000 requests from 192.168.2.0/24 reach server 192.168.1.1 > on port 3000 in the NATted LAN > rdr tx1 from 192.168.2.0/24 to 1.2.3.3/32 port = 3000 -> 192.168.1.1 > port 3000 > # let port 6502 requests reach internal PC 192.168.1.101 on port 3000 > in the NATted LAN and the same for port 6502 to .102 > rdr tx1 1.2.3.3/32 port 6502 -> 192.168.1.101 port 6502 > rdr tx1 1.2.3.3/32 port 6503 -> 192.168.1.122 port 6503 These are ordinary redirects as far as I can see, so would carry over with minor adjustments. Hope this helps, [1] the tutorial is a work in progress, with a reasonably up to date version posted at http://www.bgnett.no/~peter/pf/. For the ftp part, see the section http://www.bgnett.no/~peter/pf/en/ftpproblem.html -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: Passive FTP error after restart machine..
IMS <[EMAIL PROTECTED]> writes: > I'm quite sure that I didn't change any things in my > box.. > > So I turn back to use old machine.. but my client > still couldn't use passive ftp.. If you really did not change anything, it sounds like your client is getting bit by changes made elsewhere in the path from your client to the ftp servers in question. On the other hand, we have had cases (using ftpsesame on OpenBSD 3.7) where passive ftp stopped working apparently due to memory starvation on the filtering gateway. After killing a pftop which had lost its controlling terminal due to a reboot of a putty.exe equipped machine elsewhere, it all started working again in that particular case. Given the stability of the platform running putty.exe, this has happened more than once. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: PF inadequacy: queue download
[EMAIL PROTECTED] writes: > it's good to hear from someone who isn't pretending to be a/speak for > the developers. Kestas, several core PF developers have responded to your original message and various follow-ups, essentially trying to elicit some sort of fact-based reasoning why this feature should be developed by them. Your response to them has been essentially "Some other product has this" mixed in with some repetions of "I want this", combined with a liberal dose of name-calling. Neither of these approaches are terribly useful as tools of persuasion. Discussions of this general mold seem to pop up with alarming frequency, so I will outline some of the smarter ways to get developers' or more experienced users' attention - * "Some other product has this, why can't PF do this" Well, in most cases it is likely that PF can indeed do what you want, but possibly in a slightly different way than what you would do with the other product. If you are able to explain to other list readers what it is you want to achieve, some helpful user is likely to point you in the right direction. Offering explanations of what you want to achieve is always a lot more useful than quoting a chunk of some other product's configuration file claiming that PF is deficient if its users can't parse product foo's configuration file. * "I want this! I'm sure PF does not have this" It is possible that you have indeed found a useful feature which could usefully be implemented. If you have identified a missing feature which you feel is essential to your network, then clearly something needs to be done. Making the case for a new feature to be implemented takes a bit of work (offering up some code for review usually helps), most important is making a well reasoned case that this is a) actually a useful feature and b) the feature belongs in the base system. It is quite possible that your project satisfies condition a, but not condition b, which means that it is better off as a separate program to be maintained outside the base system. Examples of "a, but not b" features which became widely used programs maintained outside the base system are pftop and expiretable. * "You're a bunch of mindless moron zealots! I want to talk to the real developers!" The likelihood that the stranger on the PF mailing list telling you that your favorite missing feature is not worth implementing is indeed a real developer with commit access to the source tree is far from negligible. If your explanation of the obvious goodness of your wished-for feature does not convince, you should consider the possibility that a) your idea isn't actually that obviously good or b) you need to work a bit more on that explanation. Abuse and name-calling never helps your case, ever. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: Open BSD 3.9 unable to send email with attachment thru pf
"Ajith Kumar" <[EMAIL PROTECTED]> writes: > If I disable pf I am able to send mails with attachments.It looks like > problem with firewall itself. The problem here is that you keep repeating a very vague description of symptoms without giving us any information which could point us in the right direction. Basically, to PF, the difference between a text only mail message and one with an attachment lies only in the amount of data which is transferred, if that. I reiterate that the more likely culprit is some sort of content filtering you are either not aware of or not telling us about. In some truly resource starved configurations, such as a system extremely low on memory, loading PF could be what makes the system start swapping, if the connection between your gateway and the mail server is already rather saturated a largish mail message would have trouble making it without timing out, and so on. There are several more ways to misconfigure a machine so it will produce the rather bizarre symptoms you are describing, but from the information you are volunteering it's pretty much impossible to tell what is causing the situation. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
Re: pf "default deny" compile-time option?
Damien Miller <[EMAIL PROTECTED]> writes: > Mismatches between pfctl and the kernel happen on -current from time to > time, and I think being locked out is better than falling back to permit > all... .. if you have physical access to the machine in question. Then again, if you run -current on something mission critical a continent away, 'glutton for punishment' comes to mind. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
Re: lists vs tables
Ken Gunderson <[EMAIL PROTECTED]> writes: > Are there any reasons to prefer lists over tables (or vice versa) > for the smaller sized stuff, e.g. /29 - /26 subnets? Any comments > about when should one not use tables? Tables are exclusively for addresses, and pfctl has quite a few options which makes it easy to do operations on tables from the command line. So I suppose any set of addresses which conceivably could change more frequently than you would want to reload your entire rule set would be a prime candidate getting turned into a table. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
Re: PF Table Size - Sanity Check
"Michael K. Smith - Adhost" <[EMAIL PROTECTED]> writes: > We are looking at pulling in a listing of about 70,000 IP entries (most > of them are hosts, not subnets) into a PF Table. Is there any hard > limitation to the configuration size or ability to parse through > something that large? The limits are tuneable via pf.conf 'set limit' options. I forget what the default max table size is, but the pf.conf man page contains the magic to set it to 100,000 entries. Going from there should be straightforward. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
EuroBSDCon 2006 PF tutorial online
As some of you may be aware, I presented a half day PF tutorial at EuroBSDCon in Milan. The manuscript is now online in several formats at http://home.nuug.no/~peter/pf/. This is a manuscript I've revisited on occasion over roughly the last two years, intended as a flash intro to the fun and useful things you can do with PF and related tools, and an ongoing work in progress. I intend to keep it reasonably up to date and possibly expand it somewhat. NOTE: Some of you may have seen this online earlier at bgnett.no. If you have links pointing to the bgnett.no address, please change them to point to the new address http://home.nuug.no/~peter/pf/ instead. File and subdirectory names remain the same. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
Re: ext_if, int_if?
Sergey Prisyazhniy <[EMAIL PROTECTED]> writes: > how can I automaticaly initialize pf rules without making subj > interfaces specification in /etc/pf.conf by hands? If your rules do not specifically need to be bound to any particular interface, you can write such things as block all pass from self to any keep state or pass from 10.12.14.0/24 to any port ssh keep state it's extremely flexible really. The reason you see interface name macros so often is that people tend to find them useful, but you can do without them entirely if you like, I suppose. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
Re: ext_if, int_if?
Sergey Prisyazhniy <[EMAIL PROTECTED]> writes:
> Yes, Luca :). The think is, that I want, for example, to setup remote
> machines
> via siteXYtools (also load to pf.conf).
> And as you can get, I don't know anything about the remote NIC's, so in
> this case
> I wana make fully automatical process... :)
as I said earlier, if your requirements can be satisfied by a rule set
where you do not specify which specific interface the filtering
happens, you're OK.
For example, your definition of 'the local net' does not need to be
$int_if:network, it could equally well be 'localnet = 194.54.103.64/26'
or somesuch, with rules like
localnet = 194.54.103.64/26
client_out = "{ ssh, domain, pop3, auth, nntp, http, https }"
block all
pass inet proto tcp from $localnet to any port $client_out \
flags S/SA keep state
pass inet proto tcp from any to $localnet port ssh flags S/SA keep state
I have a semi-rant about these things in the tutorial[1], which I
probably will be accused of plugging quite shamelessly at this point.
[1] http://home.nuug.no/~peter/pf/, specifically about these matters at
http://home.nuug.no/~peter/pf/en/basicgw.html#GWPITFALLS and
http://home.nuug.no/~peter/pf/en/whatsyourlocalnet.html
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
Re: Any set ?
Albert Shih <[EMAIL PROTECTED]> writes: > The purpose is to open (inside --> outside) my subnet for making update > during the nigth (between 34 am) and after update I'm close everything You could use anchors I suppose, or if it's simply a matter of opening a specified set of ports for traffic to specified hosts elsewhere, you could write your rule set to pass the required services to or from members of a table, which you then fill with IP addresses, run the required commands, then empty the table. I have something hinting at how to do this in the PF tutorial at http://home.nuug.no/~peter/pf/, specifically http://home.nuug.no/~peter/pf/en/tables.html, and of course man pfctl is your dearest friend :) -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
Re: Squid 2.6 transparent proxy with pf
Dominik Zalewski <[EMAIL PROTECTED]> writes: > I have OpenBSD 4.0 firewall and I would like to redirect all outgoing http > requests to my squid web proxy. Daniel Hartmeier wrote about this a while back, his article can be found at http://www.benzedrine.cx/transquid.html -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
Re: Squid 2.6 transparent proxy with pf
Dominik Zalewski <[EMAIL PROTECTED]> writes: > My question is can redirect traffic on $int_if to another machine connected > to the same interface? Does this rule is corrrect ? You can redirect, but you need to let the packets from the proxy pass without redirection to the rest of the world. > rdr pass on $int_if proto tcp from any to any port 80 -> $squid port 8080 I would supplement this with a 'no rdr' rule for the proxy generated traffic. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
Featuritis: overload on transferred volumes, auto-expiring tables?
The 'FUP' thread[1] had me thinking a bit about the problem the original poster presented, and what I ended up with was ideas for two possibly desirable PF features. Fine grained bandwidth control via HFSC queues was suggested. I'm sure HFSC is a fine algorithm, but I am almost sure it is wrong for what the OP in that thread wanted. HFSC is a very complicated beast, and while I think I understand it in general terms, I'm not at all sure I would be able to predict the results in all cases, or for that matter explain what happens under a HFSC regime to a user. I think what the OP was after and what might possibly be a useful addition to PF's feature set is a variant of overload rules, based on bandwidth consumed or amount of data transferred. I imagine a rule like pass from $localnet to any port www queue www \ (max-transfer 4MB/2s overload flush global) assuming for the sake of argument that other parts of the config contains the necessary queue declarations and a different pass rule which occasionally lets traffic from the inhabitants through on a tiny portion of available pipe. It would take actually tracking the number of bytes transferred per IP address or connection, and I have only the haziest idea of how much heavy lifting and pain in general would come out of actually trying to implement something like this. However if one or more of the relevant developers think it's a good idea, something like this might magically appear in an upcoming release, if not necessarily 4.1. The OTHER feature I thought of, since we're dealing with tables, is to have a way to declare tables with expire time for its entries. We have expiretable for that, but I for one would find it convenient to be able to declare a table such as table persist expire 24h meaning that table entries are removed when they have not been referenced during the last 24 hours. Oh well, it's late already. But it would be nice to hear any thoughts on this, including "shoot this down, quick!" [1] http://marc.theaimsgroup.com/?l=openbsd-pf&m=116808871830284&w=2 -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: PF integrated solution
Felipe Neuwald <[EMAIL PROTECTED]> writes: > I'm looking for a solution where I can manage more users with more > flexibility, like merge pf rules with user information on database, > authentication (maybe with Radius). You don't say if you've looked into authpf(8) at all. If you haven't, taking a look at the PF user guide's authpf chapter[1], the authpf man page[2] of for that matter the sample setup in my tutorial[3] may be worthwhile. [1] http://www.openbsd.org/faq/pf/authpf.html [2] http://www.openbsd.org/cgi-bin/man.cgi?query=authpf&sektion=8&manpath=OpenBSD+4.0 [3] http://home.nuug.no/~peter/pf/en/vegard.authpf.html -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: using pf to block multiple connections in a given time
John <[EMAIL PROTECTED]> writes: > This is every couple of seconds as you can see. What i'd like is to > allow max 2 failures from one IP in 30 seconds, if more than that write > to /etc/shitlist.txt which, if the connecting IP is found in there, logs > and silently drops the connection. Can pf do this? The details differ slightly, but you can get something functionally equivalent using overload rules and a table you block. I have some musings on this in the tutorial[1], it does not cover all possible wrinkles but should be enough to get you started. [1] http://home.nuug.no/~peter/pf/en/bruteforce.html, choice of formats from http://home.nuug.no/~peter/pf/ -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: DNS answers blocked?
Jacques Beigbeder <[EMAIL PROTECTED]> writes: > But where is the trouble? Is there a better fix? hard to tell without taking a peek at your actual rule set, but could it be that you forgot "keep state" in the pass rules which let your name service queries through? -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: help in configuring icmp rules
Joseph Lappa <[EMAIL PROTECTED]> writes:
> icmpv4_types = "{ echorep, host-unr, needfrag }"
> pass inet proto icmp all icmp-type $icmpv4_types keep state
according to my /usr/src/sbin/pfctl/pfctl_parser.c, you probably need
'unreach' instead of 'host-unr' in your types list. If you use a list
of icmp codes too, 'host-unr' would be a valid member of your list of
codes.
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Fair distribution of borrowed bandwidth with a lot of users
Federico Giannici <[EMAIL PROTECTED]> writes: >> or using a script to inject ips into >> a tables based queue setup? > > I already use a script to generate the pf.conf file, but I cannot > understand what do you mean with "tables based queue". I think what he means is, you use "pass from queue foo" constructs -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: PF and forwarding to dmz
Norman Maurer <[EMAIL PROTECTED]> writes:
> It seems to me that I need one "in" and one "out" rule for each
> FORWARD rule. Is this right ?
not necessarily. you can have rules which are not explicitly bound to
an interface, such as
webserver = "194.54.107.19"
webservices = "{ www, https }"
block all
pass proto tcp from any to $webserver port $webservices synproxy state
(bah, untested, but you get the idea)
In fact, for traffic you just want to pass through your gateway you
can unclutter your rule set significantly this way.
For setups where you need to pass traffic in on a specific interface
(or interface group) and out on a some other specific interface or
group, it's a different story of course, but PF lets you do the less
complicated things in very straightforward ways.
This is the kind of stuff I rant about extensively in the tutorial
at http://home.nuug.no/~peter/pf/, btw (but it's got other things as well)
- P
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: PF and forwarding to dmz
Norman Maurer <[EMAIL PROTECTED]> writes: > The only problem I noticed was that we had some connection problems > when using synproxy in front of our webserver. So i replaced it by > keep state. Any idea if this is a know "bug" ? I remember some reports about synproxy oddities on FreeBSD a while back. I'm not sure how that story ended. The solution, if there is one, (and it's FreeBSD you're using) is probably in the archives. I probably should do some digging on this, but unfortunately it will have to wait until a few deadlines have been kept. In the meantime, plain old keep state isn't too bad either. Cheers, -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: states handling
"Ilya A. Kovalenko" <[EMAIL PROTECTED]> writes: >>>block in inet from 192.168.0.1 to 192.168.114.31 >>>pass in inet from 192.168.114.31 to 192.168.0.1 flags S/SA keep state >>> (does not work - neither pings nor TCP) >> Here, you only pass the *inbound* packets; you also must >> pass the outbound packets on the opposite interface. > > So, single state entry affects traffic on single interface only ? no. your pass rule only affects incoming traffic. You say essentially, block incoming traffic with a source address equal to 192.168.0.1 and a destination address equal to 192.168.114.31 pass incoming traffic with a source address equal to 192.168.114.31 and a destination address equal to 192.168.0.1 unless you are happy with the traffic only reaching your gateway, you need to specify how the traffic is to go out to the destination address. in simple environments it is possible to work around the problem by omitting direction (implicitly writing rules for both inbound and outbound traffic), ie block inet from 192.168.0.1 to 192.168.114.31 pass inet from 192.168.114.31 to 192.168.0.1 flags S/SA keep state -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: states handling
"Ilya A. Kovalenko" <[EMAIL PROTECTED]> writes: > Thank you very much for comprehensive explanation. I totally miss, > that state entry uses gateway-related direction to match packets. > *reading manuals one more time* It's a fairly common mistake, but the gateway-centring view is really is the only logical perspective if you think of it. That's why I spend so much time hammering that in during the relatively basic PF tutorial I've been giving. (yes, the one at <http://home.nuug.no/~peter/pf/>). -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: pfctl limits on number of tables
Russell Fulton <[EMAIL PROTECTED]> writes: > These tables are at the end of a long list of table definitions and my > immediate guess was that we had exceeded some resource limitation > (memory -- clearly) that pf used when building the tables. You can tweak the limits via 'set limit' options in your pf.conf, within the limits of actually available memory. see man pf.conf and look for 'set limit'. Also see Daniel Hartmeier's undeadly.org articles starting with http://undeadly.org/cgi?action=article&sid=20060927091645 for some explanation. The error reporting messages could possibly improved upon too. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: linux/iptables/proxy arp to pf/redundant firewall
[EMAIL PROTECTED] writes: > i was thinking at a bridge firewall with openbsd, and maybe carp to be > redundant > but carp is not working with bridge I'd think really hard about why you would want to make it a bridge then. Bridges generally makes it harder to debug and as you say it takes your main redundancy feature off the table. Why not just a carp/pfsync setup? -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: linux/iptables/proxy arp to pf/redundant firewall
[EMAIL PROTECTED] writes: >> then. Bridges generally makes it harder to debug and as you say it >> takes your main redundancy feature off the table. Why not just a >> carp/pfsync setup? > > cause i'm in the same subnet > if not, carp will be the solution no ? still don't see how a bridge would be totally desirable, bu then it's possible I'm just being incredibly dense. I think I'd need more information about your setup such as addresses and netmasks to offer any input on that. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Need more performance (FreeBSD or OpenBSD)
Michael J McCafferty <[EMAIL PROTECTED]> writes: > Should I use OpenBSD 4.2 with the improvements in speed in PF but only > use one of the two (or more cores) or shall I use FreeBSD 6.2 to be able I haven't really stress tested either of them, but all reports indicate that PF in 4.2 is significantly faster than in earlier versions. The PF in FreeBSD 6 is OpenBSD 3.7-equivalent or thereabouts so moving the config from any recent OpenBSD could mean some pf.conf editing depending on just what features you use. My first choice would be to upgrade to OpenBSD 4.2, but I'm also slightly curious about a direct comparison of FreeBSD vs OpenBSD performance on the same hardware. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Need more performance (FreeBSD or OpenBSD)
"Michael W. Lucas" <[EMAIL PROTECTED]> writes: > It actually seems to me that you're in an ideal position to create > those comparison benchmarks. One hosts with each OS, using CARP to > failover between them. I suspect that both groups of developers would > be interested in the results. Once you have made a decision, > upgrading one is simpler than changing both. It would be interesting to hear any data that comes out of tests like that. That is, as long as the OP doesn't mind being a guinea pig. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: PFW... ever used it?
kenneth2k1 <[EMAIL PROTECTED]> writes: > Does the syntax "any" work as a source or destination when setting up my > rule? "any" is valid as a source, destination or both if that's what you need to express. > Is a protocol always necessary on my rules? not always, but in practical terms, most of your rules will need to specify protocol. > What does the Family Address represent? What does inet mean and when should > I use it? That's probably "Address family". inet is IP version 4, as distinct from inet6 which denotes IP version six. > Here is what the pfw interface has as my rules after I configured them in > the web browser. I am sure there are mistakes here, so if someone could show > me what I'm doing wrong, that would be GREAT!!! That does not look like a complete rule set. If you do all your filtering on $ext_if that's fine, but then we would need to know that (or see the complete rule set, if necessary with key data shrouded). Now don't take this as anything personal, but your message reminds me why I'm sceptical when it comes to pfw and other point'n'click frontends. They're only really useful if you know what you're doing, and if you /do/ know what you're doing it's probably quicker to just edit pf.conf and be done with it. The general recommendation is to go to the normal information sources such as man pf.conf, man pfctl, <http://www.openbsd.org/faq/index.html>, and just to toot my own horn, there's word out that those *excellent* references are a little easier to take in usefully after you've spent some time browsing <http://home.nuug.no/~peter/pf/> (also nostarch.com may have the perfect xmas present for you). -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
"The Book of PF" exists, physical copies documented
Dear friends, I have just taken delivery of my box of /The Book of PF/[1] author's copies, and I'm finding I'm a bit at a loss for words when it comes to describing the feeling. The thing exists. And it feels great to finally see the thing for real. (OK, I cheated a bit and had five copies printed locally for OpenCON[2], but these are the real ones, slightly different binding) We didn't manage to release the book the same date as OpenBSD 4.2 (yes, that was the original plan), but the thing has been written, printed and should be on its way to all those who preordred as well as to better bookshops everywhere. I'm not directly involved in distribution and can not make any guarantees about when you'll get yours (a slightly more experienced author has written an explanation of that[3] - only this one was printed in Ann Arbor, Michigan, USA), but even if it's late for the holidays I hope you'll enjoy your copy and find the book useful. Now of course the usual factors interfered even with the author copies. There is a thing about courier companies and 18th century buildings. Even faced with a relatively small one such as the one I live in, DHL managed to make two attempts at delivery at the disused entrance clearly marked 'deliveries at the other door please', so the delivery finally happened at my office - also located in a 18th century building, but at least one where the DHL people have been before. But it finally arrived and life's good :) One interesting factoid (fsvo) is that this happened within hours of the twenty-five thousandth unique visitor (since EuroBSDCon 2006 that is) hitting the book's predecessor, the online PF tutorial[4]. So happy hacking holidays everyone, [1] http://nostarch.com/pf.htm, also see http://www.bsdly.net/~peter/freshbooks.jpg or (slightly faster) http://home.nuug.no/~peter/freshbooks.jpg [2] http://www.undeadly.org/cgi?action=article&sid=20071207191612 - that's me completely obscured at the back to the right in the third picture (ok, I'm in a few others ;)) [3] http://marc.info/?l=openbsd-misc&m=105723966516199&w=2 [4] http://home.nuug.no/~peter/pf/ -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: PF, limit remote clients by total bandwidth used over time
Calomel <[EMAIL PROTECTED]> writes: > Can PF be written to filter client connections based on the total amount of > bandwidth a remote client uploads/downloads over a given time frame? As > far as I know PF does _NOT_ have this ability. Well, you already have the possibility of using variables such as $srcaddr to construct your labels, creating essentially per-client statistics. If you write a program that's able to read those statistics and act upon them, you could for example have your program move addresses from one table to another based on the accumulated statistics such as total bytes or packets passed from a specific address. The next and final step would be to write your rules with various-sized queues and logic to assign traffic to queues based on table membership. Supply that well-written program and easy to use program (for PF/OpenBSD values of), and I would think you're a lot closer to a solution that would fit the basic requirements, ie adding flexibility without adding clutter to the system at the same time. Just my EUR 0.02, and maybe better ideas will be had by morning. All the best, -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: hoststated
Loke Berne <[EMAIL PROTECTED]> writes: > 1 for dynamic and one for static content the dynamic content works > fine but when I try to use both of em the traffic seems to end up on > the wrong backend I sense perhaps http://www.bsdly.net/bookofpf/errata-01-hoststated-rdr.txt would clear things up. Sorry. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Pass rule from subnet to external
Calomel <[EMAIL PROTECTED]> writes:
> You could always try setting up a table will ips/subnets of your network
> you do not want the wifi network to goto called $my_localnets. Then use the
> not (!) operator to say, wifi can go anywhere but not (!) $my_localnets.
>
> my_localnets = {10.10.10/24, 10.20.20/24}
> pass in on $wifi_if from $wifi_if:network to !$my_localnets
unless you have either a matching pass rule or a skip on the interface
facing the world, the 'pass in' will only pass as far as the machine
where the rule set runs, though. The 'from' and 'to' keywords only
denote source and destination addresses respectively.
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: New pf install on Freebsd seem to be a slow starter.
Leslie Jensen <[EMAIL PROTECTED]> writes: >> With DNS names? That's likely to be your problem. > > Oh, I didn't know that! Can you tell me how to handle this? The problem is that this makes your ruleset load dependent on working name resolution, which may not be available at the time rc starts pf and loads your rule set. > The problem is these hosts are not fixed IP's so they use no-ip > (http://www.no-ip.com/) to provide a fixed address. That doesn't make things any easier, unfortunately. I'd say by all means define the table, but wait until somewhere in your rc.local to fill in those addresses (say, with a script that checks if each name resolves, then adds the returned addresses to the table). Brittle, but with a fighting chance of working. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
A PF Certification - what do you think?
Would a creating a PF certification be worth putting some effort into? The reason I'm asking is that the good people over at The BSD Certification Group (http://www.BSDCertification.org/) are pondering that very question, and they contacted me about it. My response was essentially "yes, it would be useful to have a certification, mainly because it would make PF (and by extension, OpenBSD and the other BSDs) move visible at the suits level, making a useful certification would be a lot of work, though". A lot of work, and making it into a useful certification depends critically on Subject Matter Experts (aka SMEs, or please look in the mirror) and the quality of the work they do when specifying the task requirements that go into the certification specification. BSDCertification.org is, as we can read in their faq[1], 'committed to developing a testing methodology which tests real world skills and is not just a "paper certification". ' or, in layman's terms "our starting point is the best possible set of answers to the question, 'what would be the required or optimal skills be for somebody to fill a position in the field of the certification?' ". Once the task and skills spec is complete, test construction starts, and finally a psychometrician is set to work to check that the test actually provides a valid result for the specification, that it lets candidates with the right skills pass while others will fail. You can read a more detailed description over at the bsdcertification.org web site, but I think I've covered the key points here. So, my fellow PF SMEs, would you like to be involved in this, and contribute to creating a PF certification. I would like to have your input, including but not limited to 'would it be more useful with a multi-level certification', and of course any input on what the task and skills spec should contain. [1] http://www.bsdcertification.org/index.php?NAV=FAQ#Q04 -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Routing VPNs through a second interface.
Jeff Simmons <[EMAIL PROTECTED]> writes: > Heh. That works. But I sure pity the fool who has to take this over if I get > hit by the proverbial bus. ;-) Rule 1) don't hire fools (suits tend to underestimate the importance of that) Rule 2) document as you go or soon enough after the fact that you still understand what you did and why (suits tend to pay lipservice to this but rarely leave you time to actually do it) a corollary to rule 2) is that with from-the-trenches documentation, you will be a lot better prepared to design the network that's based on an analysis of observed needs and an actual specification, somewhere down the road. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
PF tutorial in London, Nov 26, 2008
If you are not quite up to speed with PF and related tools yet, or if you have one or more colleagues you don't have time to train in basics yourself, you might want to send them away to learn a bit. In fact, you can send them to London and get a better version back. The UKUUG[1] is organizing an intensive Full-day PF tutorial[2] featuring Book of PF[] 3author Peter Hansteen[4]. Click the links, then go to the OpenBSD events page[5] for ways to extend that away from work period. [1] http://www.ukuug.org/ [2] http://www.ukuug.org/events/pftutorial/ [3] http://nostarch.com/pf.htm [4] http://bsdly.blogspot.com/ [5] http://www.openbsd.org/events.html -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: pf overload keyword for TCP only?
gwen hastings writes: > so I inserted the following in pf.conf and while it loads up it doesnt > seem to work ie pfctl -Tshow -t bruteforce is empty It may be that you're not tight-fisted enough. I'd try two things - add logging to the rule, log (all) even, and use tcpdump to study the actual traffic and the inevitable tweaking of the parameters such as lowering number of allowed connections. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: dual ISP puzzle
Michael Grigoni writes: > Please let us know what IRC server and channel you found for 'pf' > discussions; it would be very useful. FreeNode has a #pf channel. relatively low volume, at times quite useful. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: max-src-port-states to limit 1:N source port states???
hu st writes: > So could pf limit the maximum number of simultaneous state entries > that a single source IP's source port can create with a rule? > (borrow from man pf.conf :)) max-src-states? (see STATEFUL TRACKING OPTIONS in man 5 pf.conf) - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: syntax error while using scrub with OpenBSD 4.6
Micha Holzmann writes: > But regardles how i write it into the pf.conf and check it with pfctl > i get a syntax error message. > > I tried several syntax: > > scrub all > scrub in all Yes, you've hit the one small flag day change in OpenBSD 4.6 - try match in all scrub (reassemble tcp) or some variation (some other parameters are possible). It's in the official docs, but not all the other resources out there that your favorite search engine will turn up have caught up with the news yet. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: pf is blocking too much connections?
LeiV writes: > I have a openbsd pf firewall protecting a web server, I have noticed that > some pages gives me errors when browsing through my site (sometimes it works > sometimes not), then I looked at pf and saw that is blocking a lot of > connectyions, how do I know which connections is blocking? The statistics don't really show us much of anything by themselves. What are the actual error messages? What does your rule set say? Do you have meaningful log data (pflog or otherwise)? That's the kind of information we would need to help you debug, diagnose and fix. One random thought - does your rule set include such things as limits on max number of connections? Pure speculation, of course, but it is one of many situations would fit the symptoms you describe. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Restricting source with dDNS (dynamic DNS)
Jim Flowers writes: > To lock down services (particularly ssh) as tightly as possible, I like to > allow > administrative access to a firewall only from specific ip addresses. makes sense. > Unfortunately, some of the administrators are working from dynamic ip > addresses > that change with some frequency. > > Is there a straightforward way to incorporate dynamic ip source addresses in > the > pf ruleset? I'd say this sounds like a situation where authpf could come in quite handy. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Restricting source with dDNS (dynamic DNS)
"Karl O. Pinc" writes: >> I'd say this sounds like a situation where authpf could come in quite >> handy. > > How? I thought authpf grants additional rights to those who > can ssh. But he wants to restrict those allowed to ssh period. authpf loads rulesets, with all the flexibility that comes with pf. but you're right, it requires ssh to be accessible in order to log in, and so may not be what the original poster was looking for. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
