Re: PF shirts?
On Tue, 7 Sep 2004 09:33:37 +0200 Jedi/Sector One [EMAIL PROTECTED] wrote: : Is it planned to add PF shirts to the OpenBSD store? : That one is cute :) : : http://openbsd.org/papers/bsdcan04-pf/mgp2.html : :-- : __ /*-Frank DENIS (Jedi/Sector One) j at 42-Networks.Com-*\ __ : \ '/a href=http://www.PureFTPd.Org/; Secure FTP Server /a\' / : \/ a href=http://www.Jedi.Claranet.Fr/; Misc. free software /a \/ That is actually a Paul Frank shirt. It just so happens that his initials fit here. To the best of my knowledge that series of products is out of print. -- I think every good Christian ought to kick Falwell right in the ass. -- Barry Goldwater
Re: PF --- spamd
On Thu, 2 Sep 2004 02:04:00 +0200 Ed White [EMAIL PROTECTED] wrote: :Hi, : :I'm playing with OpenBSD 3.6-beta. : :I wanted to test spamd with greylisting, but it seems that the interaction :with PF is broken. In short spamd doesn't add anything to /var/db/spamd so :I'll never get my IP added to spamd-white What does `ps aux | grep spamd` say? Mine says: $ps aux | grep spamd _spamd5408 0.0 0.2 8788 632 ?? IsSun01PM1:15.88 spamd: (pf spamd-white update) (spamd) _spamd 892 0.0 1.6 9044 4124 ?? S Sun01PM0:12.37 /usr/libexec/spamd -g _spamd 17732 0.0 0.2 8784 568 ?? I Sun01PM0:01.79 spamd: (/var/db/spamd update) (spamd) -- What color is a chameleon on a mirror?
Re: preventing state runaway
OpenBSD 3.6 now comes with shiney red buttons. Buy it starting November 1st. On Tue, 24 Aug 2004 13:47:15 -0500 (CDT) Jeff Wilson [EMAIL PROTECTED] wrote: :Could you post a brief synopsis, marketroid style, of incentives to :upgrading to 3.6? (BTW, when will it be released?) I know I could RTF :change log ... but what can you tell me in the brief moments I have :between firefights? -- Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off.
Re: synproxy to local
On Mon, 24 May 2004 23:19:21 +0200 Daniel Hartmeier [EMAIL PROTECTED] wrote: :On Mon, May 24, 2004 at 12:59:15PM -0500, Peter Hessler wrote: : : Just updated my firewall to the May 21st source, and I am having a :problem with synproxy. My synproxy rule is: : :This is the second (or third) report, I think something really broke. Do :you have an idea what version you were running before (which was fine), :so I get a smaller window to check? : :Daniel March 24. Sorry its such a large window. :( -- Given the choice between accomplishing something and just lying around, I'd rather lie around. No contest. -- Eric Clapton
Re: Changing rulesets remotely
Run an at(1) job for 5 minutes in the future. Have it put /etc/pf.conf as the active ruleset. Then install a ruleset that isn't /etc/pf.conf (like from your home directory, or the like). If it works, just kill the at(1) job. If it doesn't, wait 5 minutes. I also like the `shutdown -r +2; pfctl -f ./pf.conf` bit myself. Especially when that machine is a gateway for an entire company. Scew that up a few times, and you'll make sure to make the rules work the first time. Don't get complacent though, because you'll definitly screw it up somewhere along the way ;-). On Wed, 28 Apr 2004 13:41:34 -0600 Tim Pushor [EMAIL PROTECTED] wrote: :I am looking at trying to come up with a way to change rulesets remotely :with provisions to back out the change if I accidently shoot myself in :the foot ;-) : :I am just wondering if someone has already come up with an elegant (or :not so) way of doing this already? : :Thanks, :Tim -- I can't understand it. I can't even understand the people who can understand it. -- Queen Juliana of the Netherlands.
Re: PF/spamd oddity
On Thu, 18 Mar 2004 06:27:39 -0500 Jason Dixon [EMAIL PROTECTED] wrote: :Thanks, that works. Looking at pf.conf (5), it appears that rdr pass :is just a feature to bypass the normal filtering rule. I don't see why :my mine would've failed. I'm running 3.4 -stable. Any ideas? No, it adds a pass rule to the ruleset. Doesn't bypass anything. -- Birth, n.: The first and direst of all disasters. -- Ambrose Bierce, The Devil's Dictionary
Re: PF/spamd oddity
On Thu, 18 Mar 2004 10:02:15 -0500 Jason Dixon [EMAIL PROTECTED] wrote: : :Not according to pf.conf (5): : :If the pass modifier is given, packets matching the translation rule are : passed without inspecting the filter rules : :Is this taken out of context? : :-- :Jason Dixon, RHCE :DixonGroup Consulting :http://www.dixongroup.net : : Oh. My bad. I remembered the explanation wrong. (I don't agree with how it is done, but since I have no code to offer to fix it, I'll shutup.) -- There's no future in time travel.
Re: lists, negation, and quick
On Wed, 14 Jan 2004 09:11:42 -0600
Slavov, Vasil [EMAIL PROTECTED] wrote:
:I am trying to modify the following rule from the example
:provided at the end of the packet filtering section of the
:pf faq:
:http://openbsd.org/faq/pf/filter.html
:
:block return in quick on $int_if proto tcp from ! 192.168.0.15 \
: to $int_if port ssh flags S/SA
:
:I want to put a list of IPs that should be able to ssh to the
:int_if (by substituting ! 192.168.0.15 with $admin and
:declaring admin = { !10.5.5.5, !10.4.4.4 } Unfortunately,
:it looks like because of the quick, this doesn't work (and the
:quick is needed because of the following pass rules). Moving
:this block rule after the following pass rules didn't help. Is
:there something obvious that I am missing?
:
:Thanks,
:Vasil
:
PF generates the following rules from that statement:
...
block return in quick on $int_if proto tcp from ! 10.5.5.5 \
to $int_if port ssh flags S/SA
block return in quick on $int_if proto tcp from ! 10.4.4.4 \
to $int_if port ssh flags S/SA
...
So it ends up blocking everything. I think you want to use a table for
negation lists.
Err, now that I read your rules, I think the following would work better:
...
block return all
pass in on $int_if proto tcp from { 10.5.5.5, 10.4.4.4 } \
to $int_if port ssh flags S/SA
...
(I assume you want only 10.5.5.5 and 10.4.4.4 to ssh into this machine)
--
Endless Loop: n., see Loop, Endless.
Loop, Endless: n., see Endless Loop.
-- Random Shack Data Processing Dictionary
synproxy and dualstack (but only one of them is listening)
I know I'm doing something (semi) silly, but this might be considered a bug. My mail server has both IPv6 and IPv4, and most everything is dual, except for pop3. If I enable synproxy on that server, it seems to hang. I believe what it does, is my client connects to PF, it does the three-way-handshake, then PF tries to connect to the server. Normally this would be good, except that pop3 isn't listening on the IPv6 address that the hostname resolves to. (OpenBSD tries IPv6 first, then IPv4.) Without synproxy, the client attempts to connect to the server, gets denied, and fails-over to IPv4. With synproxy, it just stays on the IPv6 address, but nothing is listening. Is this expected behaivor? Am I just being silly? # sudo pfctl -sr pass in proto tcp all synproxy state # -- Nature is by and large to be found out of doors, a location where, it cannot be argued, there are never enough comfortable chairs. -- Fran Leibowitz
Re: Source Tracking in PF
On Mon, 15 Dec 2003 00:23:58 +
Ryan McBride [EMAIL PROTECTED] wrote:
:I just committed code which adds support to track stateful connections
:by source IP address. This allows a user to:
:- Ensure that clients get a consistent IP mapping with load-balanced
: translation/routing rules
:- Limit the number of simultaneous connections a client can make
:- Limit the number of clients which can connect through a rule
:
:As always, the more people who test this and provide feedback, the
:happier I am. Read below for details.
:
:-Ryan
:
:
:
[snip kick ass syntax]
I was wondering if there was a way to use similar rules with ALTQ. E.G.
Evenly split a queue for each source-ip on a /24. Allow each to use unused
bandwidth, but guarantee each gets a fair percentage (in this example,
each ip gets 6k/sec, and can borrow). Something like:
...
altq on $ext_if bandwidth 2Mb cbq { emp, serv, dflt }
queue server bandwidth 15%
queue emp bandwidth 80%
queue dflt bandwidth 5% cbq(default)
pass out on $ext_if from 192.169.1.0/24 to any keep state queue emp (
source-split)
(source-split doesn't exist, but I made it up, to be a semi-reasonable
place for the syntax)
Thanks for the great work!
--
Job Placement, n.:
Telling your boss what he can do with your job.
Re: pf with any l7 patches or ability?
You can look at ftp-proxy. This sort of thing won't enter the kernel, but you can write userland programs to take care of them. On Wed, 5 Nov 2003 10:47:22 -0600 Nick Buraglio [EMAIL PROTECTED] wrote: :I'm looking for anyone that knows of a bsd project that does something :similar to to the Linux Layer 7 filter project. Details found here: :http://l7-filter.sourceforge.net/ I'm more or less hoping that someone :has a *BSD project that can classify packets based on application data :in the connections they belong to or that there is a patch for pf to do :this. Is there anything in the works that anyone knows of? : :nb : -- Nothing takes the taste out of peanut butter quite like unrequited love. -- Charlie Brown
Re: PF, ALTQ on Bridge?
Works as well as I can tell. I use it on an invisible firewall, ADSL 1.5Mb down/ 256Kb up. I can do an ftp upload and download to my ISP, and still browse with little to no delay. =) On Tue, Mar 18, 2003 at 07:24:17AM +0100, Marc Balmer wrote: : Gentlemen, : : does ALTQ perform well (if it works at all) on a bridge used as : firewall? Is there anything to care of of in a bridge environment? : : Regards, : Marc :
