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
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: 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
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. -
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
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
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: 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
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
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: 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.
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/
