Re: PF/logging rule number
On Sat, Nov 02, 2002 at 01:53:09AM -0500, Jason Dixon wrote: > Does anyone else think that the ability to log the last matching rule > number (as indexed in 'pfctl -s rules') would be a glorious feature? > This is found in iptables and is a really nice debugging tool. It's already there. Use the "-e" option to tcpdump to get link-level headers when reading from the pflog0 interface. E.g.: tcpdump -e -n -ttt -l -i pflog0 - deej -- Daniel (DJ) Gregor OSU Network Security Group http://www.net.ohio-state.edu/security/
Re: PF/logging rule number
On Sat, 2002-11-02 at 02:02, Jolan Luff wrote: > On Sat, Nov 02, 2002 at 01:53:09AM -0500, Jason Dixon wrote: > > Does anyone else think that the ability to log the last matching rule > > number (as indexed in 'pfctl -s rules') would be a glorious feature? > > the log keyword already does this..? what do you mean? *sigh* I swear, I really do RTFM and Google this stuff. I promise. Sheesh. Thanks, J.
PF/logging rule number
Does anyone else think that the ability to log the last matching rule number (as indexed in 'pfctl -s rules') would be a glorious feature? This is found in iptables and is a really nice debugging tool. -J.
Re: TCP Reflection: Summary
Sorry, one final reply to self. Found the answer, albeit not the one I was looking for, in the pf.conf manpage for 3.2. This information should probably be reflected in OpenBSD's FAQ which describes a typical DMZ setup. "Note that all translation rules apply only to packets that pass through the specified interface. For instance, redirecting port 80 on an external interface to an internal web server will only work for connections originating from the outside. Connections to the address of the external interface from local hosts will not be redirected, since such packets do not actually pass through the external interface. Redirections can't reflect packets back through the interface they arrive on, they can only be redirected to hosts connected to different interfaces or to the firewall itself." -Jason On Fri, 2002-11-01 at 18:58, Jason Dixon wrote: > Sorry for the reply to self, but I found a solution. The following rdr > solves the problem, but should it be necessary? Can someone explain to > me why the default action of redirecting on the external interface, > since we're routing between LAN's, shouldn't work? > > rdr on $int_if proto tcp from any to $server port 80 -> $webserver \ > port 80 > > Thanks, > J. > > On Fri, 2002-11-01 at 18:29, Jason Dixon wrote: > > Good news and bad news. Good news, I finally got tcp reflection working > > (on 3.2) via the multiple nat/no nat/rdr rules. Turns out I had the > > $server confused with the ext_if address, rather than the webserver. > > Sounds stupid, but... well, I guess it is. :-P > > > > Bad news. Defaulting back to a "normal" set of NAT rules (one for > > "masquerading", one for port forwarding to the internal webserver), I'm > > having difficulties with a typical DMZ setup. This time, the client is > > on the 192.168.2.0/24 network, trying to reach the webserver on > > 192.168.1.0/24 network, but being redirected through the external > > interface (10.109.10.97). Every time I send a connection, the firewall > > sends an immediate reset. No traffic on any of the other interfaces. > > > > It does manage to work if I create a set of "reflection" rules for this > > interface as well, but I thought that a DMZ didn't NEED this sort of > > complex mangling. The routing is fine; I have no problems pinging the > > webserver from the client... it's only when the packet attempts to hit > > the external address for redirection that it gets reset. > > > > Any ideas? > > > > Thanks again, > > Jason > > > > > > > > > > >
Re: TCP Reflection: Summary
Sorry for the reply to self, but I found a solution. The following rdr solves the problem, but should it be necessary? Can someone explain to me why the default action of redirecting on the external interface, since we're routing between LAN's, shouldn't work? rdr on $int_if proto tcp from any to $server port 80 -> $webserver \ port 80 Thanks, J. On Fri, 2002-11-01 at 18:29, Jason Dixon wrote: > Good news and bad news. Good news, I finally got tcp reflection working > (on 3.2) via the multiple nat/no nat/rdr rules. Turns out I had the > $server confused with the ext_if address, rather than the webserver. > Sounds stupid, but... well, I guess it is. :-P > > Bad news. Defaulting back to a "normal" set of NAT rules (one for > "masquerading", one for port forwarding to the internal webserver), I'm > having difficulties with a typical DMZ setup. This time, the client is > on the 192.168.2.0/24 network, trying to reach the webserver on > 192.168.1.0/24 network, but being redirected through the external > interface (10.109.10.97). Every time I send a connection, the firewall > sends an immediate reset. No traffic on any of the other interfaces. > > It does manage to work if I create a set of "reflection" rules for this > interface as well, but I thought that a DMZ didn't NEED this sort of > complex mangling. The routing is fine; I have no problems pinging the > webserver from the client... it's only when the packet attempts to hit > the external address for redirection that it gets reset. > > Any ideas? > > Thanks again, > Jason > > > >
TCP Reflection: Summary
Good news and bad news. Good news, I finally got tcp reflection working (on 3.2) via the multiple nat/no nat/rdr rules. Turns out I had the $server confused with the ext_if address, rather than the webserver. Sounds stupid, but... well, I guess it is. :-P Bad news. Defaulting back to a "normal" set of NAT rules (one for "masquerading", one for port forwarding to the internal webserver), I'm having difficulties with a typical DMZ setup. This time, the client is on the 192.168.2.0/24 network, trying to reach the webserver on 192.168.1.0/24 network, but being redirected through the external interface (10.109.10.97). Every time I send a connection, the firewall sends an immediate reset. No traffic on any of the other interfaces. It does manage to work if I create a set of "reflection" rules for this interface as well, but I thought that a DMZ didn't NEED this sort of complex mangling. The routing is fine; I have no problems pinging the webserver from the client... it's only when the packet attempts to hit the external address for redirection that it gets reset. Any ideas? Thanks again, Jason
Re: Bad protocols and pf/nat
> Would it be interesting to write a generic proxy that included > support for each protocol? I mean, instead of running a proxy for > X, Y and Z, you could run 1 proxy and enable/disable support for > each application with the rdr rules. Monolithic pieces of security-oriented sofware are inevitably a bad idea. We should probably cobble together a plugboard proxy, however, as a kind of sample for proxy writers. -kj
OpenBSD 3.2 released
- OpenBSD 3.2 RELEASED - Nov 1, 2002. It is our pleasure to officially announce the release of OpenBSD 3.2. This is our 12th release on CD-ROM (and 13th via FTP). We remain proud of OpenBSD's record of six years with only a single remote hole in the default install. As in our previous releases, 3.2 provides significant improvements, including new features, in nearly all areas of the system: - Improved hardware support (http://www.OpenBSD.org/plat.html) o Asymmetric and symmetric hardware encryption support is enabled by default if a supported crypto accelerator is present. o Improved frame buffer and X Window System performance on the sparc, sparc64, and alpha platforms. o Builtin AGP-based video on i386 machines using ALI, AMD, Intel, SiS, and VIA chipsets is now supported and usable by the X Window System. o Intel Gigabit Ethernet adapters are now supported by the em(4) driver which replaces the gx(4) driver. The em(4) driver supports more models and has better performance than the old gx(4) driver. o Fixed a stability problem with the twe(4) driver and some UDMA drives. o Added support for more PCI-based Cyclades serial boards. o IDE disks larger than 128GB and UDMA133 are now supported. o Updated isp(4) and siop(4) SCSI drivers. o Added support for sbus-PCMCIA bridges on the sparc64 platform. o The wi(4) driver (Wavelan, Prism, and Symbol 802.11b) now works on the sparc64 platform. o DMA handling in the hme(4) driver has been fixed. - Major improvements in the pf packet filter, including: o New "antispoof" keyword: spoofing protection made easy. o Much simplified filter rule language. o Extended filtering capabilities. o All known bugs with filtering bridged interfaces have been fixed. o It is now possible to control state table entries with a per-rule granularity. o Support for dynamic interface expansion. There is no longer a need to reload the ruleset due to IP address changes. This is useful for interfaces where the address is dynamically assigned (PPP and DHCP). - Ever-improving security(http://www.OpenBSD.org/security.html) o Non-executable stack on i386, sparc (sun4m only), sparc64, alpha, and macppc platforms. Non-executable data and bss on sparc (sun4m only), sparc64 and alpha. This makes the system more resistent to buffer overflow attacks. o OpenBSD 3.2 ships with fewer setuid root binaries than ever before. Many of the remaining root setuid binaries drop root privileges early in their execution. The use of setuid in the ports subsystem has also been reduced. o Privilege separation is now the default in sshd. o The Apache web server now runs in a chroot jail by default. The new "-u" option can be used to disable this. o Several other security issues fixed throughout the system, many of which were identified by members of the OpenBSD team themselves. Please see http://www.OpenBSD.org/errata31.html for more details on what was fixed. - New subsystems included with 3.2 o A new tool, systrace, enables the user to specify policy for an executable at the system call level. o The sparc platform now uses ELF binaries. - Many other bugs fixed (http://www.OpenBSD.org/plus32.html) - The "ports" tree is greatly improved (http://www.OpenBSD.org/ports.html) o The 3.2 CD-ROMs ship with many pre-built packages for the common architectures. The FTP site contains hundreds more packages (for the important architectures) which we could not fit onto the CD-ROMs (or which had prohibitive licenses). - Many subsystems improved and updated since the last release: o XFree86 updated to 4.2.1. o Sendmail updated to 8.12.6. o Apache 1.3.26 and mod_ssl 2.8.10. o OpenSSL 0.9.7beta3 (+ patches) o Latest KAME IPv6 o OpenSSH 3.5 o The atrun command has been incorporated into the cron(8) daemon. o The vlan(4) driver now supports multicast. If you'd like to see a list of what has changed between OpenBSD 3.1 and 3.2, look at http://www.OpenBSD.org/plus32.html Even though the list is a summary of the most important changes made to OpenBSD, it still is a very very long list. This is our thirteenth OpenBSD release, and the twelfth release which is available on CD-ROM. Our releases have been spaced six months apart, and we plan to continue this timing. - SECURITY AND ERRATA -- We provide patches for known security threats and other important issues discovered after each CD release. As usual, between the creation of the OpenBSD 3.2 FTP/CD-ROM binaries and the actual 3.2 release date, our team found and fixed some new reliability
RE: Bad protocols and pf/nat
> For ftp, there's ftp-proxy, and the reverse proxy patch adds > support for servers behind the firewall: Hmm must have missed that. > For irc, there's net/tircproxy in the ports tree (which > includes a patch for NAT lookups with pf). Ok, are these written in a similar manner? Would it be interesting to write a generic proxy that included support for each protocol? I mean, instead of running a proxy for X, Y and Z, you could run 1 proxy and enable/disable support for each application with the rdr rules. > If you write userland proxies for other problematic > protocols, they are > welcome. Look at pf(4) and the existing proxies for examples of how to > use pf's ioctl interface. There won't be any application level proxies > in the kernel, and this has indeed been discussed a couple of > times, and > google finds the archives :) I did indeed see the discussion about keeping this stuff in userland, sensible idea. - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. -
Re: Bad protocols and pf/nat
On Fri, Nov 01, 2002 at 01:35:49PM +0100, [EMAIL PROTECTED] wrote: > I guess there are a lot of nat-unfriendly applications out there, but I, for one, >would be willing to contribute to such development. For ftp, there's ftp-proxy, and the reverse proxy patch adds support for servers behind the firewall: http://www.benzedrine.cx/ftp-proxy-reverse.diff For irc, there's net/tircproxy in the ports tree (which includes a patch for NAT lookups with pf). If you write userland proxies for other problematic protocols, they are welcome. Look at pf(4) and the existing proxies for examples of how to use pf's ioctl interface. There won't be any application level proxies in the kernel, and this has indeed been discussed a couple of times, and google finds the archives :) Daniel
Bad protocols and pf/nat
First of all, apoligies if this has been done to death (read archives, saw a little bit on app-proxying). Second, sorry about the appended disclaimer. I was wondering if the nat code will be extended to do some of the dodgy protocols like active FTP (or serving ftp to passive clients) as well as the usual suspects (rtsp, icq irc-dcc etc). What I want to do is only open up the ports that I require and not some high-port range. I know some firewalls are smart enough to watch the app layer protocols for port handshaking. And I know that ftp-proxy does some of what I am talking about (for FTP) but does not seem to work for servers as well as clients. I guess there are a lot of nat-unfriendly applications out there, but I, for one, would be willing to contribute to such development. -D - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. -
Re: fully transparent ftp-proxy?
i get the impression you thought i was suggesting rules to express embryo states. my intention was that the embryo statement merely be an entry point for traversal of embryo trees. the syntax could look something like this (without the macros defined): # an embryo tree addressable by the name "ircproxy" from userland that # checks that the initial packet is in fact an initial packet and will # modulate state on the connection prestates for "ircproxy" flags S/SA modulate # transparent irc proxy rdr on $int_if from $int_addr to any port 6667 -> 127.0.0.1 port 7666 # duh block in all block out all # included so i dont get flamed pass { in, out } quick on { lo0, $int_if } all # proxied connections now look like theyre coming from the external interface pass out on $ext_if inet proto tcp from $ext_if to any port 6667 flags S/SA keep state David Gwynne - Original Message - From: "Daniel Hartmeier" <[EMAIL PROTECTED]> To: "loki" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, November 01, 2002 2:59 AM Subject: Re: fully transparent ftp-proxy? > On Fri, Nov 01, 2002 at 02:14:58AM +1000, loki wrote: > > > rather than having an "embryo" flag on a rule tho, id make it its own > > directive and have it before the normal filter rules, therefore evaluated > > before the normal rules. state is checked before rules. since embryo > > states are almost states, it makes sense to me that they get checked > > before the rules as well. > > I don't think adding such a mechanism to the rule set improves > performance, quite the opposite. A single pointer comparison (for an > empty tree of embryonic states) is about as cheap as it gets. Look at > what already happens for each packet going through the packet filter, an > additional single comparison is just a tiny fraction. If we'd argue > about half a dozen cpu instructions, we could gain a lot more by > removing a single byte/packet counter. What does pfctl -si show for > 'Counters, match'? 1000 rule set evaluations per second? That would mean > 1000 additional pointer comparisons per second. Now benchmark how many > such comparisons you can do per second without increasing cpu load by > more than 1%, on a 486/133 if you like :) > > The point of an embryonic state inserted by a proxy is that it's an > exception from the static filter policy. If you could allow these > connections using a static rule set, there would be no need for > embryonic states. If you can't, you also have troubles expressing, > statically, _what_ embryonic states to allow. A proxy making use of such > a feature would require access to /dev/pf and it would have to be written > as carefully as authpf, for instance. > > > having such a rule (or rules) has several other advantages, you could > > create several trees, one for each proxy that requires it (include a > > mechanism for the proxy to talk to its own tree). you could specify which > > field of the state entry is variable (id still say that remote src port > > would be th only one, but its nice to be flexible). you could specify tcp > > flags and state modulation. whatever is needed for connections created by > > the proxy. > > I can't think of a case where anything but the source port is missing, > actually. And of course an embryonic state could hold any information a > normal state can (like address translations, timeout values, etc.) or any > information otherwise read from the rule that creates an ordinary state > (like modulation, route-to, etc.) > > The proxy wouldn't need to do anything but insert an embryonic state (no > enumeration, reading or changing of tree nodes), specifying a timeout > value after which it's removed if not completed. The whole kernel part > shouldn't get larger than a couple of lines, and the only change > relevant for userland would be an additional ioctl. > > There's another way of comparing performance: if you're using embryonic > states with a proxy, you're dealing with connections you want to allow. > You want the firewall to create state and pass the packets of that > connection. Creating a state entry from an embryonic state after doing a > normal state lookup (failing) and a lookup in the embryonic state table > is generally cheaper than walking the rule set and creating state in > that way (assuming you could express a pass keep state rule there for > such connections). If your embyonic state table constantly contains > several thousand entries, the lookup for each new connection will of > course have an impact. The question, in such a setup, is how many times > an embryonic state matches and becomes a normal state, saving a rule set > evaluation (which would always follow a failed state table lookup). I > guess it boils down to the ratio of expected proxy connections vs. newly > created normal states (or blocked connections) per second. > > Daniel > > >