Re: feature request
On Wed, Oct 31, 2007 at 04:14:55PM +0300, Guntis Bumburs wrote: > On Wednesday 31 October 2007 13:52:15 Stuart Henderson wrote: > > On 2007/10/31 14:02, Guntis Bumburs wrote: > > > It would be nice if there was a knob to mark some rules "skip on high > load" so > > > they would be skipped to avoid congestion. > > > > So, when the system is already busy, it has to do extra processing > > to figure out which rules to use? H... > Maybe it could be added in rule like: > pass in log quick "this_rule_can_be_skipped" on $ext_if proto tcp > so if the system is busy pf can skip all the rules (or 1 by 1 ) witch > contains "this_rule_can_be_skipped" option? In case of congestion pf skips ALL rules, so you should be fine ;) Now that 4.2 is out, just give it a try ... Can
Re: linux/iptables/proxy arp to pf/redundant firewall
On Fri, Oct 26, 2007 at 01:59:57PM +0200, [EMAIL PROTECTED] wrote: > so u said that u could inject bad things on some level to give trouble and > shake > on stp ? This is right, you can have fun with most L2 protocols out there check out http://www.yersinia.net/ for instance. > Selon Henning Brauer <[EMAIL PROTECTED]>: > > > * Russell Fulton <[EMAIL PROTECTED]> [2007-10-25 10:09]: > > > Henning Brauer wrote: > > > > so get a little transfer net and make your upstream adjust his routes > > > > > > > > otherwise you need a bridge indeed, but you really want to avoid that > > > > if you have a chance to go for regular routed with carp etc. > > > we also run redundant bridges -- we have two physical paths to our ISP > > > only one of which is ever in use. We have bridges on both these link > > > and use pfsync to share state. The network uses STP to fail the traffic > > > between the links. Works well for us. > > > > I have never said it does not work. Heck, bridge & (r)stp on OpenBSD > > are probably better than on most OSes out there. > > BUT: I hate bridges. They make debugging really darn hard, and come > > with their own set of problems. (r)stp you cannot run in any remotely > > secure fashion without filters on the switches (to be honest, you need > > the same for carp, but there it isn't THAT a disaster because carp uses > > some crypto, (r)stp does not) > > > > -- > > Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] > > BS Web Services, http://bsws.de > > Full-Service ISP - Secure Hosting, Mail and DNS Services > > Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam > > >
Re: firewall is too slow
On Mon, Oct 08, 2007 at 11:50:14AM -0700, Florin Andrei wrote: > (originally posted on openbsd-misc, but then I figured this list might > be a better place for this question) > [snip] > > Seems like a bad network driver, because of the amount of interrupts, > but I'm not sure. Any suggestion is welcome. Try -current, the latest snapshot for instance. There are large improvements in network stack performance.
Re: states handling
On Fri, Sep 21, 2007 at 11:55:36PM +0800, Ilya A. Kovalenko wrote: > >>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 ? It is little a bit different than that. A state also has a 'direction' associated with it. So, a state matches either incoming or outgoing traffic. As long as the direction matches, the interface does not really matter. Sometimes, rarely, you have to enforce the interface (usually only useful for IPSec (enc0) traffic) this is what the ifbound states (check pf.conf man page) are for. To summarize, you need two states to forward a traffic. The ruleset is traversed twice. First at the inbound interface, second at the outbound interface. Once the states are created, no more rule lookups are done for this particular connection. Some people use: pass out all keep state at the start and filter the inbound traffic (this would allow connections originating from the firewall itself though) For most cases, you can get away with not specifying a direction and an interface. An exception is NAT and Redirection where you have to use rules for both the original and transformed traffic. Keep in mind that address translation is done before matching rules. NAT changes the source and always done at the outgoing interface. RDR changes destination, at the incoming interface. > >> Preferred version, because it does not affect queueing > > I think you'll find the complication comes from queueing. > > hell, yes ... states vs queueing ... but it's another story Actually, once you are comfortable with states, queueing is very flexible and powerful. Can
Re: altq priq Anomaly
On Wed, Aug 01, 2007 at 12:55:15PM +0100, Stuart Henderson wrote: > On 2007/07/30 17:33, Can Erkin Acar wrote: > > > > The problem with this diff is that it assumes an ADSL link. > > While 'vcmux' is obviously ADSL terminology, I assume > > having 'pppoe' or 'bridge' would confuse others trying to > > use non-adsl pppoe connections or even real bridges. > > That's a very fair point. I was aiming for a balance of accuracy > and simplicity with the keyword names, and might have gone too far > in the direction of simplicity (though the listing in the manual > is done in more detail). > > > While altq is not my area, I think the diff would be > > more useful if it allowed an 'overhead' and a 'scale' > > to be set on an interface. You could then document suitable > > values for commonly used setups (pppoe/vcmux/whatever). > > There are a finite number of adaptations which would be really useful, > so I think that adds unnecessary complexity to the configuration > language, and it's easier to see what's going on when this is expressed > directly in C than by listing magic numbers in an already-long manual > page. With the framework in place it's simple to see where additions > should go. I am really not sure about this. I would prefer to pass the 'magic' parameters to the kernel, and put the tables into pfctl. That way the kernel and pfctl do not have to match exactly, and you could fine tune in userland, without changing the kernel. > How would you feel about it with more descriptive keywords? Descriptive keywords would be better, but see the above comment. This way you can do both.
Re: altq priq Anomaly
On Fri, Jul 27, 2007 at 06:53:27PM -0600, Daniel Melameth wrote: > On 7/22/07, Daniel Melameth <[EMAIL PROTECTED]> wrote: > > On 7/22/07, Stuart Henderson <[EMAIL PROTECTED]> wrote: > > > On 2007/07/20 15:20, Daniel Melameth wrote: > > > > then go back to the broken behavior sometime later. A reboot of the > > > > box or > > > > removing altq is the only way to resolve the issue, temporarily. I've > > > > tried > > > > both priq and cbq, adjusting tbrsize, recompiling the kernel with a > > > > higher > > > > HZ value and using different hardware and different Internet > > > > connections, > > > > but the issue persists. > > > > > > Try a snapshot, i386 moved to the new timecounter code after 4.1. > > > > > > Though I note there is also an XXX about variable cpu frequency (in > > > sys/altq/altq_subr.c) which might affect you if you adjust cpu speed > > > (manually or by apmd). > > > > > > > Full detail on the issue is available from my gnats post at > > > > # Attempt to account for overhead of RFC 1483 bridging, ATM, PPPoE and > > > > TCP > > > > > > For this you might like to try a diff of mine and report back > > > (http://spacehopper.org/openbsd/altq_tbradapt.diff). > > > It won't help the other problem though. > > > > Thanks for taking the time to reply. I can't readily do a snapshot > > now, but since I am using apmd, I'll try this avenue first and see > > what happens. I also went ahead and incorporated your diffs into my > > currently running 4.1-stable and it appears to be working quite well, > > but I'm not certain if I'm piloting these changes the correct way--so > > if there's an ideal way you'd recommend piloting this, let me know. > > Regardless, I'll monitor the result of these diffs this week and give > > you a heads up at the end of the week. > > Stuart, > > I did some simple piloting of your diffs and they work quite nicely. > The details: > > Without altq, I get a fairly consistent roundtrip latency of 58ms to a > known good host when there is no congestion--and when the upstream is > saturated, latency to the same host goes up to ~220ms. If I use altq > without your diffs and specify my maximum upload bandwidth of 896Kb, > as expected the overhead of PPPoE tramples this and I still get ~220ms > under saturation even with a high priority queue. In order to get > decency latency in this case, I have to artificially estimate a > bandwidth of ~716Kb--and this provides for a high priority queue > latency of ~68ms while saturated, which is pretty good. > > With your diffs though, not only do I get ~68ms for a high priority > queue while using a bandwidth of 896Kb on a saturated connection, but > my maximum upload speed is, consistently, a bit higher as well when > compared to using a bandwidth of 716Kb without your diffs. I > continued to pilot your diffs further by seeding and downloading > multiple torrents simultaneously--to more heavily expose small TCP > ACKs to the stream--and I continued to get these consistently good > results. > > I have been using your diffs for almost a week now with nary an issue. > So, my next question is: > > HOW DO WE GET YOUR GREAT DIFFS INTO -CURRRENT OR A SNAPSHOT? The problem with this diff is that it assumes an ADSL link. While 'vcmux' is obviously ADSL terminology, I assume having 'pppoe' or 'bridge' would confuse others trying to use non-adsl pppoe connections or even real bridges. While altq is not my area, I think the diff would be more useful if it allowed an 'overhead' and a 'scale' to be set on an interface. You could then document suitable values for commonly used setups (pppoe/vcmux/whatever).
Re: Squid 2.6 transparent proxy with pf
On Thu, Dec 21, 2006 at 02:39:50PM +, Stuart Henderson wrote: > On 2006/12/21 15:29, Dominik Zalewski wrote: > > In this article squid is running on the same machine as OpenBSD firewall. > > In > > my case I have squid running on different machine connected to LAN > > interface. > > My question is can redirect traffic on $int_if to another machine connected > > to the same interface? Does this rule is corrrect ? > > No, you can't redirect back out the interface the packet came from. > Maybe vlans could help, if there are no spare physical interfaces. > Or you could run a small transparent proxy (e.g. tinyproxy) on the > firewall and have that use $squid as a parent. unless you nat the connection back, but it is an ugly solution see the pf guide. > > rdr pass on $int_if proto tcp from any to any port 80 -> $squid port 8080 > > Even if you arrange $squid to be on an interface other than $int_if, > I don't think this will work: iirc Squid needs to query /dev/pf for the > untranslated addresses; in that case you need route-to on the firewall > and fwd -> 127.0.0.1 on the proxy. squid needs to query /dev/pf only for HTTP/1.0 connections with no Host: header. Otherwise, it will happily use the Host: header to connect to the remote server.
Re: Squid 2.6 transparent proxy with pf
On Thu, Dec 21, 2006 at 03:29:51PM +0200, Dominik Zalewski wrote: > On Thursday 21 December 2006 15:04, Peter N. M. Hansteen wrote: > > 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 > > In this article squid is running on the same machine as OpenBSD firewall. In > my case I have squid running on different machine connected to LAN interface. > My question is can redirect traffic on $int_if to another machine connected > to the same interface? Does this rule is corrrect ? > > rdr pass on $int_if proto tcp from any to any port 80 -> $squid port 8080 > > pfctl doesnt complain about nothing but its simply doesnt work. This is reflecting a connection back to the same interface The squid proxy tries to reply to the sender, bypassing the firewall. The sender resets the connection since it did not send a packet to the proxy in the first place. This is all discussed in the pf guide: http://www.openbsd.org/faq/pf/rdr.html#reflect with different ways to solve it. Can
Re: OpenBSD ADSL connection problem
On Wed, Nov 15, 2006 at 04:22:10PM +, [EMAIL PROTECTED] wrote: > Hello, everyone! > > I'm not sure, if it is the good forum or not where I can > post my problem, but I hope there is some people who met > similar problems or have some good instructions as a > solution. Sorry for a long letter. [snip] > But the NAT won't work with kernel pppoe driver because of > the difference of MTU(1500-ethernet/1492-ADSL), and I > coudn't access the Internet from the local network. I > rewrite the pf.conf according the pppoe(4) manual, and the > MTU of the ethernet cards with ifconfig, but NAT didn't work. It does check the MTU/MSS ISSUES section of pppoe(4) manual page easiest way is too scrub using pf.
Re: pf "default deny" compile-time option?
On Sun, Jul 16, 2006 at 07:02:00PM -0500, Travis H. wrote: > On 7/15/06, Ryan McBride <[EMAIL PROTECTED]> wrote: > >Root can do stupid things which compromise security. Obfuscation or > >needles complexity in an attempt to protect yourself from the root > >account will only make your system less secure. > > If every ruleset needs to put a rule in to default to blocking > packets, then that's needless complexity to me. No, needless complexity is a compile time option that makes it impossible to know whether a given installation needs the block rule or not. > >Because the /etc/rc ruleset is only temporary, and quite small, I don't > >see the point in making performance-related changes to it (particularly > >performance-related changes that one would have a hard time measuring > >the effects of) > > I doubt it could hurt. > > >> and make some allowance for DHCP. > >DHCP uses bpf(4), and is unaffected by pf rulesets. > > Ah, learn something new every day. > > I suppose the outbound packets are passed by the ruleset, so it makes > no difference that they have a SRC IP of 0.0.0.0... packets are sent using bpf(4) so ruleset does not really matter. Can
Re: PF inadequacy: queue download
On Sun, Apr 30, 2006 at 08:22:51AM -0700, [EMAIL PROTECTED] wrote: > I don't think time spent developing PF or ALTQ could be better spent > developing something other than download queueing. Everyone here seems > to agree it's PF's worst deficiency. Intresting definition for "Everyone". It seems the definition does not include the developers. If you can not live without "download queueing" you can always: 1. Write and submit a patch 2. Fund a developer to do the work for you. 3. Go run something else. I guess you would get bored after a while and choose #3. Feel free to surprise me though. Note that "unending trolling on the mailing lists" > I'm thinking perhaps there's some messy hack I can come up with using > virtual interfaces, does anyone have any ideas? Not that I know of. > > and there are 'lots of people' that care deeply about this > I said lots of people *here*, and there aren't close to 40 here, and > $500 is very steep for an extra box which has to do so little, and this > wouldn't require a whole hackathon to code. I'm not sure why you're > being so resistant to a feature request. This might surprise you but OpenBSD does not run on requests, or polls or democracy. If a developer feels that such a feature is intresting/important and have resources to spare, than the feature will be implemented. The best way to get results is to 'shut up and code'. > > By all means, try it. There are more readers (and developers) on the misc@ > > and tech@ lists, so I'd start there. > I posted in misc, but no-one was biting, and I've just sent one to > tech. > > > Stock altq could put token buckets on input interfaces for rate > > limiting purposes, referred to as the "traffic conditioner" (CDNR). > > That capability was removed when the classifier was merged with pf. > > > > Old messages that might be relevant: > > http://www.benzedrine.cx/pf/msg02871.html > > http://www.benzedrine.cx/pf/msg07159.html (bottom) > Interesting, I wonder how difficult it would be to get the > functionality back. Any ideas on why it was dropped in the first place? Input condititioners are different from queues. You would *not* have the same amount of control over the traffic as you would have when using a separate box. Can
Re: viewing pf rules in tcpdump output
On Sun, Jan 15, 2006 at 05:43:49PM -0500, Melameth, Daniel D. wrote: > Peter wrote: > > --- "Melameth, Daniel D." <[EMAIL PROTECTED]> wrote: > > > Peter wrote: > > > > Question: Why does tcpdump show pf rules when I use the pflog0 > > > > interface in combination with the -e switch (link layer)? It's a > > > > fantastic feature but it seems like an odd way to arrive at it. > > > > > > > > rule 0/(match) [uid 0, pid 14885] pass out on fxp0: esp > > > > 192.168.1.1 > 192.168.2.213 spi 0x1 > > > > > > Not only is it a fantastic feature, I'm quite pleased with the > > > design and ability to tools I'm already comfortable with to review > > > packet logs/dumps. How would you do it differently/better? > > > > My comment is about the output not being related to the switch used. > > What does a matching filter rule have to do with the data link layer? > > Guess the devs can comment on that... FWIW, I see this as the "layer > two" equivalent of pflog and find this far more useful, in this > capacity, than MAC addresses. Also note that pf only does IP filtering, and does not even have access to the ethernet header (MAC addresses etc.) of the packets.
Re: viewing pf rules in tcpdump output
On Sun, Jan 15, 2006 at 04:19:10PM -0500, Peter wrote: > > --- "Melameth, Daniel D." <[EMAIL PROTECTED]> wrote: > > > Peter wrote: > > > Question: Why does tcpdump show pf rules when I use the pflog0 > > > interface in combination with the -e switch (link layer)? It's a > > > fantastic feature but it seems like an odd way to arrive at it. > > > > > > rule 0/(match) [uid 0, pid 14885] pass out on fxp0: esp 192.168.1.1 > > > > 192.168.2.213 spi 0x1 > > > > Not only is it a fantastic feature, I'm quite pleased with the design > > and ability to tools I'm already comfortable with to review packet > > logs/dumps. How would you do it differently/better? > > My comment is about the output not being related to the switch used. What > does a matching filter rule have to do with the data link layer? The pflog0 interface is not a physical interface. The 'datalink layer' *is* the pf rule that generated the log. So it really makes sense, and furthermore, it is a nice and clean way of adding this extra information to the bpf packet dumps. Can
Re: ftp server behind OpenBSD PF, I'm almost mad
On Mon, Jan 09, 2006 at 04:56:27PM +0100, MK wrote: > Hello all > > I can't still solve my problem. I have LAN which is connected to the > internet through OpenBSD's PF NAT. On OpenBSD gateway runs main ftp server > which is accessible from internet and also from LAN. But one computer in my > LAN is FTP server too and I need to make it accessible for internet users. > > I hoped that ftpsesame can help me, but I'm not able to make my > configuration work. > > > MS FTP server ( port 21, private IP ) -- OpenBSD NAT ( FTP server, port > 21 ) internet - ( NATs ) clients > > So what I did? As I mentioned above FTP server on OpenBSD works with > ftpsesame perfectly. ftpsesame is listening on port 21 of external > interface and all clients from internet can reach it even if they are > behind NAT. ftpsesame does NOT listen on any port. It uses bpf to look at packets on the wire, so it has no control over the data as you have found out. Try pftpx instead, which already replaced ftp-proxy in -current and use the reverse mode. Can
Re: Pftpx & Bridge?
On Mon, Jan 02, 2006 at 03:06:33PM +0100, Henrik Bro wrote: > Hi :) > > I am a little confused about Pftpx / Ftpsesame, and I hope someone can help? Both are written by the same author, Camiel. > > Is Pftpx replacing Ftpsesame ? I do not think so, although pftpx is now in the base distribution, replacing the old ftp-proxy. > And if so, does Pftpx support PF in bridge-mode? you can run pftpx in bridge mode, I suppose, but you will need an IP on the bridge Ftpsesame is better suited to ip'less bridges. > Best regards & happy new year to you all, > > Henrik Bro > >
Re: Syntax errors in pf.conf
On Saturday 10 December 2005 01:55, ed wrote:
> On Fri, 09 Dec 2005 16:14:25 -0500
>
> Forrest Aldrich <[EMAIL PROTECTED]> wrote:
> > rdr on $ext_if proto tcp from !, !, ! any \
> > port { $tcp_services } tag INET_DMZ -> $server
>
> rdr on $ext_if proto tcp from { ! , !, ! } to \
> any port { $tcp_services } tag INET_DMZ -> $server
and note that this is equivalent to:
rdr on $ext_if proto tcp from ! to \
any port { $tcp_services } tag INET_DMZ -> $server
rdr on $ext_if proto tcp from ! to \
any port { $tcp_services } tag INET_DMZ -> $server
rdr on $ext_if proto tcp from ! to \
any port { $tcp_services } tag INET_DMZ -> $server
which is probably not what you want.
you could use something like:
no rdr on $ext_if proto tcp from to any port { $tcp_services }
no rdr on $ext_if proto tcp from to any port { $tcp_services }
no rdr on $ext_if proto tcp from to any port { $tcp_services }
rdr on $ext_if proto tcp from any to any \
port { $tcp_services } tag INET_DMZ -> $server
which has the effect of preventing the redirection and tagging
from IPs inside any one of the three tables.
Can
Re: rdr not redirecting when target is localhost
On Saturday 08 October 2005 17:00, Graham Toal wrote: > This is my second adventure with pf. The first was setting > up spamd on a system with an IP - not the preferred solution > but one that was forced on me at the time because I didn't > have physical access to the mailserver in a way that would > allow me to put a transparent bridge in front of it. Now I do, > and so I'm upgrading our greylister to use transparent bridging > - but I've hit a problem which has driven me crazy for 2 days > now but which I'm hoping will be obvious to the folks here... [snip] > If you can give me a known working pf file for the above configuration > and it *doesn't* work, I need pointers on where to look elsewhere > for the problem, because I'm all out of ideas. Let's just say > Google is no longer my best friend :-) I think I've read every > pf page on the net... You obviously have not searched enough. For instance: http://marc.theaimsgroup.com/?l=openbsd-misc&m=108089194621750&w=2 explains how you can redirect connections transparently to ftp-proxy and why you need an IP on the bridge if you use userland proxies. Can
Re: rdr pass, max-src-conn
On Wed, Sep 07, 2005 at 07:37:04PM +0100, ed wrote:
> On Wed, 7 Sep 2005 20:25:54 +0200
> Daniel Hartmeier <[EMAIL PROTECTED]> wrote:
>
> > > rdr on $ext_if proto tcp from any to 1.2.3.4 port 80 -> 10.10.10.10
> > > pass on $ext_if proto tcp from any to 1.2.3.4 port {80,3389}
> >
> > Packets will have their destination address replaced with 10.10.10.10
> > when filter rules are evaluated (translation always happens first).
> >
> > So the pass rule needs to be "to 10.10.10.10" instead of "to 1.2.3.4".
>
> Thanks I'll give this a go. Is there much chance of the two rules being
> combined to a single rdr pass ( max-src-conn etc ) in the future?
You can use tags for that:
rdr on $ext_if proto tcp from any to 1.2.3.4 port 80 tag MYTAG -> 10.10.10.10
pass on $ext_if proto tcp tagged MYTAG keep state
The pass will match the rdr rule exactly and you can specify any options there.
Can
Re: Question/suggestions about tftp
On Mon, Apr 18, 2005 at 02:09:12PM -0400, Jason Murray wrote: > I'm trying to set up a tftp server to host the configs of some PIX > boxes. The PIXes and the tftp server are separated by a pf box. And > before anyone gets smart and says "why not replace the PIXes with PF" > that's a non-starter. I'd love to, but it ain't going to happen. > > Anyway onto the the problem. I see the tftp traffic pass in: > Apr 18 13:46:59.438588 rule 23/0(match): pass in on de3: > 172.17.16.250.1034 > 192.168.42.20.69: 32 WRQ "wsg-conf-200504180" [|tftp] > Apr 18 13:46:59.438727 rule 25/0(match): pass out on xl0: > 172.17.16.250.1034 > 192.168.42.20.69: 32 WRQ "wsg-conf-200504180" [|tftp] > > I see the daemon start from inetd and accept the connection. > > Then I get this: > Apr 18 13:46:59.445133 rule 0/0(match): block in on xl0: > 192.168.42.20.34472 > 172.17.16.250.1034: udp 21 (DF) > > Two questions: > 1) is this "normal" tftp behaviour? I've not fooled around with it > before. I would have expected a trivial file transfer protocol to reuse > the existing sockets. Yes this is the normal, braindead tftp behaviour. > 2) any suggestions on how to adapt the rules to deal with this? > Obviously keep state is not enough, but I'm sure this has been solved > before. Hm, if you are running PF on the tftp box, you can match the outgoing packets as 'user _tftp' If your PF box is separate, you would have to use a userland tftp proxy (no such thing exists afaik) or something like pass from $tftp_server proto udp port > 1024 to ... Can
Re: traffic leaking out on PPP connection
On Thu, Nov 25, 2004 at 07:46:30PM -0500, Peter Matulis wrote: > --- "Ilya A. Kovalenko" <[EMAIL PROTECTED]> wrote: > > These hosts, probably, infected w/ "Lovesan" (aka "MS-blast") virus. It > > scans networks for vulnerable Windows boxes to infect. > > > > but you, should see it as incoming requests, than, your host replys. > > I do get, like everyone else, incoming requests due to the reason you give > but this is the only > port my firewall is responding to and I have no idea why except the > hypothesis that it is due > to some PPP tunneling being done by my ISP. Have you bloccked udp in addition to tcp ? If so, what you are seeing is not 'replies' but virus/worm activity from *within* your internal network, scanning hosts outside. > Furthermore, I went to the Shields Up! site at > https://grc.com/x/ne.dll?bh0bkyd2 and it scanned > my IP and did not report *any* ports open. This is what I should expect. Well, without going into another grc debate, you should know that such port scanning over the internet can be quite unreliable. Furthermore, they may not be scanning for 135/udp, or the netbios ports might be blocked somewhere else along the way. The best way to go is to start from a default deny policy, and open only what you require. Can
Re: bridge tagging limits?
On Thu, May 27, 2004 at 04:56:41PM -0400, Jim Zajkowski wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > Does anyone have any experience with the number of rules a bridge can > handle? We're thinking about how our wireless network policy, and we'd > like to filter by MAC -- allow connection we know about (with pf) and > redirect everyone else into a "please call this number" web page. I'm > concerned about pushing 500 or more rules onto a bridge just to tag > which MACs we know about versus which we don't. bridge rules are stored on a linked list and evaluated for every packet thus having many rules will definitely affect performance. Although you should be able to evaluate the performance easily within your environment. > University environments can be so interesting. :-) :)
Re: Things pf can't do?
On Wed, May 19, 2004 at 12:34:52PM -0400, Dave Anderson wrote: [snip] > There seem to be some things one might reasonably want to do which are > not practical with pf; in particular, I (being paranoid) would like to > drop any incoming packets which have the loopback address as their > destination address -- but I also need to redirect some incoming packets > to the loopback address (e.g., for spamd and ftp-proxy). Since only the > translated addresses are available to the filter rules, the only way to > do this appears to be to use the 'pass' option on the redirection rules > -- but this means that all of the other sanity-checking I do in the > filter rules must also be squeezed into each redirection rule (which not > only is awkward but probably isn't possible, since they're most likely > too complex to express that way). One practical solution is to tag with the rdr rule, and check the tag instead of the destination address in the pass rule. Can
Re: squid+pf+transparent bridge
On Mon, May 17, 2004 at 03:19:25PM -0700, Bryan Irvine wrote: > do you have a "pass" line as well? > > Follow these directions closely. > > www.benzedrine.cx/transquid.html > > --Bryan In addition to this, since you are using a bridgeyou will have to route the redirected packets to the loopback interface in the related pass rule. Search the archives for details.
Re: Borrowing in OpenBSD 3.3
On Thu, May 06, 2004 at 09:13:52AM -0700, Alex Berdan wrote: > Hello, > I have read the lists and I found somebody speaking > about this Borrowing not working but there is no > conclusion about that! > I'm running OpenBSD 3.3 and as the other guy I'm > trying to do borrowing which is not working as > expected (the way that is described in the man). > > Is this already fixed in the OpenBSD 3.5? May be I > should plan an upgrade in that case. Many things changed since 3.3 and I am pretty sure borrowing works in 3.5. Since 3.3 is no longer supported you should plan an upgrade to 3.5-stable in any case. Csn
Re: RDR and transparent filtering.
On Mon, Apr 12, 2004 at 04:09:24PM +0200, Mario Lopez wrote: > Hi, > > I have the following problem, I actually have a dual bridge configuration > (one machine with 4nic's, two filtering bridges), one of the bridges is the > one that is between all my class C network and Internet connection, my > problem is that I would like to redirect some of the IP's on the class C > network to a Squid proxy for transparent proxy (the proxy is in another > machine with IP two which I have connection through a fifth nic connected > to a switch with other servers). I have correctly configured squid for > normal proxy support (if I specify proxy on browesers it all works > flawlesly) the problem is that I dont seem to get the correct rule for > redirecting and I am starting to think that transparent bridge filtering > has something to do. > > I am using the following rdr rule: > > rdr on $wan_ext_if proto tcp from 10.0.0.1 to any port 80 -> a.b.c.d port > 3128 > > $wan_ext_if is one side of the filtering bridge (I have tryed both sides of > the bridge anyway), machine a.b.c.d is reachable from the bridge no problem > on that, I can telnet the machine perfectly and seems correct. > > Any clue on where the problem might be?. failure to search the archives? :) http://marc.theaimsgroup.com/?l=openbsd-misc&m=108089194621750&w=2 http://marc.theaimsgroup.com/?l=openbsd-pf&m=107022940206139&w=2 Can
Re: PF block arp dhcp requests?
On Fri, Feb 13, 2004 at 01:55:07AM -0800, Jason wrote: > I see, so if dhcpd and pf weren't sharing the same interface, then I wouldn't > have this problem. > > I guess limiting dhcpd wouldn't be the best thing, but improving pf. Is > anyone working on adding such a feature to pf to make it block these kinds of > requests? Seems like it'd be helpful. Otherwise, seems like that's somewhat > of a security hole. As Daniel pointed out, not filtering bpf is a design decision. When an application needs to use bpf, that means, it has requirements beyond normal ip-networking capabilities, so bpf filtering would require a different kind of interface/syntax, and would not really mix well with pf. Given that decision, we are aware of the risks of bpf, and are actively working on reducing these risks. The bpf interface was recently made safe for use in non-privileged programs, and as a result pflogd and tcpdump both run privilege-seperated in -current. Work is in progress about making dhclient and dhcpd privilege seperated. Can
Re: PF block arp dhcp requests?
On Thu, Feb 12, 2004 at 10:36:27PM -0800, Jason wrote: > Hi, > > I'm new to the list, and fairly new to OpenBSD (installed maybe 6 months ago). > Anyway, I have a question. Is there anywhere to get PF to stop arp requests > from passing through it? The problem I'm having is dhcp requests from > Windows XP are squeezing by. dhclient on Linux seems to not work (which is > good). > > Here's my setup: > > I have two interfaces, rl0 and rl1. rl1 is my wireless. rl0 is my internal. > I have dhcpd listening on both interfaces. My test pf rules are: > > block in all > block out all > > So nothing should get in or out. period. right? Well, when I do an > ipconfig /renew on Windows XP (wireless), it gets an IP address from dhcpd! > And I know it came from my sever because looking at /var/log/daemon confims > it (plus it's the only one the network). Is this the expected behavior? Or > am I missing something here? this is the expected baheviour. > I did a tcpdump on rl1, and it was just a bunch of mac addresses talking back > and forth. This is exactly how dhcpd sees those packets. it uses bpf, just like tcpdump to captures packets from the interface. This is why pf is unable to block it. You can work around this with dhcp configuration as you already noted. Can
Re: Analyse bandwidth usage
On Mon, Feb 09, 2004 at 12:39:51PM -0500, Hsiao-lung Chang wrote: > Can I use ntop and pf at the same time? > Looks like ntop was not capturing any stats? > you can use ntop on a normal interface. pf does not interfere with bpf captured packets. I do not know what will happen if you try to ntop on pflog0 interface. Even if it works, I believe it will not process pf related information such as rule numbers.
Re: Analyse bandwidth usage
On Mon, Feb 09, 2004 at 04:40:54PM +1100, Craig Bennett wrote: > Hi All, > > I would like to determine how much traffic each rule matches. Ideally I > would like the packet length to appear in the system logs. you can get the same information from per-rule counters, try pfctl -vsr > I haved looked at the man page for tcpdump and it says the for pflog data, > the link-level header shows information from pf. Does anyone know how I can > add a length to this? If you still need this, packet length is already in bpf header, subtract pflog header length if you need the packet length. see bpf(4), pcap(3) for more info.
Re: Problem with log for loopback address
On Fri, Jan 09, 2004 at 03:30:37PM +0100, Laurent Cheylus wrote: > Hi, > > On Fri, 9 Jan 2004, Daniel Hartmeier wrote: > > > Why do you assume those are incoming packets? Might as well be > > _outgoing_ packets, with you being the one sending out packets with > > unroutable source addresses. That would explain all inconsistencies you > > mention, assuming you're passing such packets out or drop them without > > logging. > > > > Run tcpdump with additional flag -e, so you see the MAC addresses > > involved, and compare source MAC address with your own NIC. > > Sorry Daniel but those packets are incoming packets from 127.0.0.1 for my > external interface. Perhaps they are dropped during scrubbing? You can try by removing the scrub rule, or (possibly) increasing the pf debug level: pfctl -x loud and checking the logs. Can
Re: Problem with log for loopback address
On Fri, Jan 09, 2004 at 12:41:45PM +0100, Laurent Cheylus wrote: > > I have a problem with PF logs on OpenBSD 3.4-stable version. > > I received a lot of packets from loopback addresse 127.0.0.1 port 80 : > - - TCP RST packets sent by clients infected by Blaster Worm and use of my > personnal aaddress for IP source spoofing !!! > - - bad configuration from my ISP who routes those packets on Internet, > contrary to RFC 1918 [snip] > No log for loopback address 127.0.0.1 but my PF rules are : > > > sudo pfctl -sr [snip] This information is not complete. Do you also have nat/rdr rules? Are you running a bridge?
Re: Still having trouble with ftp
On Sat, Jan 03, 2004 at 02:53:29PM -0500, stan wrote: > > > > > Jan 3 09:24:31 koala ftp-proxy[22750]: xfer_data (server to client): failed > > > (Connection reset by peer) with flags 00 > > > Jan 3 09:24:39 koala ftp-proxy[22750]: xfer_data (server to client): failed > > > (Connection reset by peer) with flags 00 > > > Jan 3 09:27:27 koala ftp-proxy[27282]: xfer_data (server to client): failed > > > (Connection reset by peer) with flags 00 > > > Jan 3 09:27:47 koala ftp-proxy[27282]: xfer_data (server to client): failed > > > (Connection reset by peer) with flags 00 > > > Jan 3 12:02:23 koala ftp-proxy[8033]: xfer_data (server to client): failed > > > (Connection reset by peer) with flags 00 > > > > Well, these error messages does not always mean that it is not working. > > It just tells that a data connection is aborted by server or client. > > At least ftp-proxy is receiving connections and (attepmting) to transfer > > data. Only YOU can tell if it works or not. > > Well, I don't expect to get error messages in my /var/log messages when > things are workign corectly. Looking at /var/log/messages of several *nix systems around ... Guess what, there are a lot of non-error messages in /var/log/messages just to inform you about various _events_ > Is that an unreasonable thing to expect from OpenBS/pf? There you are, being hostile again. Why dont you just try to _understand_ what these logs mean? ... xfer_data (server to client): failed (Connection reset by peer) have you read it? It means a data connection is broken. By whom? peer. Hmm, either the client, or the server is closing the connection, probably prematurely. Perhaps I, or another user aborted the connection by ^C or 'stop' button? Some network failure? Whatever. ftp-proxy is just informing you of the event. But I dont want to see it. Perhaps ftp-proxy has a debugging option? man ftp-proxy ... hmm, it does have one, but it is disabled by default I can then redirect ftp-proxy logs to some other file. man syslog.conf There! now I dont need to bother a lot of people with my trivial problems. And I learned a few things too ... See? not too difficult is it? Please try it next time.
Re: Still having trouble with ftp
On Sat, Jan 03, 2004 at 12:52:33PM -0500, stan wrote: > Ok, I thought I had active ftp working from behind my firewall, bit I am > still getting these message in /var/log/messages: You thout it was working? Cant you tell whether it works or not? It is as simple as walking to a client and running your favourite ftp client. I guess Jason Dixon is right, at least _you_ seem to think that we know more about your setup then you do. > Jan 3 09:24:31 koala ftp-proxy[22750]: xfer_data (server to client): failed > (Connection reset by peer) with flags 00 > Jan 3 09:24:39 koala ftp-proxy[22750]: xfer_data (server to client): failed > (Connection reset by peer) with flags 00 > Jan 3 09:27:27 koala ftp-proxy[27282]: xfer_data (server to client): failed > (Connection reset by peer) with flags 00 > Jan 3 09:27:47 koala ftp-proxy[27282]: xfer_data (server to client): failed > (Connection reset by peer) with flags 00 > Jan 3 12:02:23 koala ftp-proxy[8033]: xfer_data (server to client): failed > (Connection reset by peer) with flags 00 Well, these error messages does not always mean that it is not working. It just tells that a data connection is aborted by server or client. At least ftp-proxy is receiving connections and (attepmting) to transfer data. Only YOU can tell if it works or not. Just use your mind to solve problems, you will find out that it is more fun and satisfying that way.
Re: newbie help
On Sat, Jan 03, 2004 at 10:04:32AM -0500, stan wrote: > > > > http://www.deadly.org/article.php3?sid=20020130012631 > > > Thanks, taht's a very useful document! but outdated. Why dont you just start with _the_ reference. The pf faq has a whole section dedicated to ftp: http://www.openbsd.org/faq/pf/ftp.html > I'm working my way throuhg it at the moment, and i have a few questions. > I want to set up to use active ftp, that's what I think I had with ipf. yes, ipf handles active ftp in the kernel, which is actullya bad idea, so pf uses ftp-proxy. > I added teh entry to /ect/services that it discuses. Then it talks about > etc.inetd.conf. I found this entry in mine, which was installed by > default, but commented out, and I had uncomented in an atempt to make > things work. > > 127.0.0.1:8021 stream tcpnowait root/usr/libexec/ftp-proxy ftp-proxy so, you already had the correct entry, and no need to mess with /etc/services too. > So, I comented it back out, and added this: > > ftp-proxy stream tcp nowait root /usr/libexec/ftp-proxy \ > ftp-proxy -n -V -D3 -u ftp-proxy -m 55000 -M 57000 -t 300 no need, remove those and put the original entry back in. > And this is when I started to get puzzled. The next refernce is to a > /etc/nat.conf file. I thought this file was obsoleted with teh move from > ifp to pf. Am I wrong? I don't have one, and man nat.conf doesn't show any > entries for it. yes, what you are reading is an _old_ document. Please use the pf-faq. and you will find that the sample pf.conf already have the rules you need for ftp-proxy there, commented out. Perhaps you need to give a thought to how things work instead of blindly following arbitrary instructions? OpenBSD documentation (FAQ and manual pages) contain everything you need. Just learn to read and understand them.
Re: syslog shows still open?
On Tue, Dec 30, 2003 at 11:43:19PM -0600, [EMAIL PROTECTED] wrote:
> Don't know what I am missing but running scans of a 3.4 stable box (updated
> 12/21) shows udp port 514 open.
syslogd listens keeps udp port 514 open to prevent other programs from
binding. It would not process received packets by default.
> I block by default, added these two rules to
> see if I could make it go away. Pretty standard box with 1 internet
> connection, a DMZ and a lan interface. The Internet interface has ip aliases
> on it for a few IP addresses, removed these as well since it shows on scans of
> the aliased IP's as well.
>
> block in log quick on $all_ints proto { udp, tcp } from any to any port 514
> block in log quick on fxp2 proto udp from any to any port 514
>
> First rule shows it blocking a packet on fxp2, but tcpdump shows it coming
> through, so added second rule and it isn't catching anything after the first
> one thinks it gets blocked.
>
> RULE ACTION DIR LOG Q IF PR K PKTSBYTES STATES MAX INFO
>4 BlockIn Log Q fxp2 udp 2 560 drop from
> any to any port = 514
> 12 BlockIn Log Q fxp2 udp 000 drop from
> any to any port = 514
so, your packets are being blocked, that is nice :)
> vulcan# tcpdump -i fxp2 port 514
> tcpdump: listening on fxp2
> 22:57:52.885387 1.6.0.90.34878 > 1.3.0.81.514: udp 0
> 22:58:35.078369 1.6.0.90.34663 > 1.3.0.89.514: udp 0
> 22:58:41.085093 1.6.0.90.34664 > 1.3.0.89.514: udp 0
tcpdump looks at the interface _before_ pf, so you are seeing packets
before they are blocked. This is normal too.
> ran scans with nessus and nmap, both show udp port 514 open. Turned off Nat's
> and redirects, this did not change anything though. Tried a block all quick on
> internet interface, it still shows it open. Does this make sense to anyone?
> IP address changed let me know if you need to see the whole ruleset.
Ah, how do you define 'open' for udp?
since udp is a connectionless protocol, the scanners _assume_ that it is
open if they do not receive an icmp port-unreachable packet. Your rules
just drop the packet, and do not return anything.
Try 'block return' in your rules
Can
Re: transparent proxy isn't the def gw
On Sat, Nov 29, 2003 at 06:10:06PM +0100, Thelmo Loisio wrote: > On Fri, 2003-11-28 at 18:23, Greg Hennessy wrote: > > > Is your perimeter gateway doing address xlation for source address you are > > using ? > > Don't take me wrong, but... of course nat is working ;) > > My problem is that i don't know why when running in bridge environment > the rdr to 127.0.0.1 doesn't work anymore. because the bridged packets do not actually make it to the ip stack the work around is to add an explicit 'route-to lo0' to your pass rule: for instance: rdr on $int_if from $int_net to ! $int_net port 80 -> 127.0.0.1 port 3128 ... pass in on $int_if route-to lo0 from $int_net to 127.0.0.1 port 3128 Can
Re: ftp-proxy & ALTQ
On Thu, Nov 06, 2003 at 10:36:12AM +0100, Ed White wrote: > Hi, > > I'm wondering if there's a way to let ftp-proxy set the priority queue for > every state it creates. [snip] > The problem is that _passive_ ftp download tcp connections have not fixed > points: no IP and no ports. you can always use 'user proxy' to match connections related to ftp-proxy Can
Re: PF and Snort Working together
On Mon, Oct 13, 2003 at 01:43:37PM -0400, [EMAIL PROTECTED] wrote: [snip] > ... I have seen a number of articles and email stating > that snort see's all traffic before it is ever filtered by PF ... this is true. You can run snort and pf together without problems. Can
Re: syn-proxy & application-level-proxy
On Thu, Sep 11, 2003 at 11:32:28PM +1000, Damien Miller wrote: > On Thu, 2003-09-11 at 23:00, Daniel Hartmeier wrote: > > It would be cool if pf (some time in the future) had someway of passing > packets off to to a userspace inspection process before they were put > out on the wire or delivered locally. The inspection process could > interrogate the packets and tell pf if they were OK. After the userspace > process was no longer interested in the connection, it could > disassociate from it and exit. In a perfect world, the inspection > process would have the ability to modify these packets too (since I am > in wishlist mode, why stop? :) ) > > IIRC Linux netfilter has something like this with its "queue packet for > userspace" functionality. also freebsd divert sockets i think. the problem with this approach is that you loose the stream, and have to inspect individual packets and do stream assembly in userland, or risk trivial attacks related to small or non-aligned packets (whisker had an option to send such streams iirc). I have been dreaming of passing assambled streams through the userland. I have not yet come up with a suitable design though. Can
Re: dup-to to 3rd interface for snort
On Wed, Sep 10, 2003 at 10:50:24AM -0500, Chris Reining wrote: > Why don't you just run a chrooted snort on $ext_if? choose one: a. machines running snort usually have much higher requirements (disk space, cpu, connection to a database?) b. complex processes/services on a firewall is a bad thing c. running snort chrooted does not remove risks associated with the open bpf interface in snort i.e. a potential exploit can still sniff all your interfaces, send arbitrary signals to arbitrary processes etc. > Chris And to answer the original question(s) > On Wed, Sep 10, 2003 at 09:25:37AM -0400, Aaron Wade wrote: > > Hi all, > > I have a 3.3 based firewall, and I am looking at deploying snort on a 3rd > > interface. It seems like dup-to is the best option for this, but I have a > > few questions as to how it works. > > > > How does dup-to work with scrub ? If scrub is reassembling packets, how > > could the IDS pick up a fragmented attack ? It can not. But your internal hosts will not be affected (due to scrub) so there is no problem. If you still want to know if someone _attempted_ a fragmentation attack, you can increase debug level of pf (read -x switch in pfctl(8) ) and check system (firewall) logs. > > > > I have explicit deny rules in place, so I am assuming the following would > > work ? > > > > block log on $ext_if dup-to $IDS all > > > > If that wouldn't do the trick, what would ? > > only the packets blocked by the above rule will be duplicated to $ids if you want other packets, you have to add explicit dup-to statement to the rules/connections you want to inspect. > > The 3rd interface will simply be "up" with no IP and the IDS is active with > > a unidirectional cable connecting the two. Are there any issues with that ? unidirectional? you may have autonegotiation problems with that I have not tried it but you may get away with manually specifying media type and speed on both sides of the cable. why not use a simple crossover cable? > > If anyone has suggestions or comments, I'd appreciate it. > > As to why I am resorting to this..I was denied a mirror port on our switch, a > > tap costs more than I want to spend, and an inline hub is rediculous IMO. > > Thanks, > > Aaron
Re: PF -> tags <- bridge
On Fri, Sep 05, 2003 at 03:16:05PM +0200, Ed White wrote: > On Friday 05 September 2003 13:03, Henning Brauer wrote: > > We also modified the matching so that _every_ matching rule sets the > > tag, not just the last one. > > This means multiple tags for one packet, right ? No, there is only one tag which is replaced as the rules are evaluated. The last matching rule need not attach a tag for a packet to be tagged. Can
Re: another pf question
On Fri, Mar 28, 2003 at 01:14:41AM -0500, [EMAIL PROTECTED] wrote: > Is pf a true 'silent' firewall, not touching the ttl of a packet and thereby > not giving out that the packet has gone through an extra layer to get to the > destination? If it isn't, is there a way to enable such a feature, if it's > yet implemented? You can also use 'block ... return-rst ttl ...' syntax to explicitly specifty the TTL used in the generated RST packets (read pf.conf(5), search for ttl). pf also drops packets with invalid checksums by default (post 3.2) thus preventing another avenue of detection. However, there probably are (or will be) other ways to detect the presence of a 'stealth' firewall so dont just depend on it. Can
Re: pf(4) schemantics
On Fri, Mar 21, 2003 at 06:44:37PM +0100, Srebrenko Sehic wrote: > On Fri, Mar 21, 2003 at 12:50:43PM +0100, Henning Brauer wrote: > > > I'm close to give up on you wrt to that. SOmehow it seems you don't _want_ > > to see why the filtering outbond on an interface is so important. I gave a > > very good example why that is absolutely needed. > > Bla, bla, since traffic can originate from the firewall itself. In a lot of > cases, it doesn't, though. Yeah, tell that to my OpenBSD web/file server and the desktop machine from which I am writing this mail. I have great many reasons to filter BOTH inbound and outbound traffic. And repeat after me: OpenBSD is NOT just a firewall appliance. Also, there are MANY cases where filtering traffic originating from a firewall is needed. Think about application level proxies for instance. Can
Re: pf(4) schemantics
On Thu, Mar 20, 2003 at 06:11:28PM +0100, Srebrenko Sehic wrote: > > Sure. However, if you only "block in all", you will end up in situation > where TCP_RESET for tcp and ICMP_UNREACAHBLE for udp can't get back to the > source. these are automagically linked to the state. As long as you keep state in your pass out rules, RST and ICMP related to the state will always make it back to the source regardless of 'block in all' > Which can make clients 'hang' waiting for a TCP_RESET/ICMP_UNREACHABLE. > > I'll post a ruleset explaining issues I'm having. It _just_ might make > things clearer. that would be nice Can
Re: dump pflog to a database
On Tue, Mar 18, 2003 at 04:43:53PM -0600, Sid Keller wrote: > Is there an easy way to get pflog information into a database? I don't > need for pf to log directly to a database, I would just like to be able > to take data from the pflog file and load it into a database, > specifically a postgresql database. Any ideas or thoughts on how to do > this? * You have to parse the binary logs (not too difficult) or tcpdump ascii output (easier) and fill your database. * In parsing you have to be _very_ careful, pf logs contain potentially malicious data which may try to exploit/disrupt your analysis tools, parsers. See recent vulnerabilities in tcpdump (DoS) ethereal and snort (code execution). * There are a couple of recent threads on www.deadly.org on pf logs read these for more information. Can
Re: pflogging
On Tue, Mar 18, 2003 at 01:59:31PM -0800, Bryan Irvine wrote: > Is there a way to pipe only parts of pf to a log file? Or a different > log file? you can filter rule number, for instance: tcpdump -n -e -ttt -r /var/log/pflog rulenum 73 where 73 is the rule number of the you want to see you can also define more complex filters, see tcpdump(8) for details. You can also use the same filtering expressions to direct matched log packets to a different file by running a different instance of pflogd(8): pflogd -f /var/log/otherlog rulenum 73 Can
Re: source limit
Perhaps this can be implemented in userland? A deamon listening on pfsync could track states/hosts and kills states/modifies rules depending on any criteria you care to define. Better than adding more complexity to the kernel code. Can
Re: pf state issue
On Fri, Mar 14, 2003 at 09:04:51AM -0500, ben fleis wrote: > i hope this is the right forum for asking this question... i imagine it will > have a simple answer :) simple answer : no need to keep state on lo :) simple facts: - these packets are filtered on lo0 twice, one inbound and one outbound - you have 'pass out on lo0 keep state' kind of rule thus the DNS request and reply create distinct 'outbound' states. - for fun and symmetry, add a 'pass in on lo0 keep state' (see simple answer) Can
Re: PF in 3.3-current, ioctl
Since you will be using 3.3, consider anchor rules and tables instead they provide a much better interface to rule/address modifications check the sources for spamd, authpf and pfctl for implementation details. Can On Wed, Mar 12, 2003 at 05:00:48PM +0100, Marc Balmer wrote: > Hi > > I am upgrading my cmd counter measures daemon to 3.3 current. cmd > listens on pflog0 and modifies pf rules through the pf device using > ioctl calls (yes I know, dynamic firewalls are disbutable and open > doors to all kind of DoS attacks...). [snip]
Re: intrusion detection
While pf has no syntax for intrusion detection, it has some nice features that aid in intrusion detection. scrub: makes sure that the intrusion detection system inside the firewall cannot be fooled by fragments and similiar other tricks that would cause hosts and the ids see different packet streams. binary logs: complete packets (within the given snaplength) are logged which can give you more information about the nature of the attacker (eg. passive os detection) and the attack/scan. dup-to: you can redirect packets to a different interface (where IDS listens ?) anchor rules and tables: your IDS can interact with PF to selctively block the attacking hosts. you can find many other creative uses ... Can On Wed, Jan 22, 2003 at 02:35:05PM -0800, Bryan Irvine wrote: > Does pf have a syntax for intrusion detection? > > Id not what do you guys recommend? Nessus? Snort? Prelude? > > --Bryan >
Re: Rule short in pflogd output
a HUP to init only works for /etc/ttys file (see init(8). For pflogd you dont need a reboot. Just kill and restart it manually using whatever options you have in /etc/rc.conf. pflogd will (correctly) resume logging to the same log file even if options such as snaplen change. you might miss a couple of log packets that arrive while pflogd is down but not more than you would lose during a reboot :) Can On Tue, Jan 14, 2003 at 05:47:51AM -0500, Jason Dixon wrote: > > Thank you both, great explanations. A bit OT, but, if I add the pflogd > expression to rc.conf, will a HUP to init also restart pflogd with this > option, or am I forced to reboot for this to take effect? > > -J. >
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 11:12:35PM +0100, Daniel Hartmeier wrote: > See the updated patch in the -current ports tree, it's fixed. Thanks :) > There's no reason to gamble with sanity by trying to backport features, > people running 3.0, 3.1 and 3.2 -release or -stable are supposed to use > the appropriate ports tree. If it worked when 3.1 was shipped, it can > still be built using that ports tree. I wouldn't go insane over trying > to backport all changes and supply one version that compiles with all > old releases. If people can't be bothered with upgrading, why would you > bother delivering them the latest features to compile on their old > systems? :) You are right, too many things have changed between 3.2 and -current. I will probably stop supporting pre 3.3 in later releases of pftop. Can
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 06:52:40PM +0100, Srebrenko Sehic wrote: > On Thu, Jan 09, 2003 at 06:34:13PM +0100, Daniel Hartmeier wrote: > > > > But it would be worth carefully looking at the currently shared modules, > > and sorting all functions and shared globals to into either shared or > > private modules. Whether you put the shared code into a library or just > > link an object file from pfctl is then just a detail. :) > > If we leave out all the technical challenges involved, the real question > is if the pf developers find this idea useful at all? The only way libpf > whould ever be a hit is if it was developed/maintained in the official tree. > Otherwise, libpf maintainer would need to do spend a lot of time > figuring out the changes happening to pf, pfctl, authpf, etc. > > How often do pf(4) structures changes? 5 times a week? IMHO, it would be > a mission impossible to maintain it externally. Right now things are changing too fast. I had to stop working on pftop or risk losing my sanity ;) (Ouch! it is broken again, I will make a new release in a week). I think we need a 'pf version' incremented with api/structure changes. That would really make maintaining portable code MUCH easier. In pftop I only duplicate state/rule printing functions so I have not needed a general purpose library (yet). Though I believe it would be useful if designed/implemented correctly. Can
Re: set block-policy set
OpenBSD is not only the kernel, there are the system binaries apps etc. the faq5 mostly talks about the kernel but gives a few pointers especially the upgrade minifaq: http://www.openbsd.org/faq/upgrade-minifaq.html the release(8) manual page describes the steps you need to compile a new system (then it goes on to describe building release tarballs but this part is not relevant here). On Sat, Jan 04, 2003 at 03:30:22AM -0700, Duncan Matthew Stirling wrote: > Well this is the same steps I've been following, I guess the term > userland is new to me. I generally start off with the > http://www.openbsd.org/stable.html , document then I build a custom > kernel with just the options I want enabled on the box. Little things, > like disabling devices that aren't present in my system, or disabling > devices that I don't use in the system. > > Again, userland is a new term. Though whatever I call it, I'm doing > something wrong. > > Duncan
Re: set block-policy set
http://www.openbsd.org/faq/faq5.html also 'man release' On Sat, Jan 04, 2003 at 02:19:12AM -0700, Duncan Matthew Stirling wrote: > how do I rebuild userland?? >
Re: State table with a rule change
Rule changes do not affect existing states. You have to process each state and decide if you still want it or not. Look at authpf for one way to do it. authpf removes states containing the IP address of the connection it authenticated on exit. Can On Thu, Dec 12, 2002 at 08:11:27AM -0700, Larry Coulson wrote: > If pf has been in operation for a while and a new rule set is loaded what > happens to the states? For example there could be two rules to allow > packets (rule A & rule B) in the old rule set that have just created two > tcp established states (state A & state B) that could naturally time out in > 24 hours. The new rule set just loaded retains rule A but no longer has > rule B. We would like state A to be retained but state B should be removed. > Will this occur? >
pftop broken on -current
pftop failes to compile on -current right now. Daniel Hartmeier kindly provided a patch which can be downloaded from: http://www.eee.metu.edu.tr/~canacar/pftop/pftop.diff The patch is tested by jolan, many thanks. I am having problems (of bandwidth and time) upgrading to -current right now. I will provide an update to pftop and the port in a few days. Can
Re: RFC: dynamic rules
On Mon, Oct 14, 2002 at 04:46:33PM -0400, Mike Frantzen wrote: > > The application has to specify not only the > > complete rule parameters, but has to know _where_ exactly to place the > > rule in the ruleset (beginning, end, after a rule? etc.) > > I'd hope so. I wouldn't want authpf to start placing rules at the end > of my ruleset of mostly quicks. Yes and at present there is no way to tell an application exactly where to place the rule and that is one of the problems I was trying to solve. > > Furthermore, > > the administrator has no control on what rule an application inserts, or > > a way to konw which rules are inserted by an application. > > Configure your app to add a label to the rules if you want to > distinguish them. If an admin has no control over what an application > inserts, why would he run the app? 'control' is the wrong word. I guess 'fine-tune' would have been better. Given the large number of different network configurations, possible rulesets and continuing pf improvements, it is hard for an application to supply reasonable values to all the rule fields. There was no 'user' keyword when I started thiking about this and now there is the altq integration (no I am not complaining). > > To make matters > > more complex, if the application crashes, it may leave permanent rules > > in the ruleset. > > Aha! That is a real issue. The way we had talked about solving that up > in Calgary was to extend proc so rules could be tied to a process. When > the process goes away, it calls back into PF which removes the rules. > Were we talking about that in Calgary or in DC a year ago?? Hell, I > can't remember. Bob was running around in a tizzy with excitement > though (now that was a sight!) I would like to see that (both :) ). > > Now, after all that talk, I should note that, with proper usage of > > static rules (especially the user keyword) most proxy servers would > > never need to insert rules (or can be designed to remove that requirement) > > However there are isolated cases where it would be useful see > > the recent post by Matthew Sweet for instance. That is why I could not > > easily come up with a real world example. > > It is a cool concept, I'll give you that. But I still don't see the > problem you're trying to solve. Thanks, and thank you for the comments. That is exactly the kind of feedback I was waiting for. Although it probably would not matter any more, I have been refining the idea and could not resist posting the final version which is much more intuitive: * all rules including nat/rdr have a optional 'dynamic' flag. * dynamic rules hold a list of (initially empty) instances. * the instances only contain src/dest addr/port filters and redirection information, most of which is optional. * the list is evaluated after the rule matches, the rule acts as a template, refined by the instances. * a dynamic rule does NOT match unless an instance matches. * the applications attach instances to dynamic rules using an ioctl. * the instances expire with time, activation count (or process termination :) ) The result is: * better, consistent syntax. * dynamic rules can now block as well as pass. A real life example - IDS triggered dynamic blacklists with auto expiration: The IDS engine requires two label strings (that could be identical) and adds the suspect IP address to rules identified by the labels. these labels, one for src addr and one for the destination. The IDS needs no configuration about interfaces, protocols and other rule options except for expiration timeouts. The administrator can define the rule template in pf.conf and can block, log, route to another interface or rdr to a honeypot as necessary. # Block all attacks recognized by IDS # same label for src/dest block in all dynamic label_ids or # redirect to honeypot rdr on $ext_if from any to any -> $honeypot dynamic label_ids_src # block all non-redirected packets block out quick on $ext_if from any to any dynamic label_ids_dst Can
Re: RFC: dynamic rules
Sorry for the late reply, I have been really busy last week. On Mon, Oct 07, 2002 at 12:38:09PM +0200, Ed White wrote: > > I will come up with better examples later. promise. > > I'm really interested, because I didn't understand what is the objective ;-) The objective is to allow applications to insert and remove rules dynamically. The present mechanisms for adding/removing rules are too general to be easily used by applications. The application has to specify not only the complete rule parameters, but has to know _where_ exactly to place the rule in the ruleset (beginning, end, after a rule? etc.) Furthermore, the administrator has no control on what rule an application inserts, or a way to konw which rules are inserted by an application. To make matters more complex, if the application crashes, it may leave permanent rules in the ruleset. Now, after all that talk, I should note that, with proper usage of static rules (especially the user keyword) most proxy servers would never need to insert rules (or can be designed to remove that requirement) However there are isolated cases where it would be useful see the recent post by Matthew Sweet for instance. That is why I could not easily come up with a real world example. The rdr/nat rules are more complicated and ftp-proxy, for instance, does not support EPSV requests in non NAT mode because it cannot (easily) add the required rdr rule. However, the rule syntax and semantics has to be worked out for rdr/nat case. > > > This would enable better chaining of chain rules ;) > > Chain... > This word is Linux-related, could we change it ? > Call it a "jump" (infact it jumps a rule). Oops, I have not thought about ipchains! There is no jumping involved, perhaps 'link' would have been a better term or 'temp' for temporary/template or 'dynamic'. Hope this helps to clarify things Can
Re: Activating temporary rules in static pf.conf
You can write a script to automatically generate tour rules file similiar to the one recently announced on deadly.org: http://www.deadly.org/article.php3?sid=20020919022924 Another approach is to modify authpf to add/remove rules based on your requirements. Finally, I have been working on a way to add temporary rules to pf It works by inserting a rule template to pf.conf and later, dynamically specifying rule parameters (src/dest host/port etc.) these specific instances expire based on time and/or activation count. The advantage is that the programming interface is much simpler than authpf way of adding/removing rules, furthermore, they expire automatically. You dont need a cron job to turn remove them later. The disadvantage is that, for normal (non nat/rdr) rules, you can almost always come up with other ways of achieving similiar results like the two alternatives I have already given above ;) Can On Mon, Oct 14, 2002 at 01:08:40PM -0500, Matthew Sweet wrote: > Hello, > >Sorry to bother everyone with this miniscule question. I am trying to > figure out how to add temporary rules to pass traffic for a particular > service? > >What I am trying to do is set up a test ftp server for Internet > customers to use on a controlled basis. A tech would run a command (via > sudo running from a menu-driven script) and enable temporarily the IP > address the customer resides on to test. The IP would stay open for x > hours. I would then have a cron job reset the firewall rulesets to the > default on a pre set time. > >Any suggestions would be appreciated. > > Thanks, > > Matt >
Re: RFC: dynamic rules
On Sun, Oct 06, 2002 at 08:55:39PM +0300, Can Erkin Acar wrote: [snip] > As an example real-life example I can think of (samba) nmbd and net bios > name resolution broadcasts where keeping state does not work but a > small patch to nmbd would ;) OK disregard this example. Although replies to broadcasts are a problem it would not be solved by patching nmbd (what was I thinking !) I will come up with better examples later. promise. By the way, the following change to the chain-rule semantics I described earlier would perhaps be more intuitive: instead acting as a drop rule on a mismatch, continue with the next rule. act as pass on a match (this was what I envisioned in the first place but it got changed during implementation) This would enable better chaining of chain rules ;) Can
Re: RFC: dynamic rules
On Sun, Oct 06, 2002 at 06:29:17PM +0200, Daniel Hartmeier wrote: > Could you post a small rule set example that shows the feature? And > maybe some examples of how a userland tool would use it, and where it's > useful? I'm not entirely sure yet where I'd want to use the chains. :) > Think of a chain rule as a template, refined by an application proxy: A rule like: chain return-rst in on $ext_if proto tcp from any to any port > 49151 \ user proxy keep state label proxy1 can be refined by the proxy application to accept connections only from the client address at a specific port. The proxy only needs to be passed the label 'proxy1' to refine the rule. The following fragment restricts the port and defines expiry time but leaves the src, dst and dport the same as defined in the original chain rule. struct pfioc_chain c; c.chain.src.addr32[0]=htonl(0); c.chain.dst.addr32[0]=htonl(0); c.chain.sport=htons(0); c.chain.dport=htons(port); c.chain.expire=expire; strncpy(c.label, label, PF_RULE_LABEL_SIZE); ioctl(fd, DIOCCHAINRULE, &c); you can use the included test application (which contains almost the same code fragment) to create holes in a rule such as: chain return-rst in on lo0 proto tcp from any to any port 4 >< 5 keep state label proxy1 using test proxy1 40666 30 which creates a hole to port 40666 for 30 secs. for one connection only. As an example real-life example I can think of (samba) nmbd and net bios name resolution broadcasts where keeping state does not work but a small patch to nmbd would ;) While the 'user proxy' restriction is possibly enough for ftp-proxy and further limiting remote address and port may not be necessary, the ftp-proxy needs a rdr (for full EPASV functionality) which can be implemented within the same framework: rdr chain on $ext_if from any to any label proxy2 in this case the application proxy can restrict src/dest ports and specify the redirected host and port. I have not worked out the exact syntax for using rdr with chain, however the redirected ports/hosts should also be restricted: rdr chain on $ext_if from any to any portspec -> $int_net portspec label proxy3 where portspec further restricts the port values specified by the chain rule. Can
RFC: dynamic rules
Hello,
I have been thinking about a method that would allow userland programs
to create dynamic rules. I have come up with the following:
* Create a new rule type called 'chain'. It has the combined syntax of
pass and block. It is parsed and installed as a normal rule and
defaults to block. It must contain a (unique) label.
* Userland programs address the rule using the label, and add their
own 'chain-rules' to the list of chain-rules contained in the rule.
* A chain-rule contains an address/port pair for souce and destination
of the rule. It can also contain fields for any other customizations
that may be needed, including a hit-count and a timeout.
* When a rule with chain action is hit, the list of chain-rules is
traversed and if a match is found, the rule acts as a 'pass' rule.
If there is no match, it acts as a block rule.
* This idea can be extended to NAT/RDR rules by including a chain flag
and labels.
Advantages:
* Admin can completely control the behaviour of the application that
is going to insert the rule.
* Low overhead.
* Application interface is very simple. Labels used in pf.conf are
passed to the application and application performs a single ioctl
with unknown information set to zero. Application needs no further
knowledge of rules or system.
* Chain-rules expire on a hit count or age. Crashed applications do
not leave rules behind.
Disadvantages:
* NAT/RDR does not have labels yet.
* a better name? proxy/extern/dynamic come to mind.
Implementation:
I have attached a draft implementation. It is for tcp and udp only.
chain-rules are one-shot but have expiration timers. I have
also included a test application that adds chain-rules to rule for a
given port.
Comments ?
Can
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.247
diff -u -p -r1.247 pf.c
--- pf.c2002/10/05 21:17:57 1.247
+++ pf.c2002/10/06 15:08:12
@@ -142,6 +142,7 @@ int *pftm_timeouts[PFTM_MAX] = { &pftm
struct pool pf_tree_pl, pf_rule_pl, pf_nat_pl, pf_sport_pl;
struct pool pf_rdr_pl, pf_state_pl, pf_binat_pl, pf_addr_pl;
+struct pool pf_chain_pl, pf_chainlist_pl;
voidpf_addrcpy(struct pf_addr *, struct pf_addr *,
u_int8_t);
@@ -615,6 +616,7 @@ pf_purge_timeout(void *arg)
s = splsoftnet();
pf_purge_expired_states();
pf_purge_expired_fragments();
+ pf_purge_expired_chains();
splx(s);
timeout_add(to, pftm_interval * hz);
@@ -659,6 +661,33 @@ pf_purge_expired_states(void)
}
}
+void pf_purge_expired_chains(void)
+{
+ struct pf_rule *rule;
+ struct pf_chain *cur, *prev;
+
+ for (rule = TAILQ_FIRST(pf_rules_active);
+rule != NULL; rule = TAILQ_NEXT(rule, entries)) {
+ if (rule->action != PF_CHAIN)
+ continue;
+ prev = NULL;
+ cur = LIST_FIRST(rule->chainlist);
+ while (cur != NULL) {
+ if (cur->expire > time.tv_sec) {
+ prev = cur;
+ cur = LIST_NEXT(cur, entries);
+ continue;
+ }
+ LIST_REMOVE(cur, entries);
+ pool_put(&pf_chain_pl, cur);
+ if (prev == NULL)
+ cur = LIST_FIRST(rule->chainlist);
+ else
+ cur = LIST_NEXT(prev, entries);
+ }
+ }
+}
+
int
pf_dynaddr_setup(struct pf_addr_wrap *aw, u_int8_t af)
{
@@ -757,6 +786,46 @@ pf_dynaddr_copyout(struct pf_addr_wrap *
}
void
+pf_chainlist_remove(struct pf_chainlist *clist)
+{
+ struct pf_chain *cr;
+
+ if (clist == NULL)
+ return;
+
+ while ((cr = LIST_FIRST(clist)) != NULL) {
+ LIST_REMOVE(cr, entries);
+ pool_put(&pf_chain_pl, cr);
+ }
+
+ pool_put(&pf_chainlist_pl, clist);
+}
+
+/* assumes label contains space for at least PF_RULE_LABEL_SIZE bytes */
+struct pf_rule *
+pf_get_rule_by_label(char *label)
+{
+ struct pf_rule *r;
+ int n;
+
+ if (label == NULL)
+ return NULL;
+
+ r = TAILQ_FIRST(pf_rules_active);
+ while (r != NULL) {
+ for (n = 0; n < PF_RULE_LABEL_SIZE; n++) {
+ if (label[n] != r->label[n])
+ break;
+ if (label[n] == '\0')
+ return (r);
+ }
+ r = TAILQ_NEXT(r, entries);
+ }
+
+ return (NULL);
+}
+
+void
pf_print_host(struct pf_addr *addr, u_int16_t p, u_int8_t af)
{
switch(af) {
@@ -1605,8 +1674,9 @@ pf_test_tcp(struct pf_rule **rm, int dir
uid_t u
