Re: ftpsesame 'drop: short capture'
Jordi Espasa Clofent wrote:
Hi all,
Because of my previous problem I've seen the next output in
/var/log/messages:
-- Sep 22 19:00:01 ares newsyslog[21422]: logfile turned over
Sep 22 19:00:01 ares syslogd: restart
Sep 22 19:00:38 ares ftpsesame[15600]: drop: short capture
Sep 22 19:01:04 ares last message repeated 3 times
Sep 22 19:04:36 ares ftpsesame[15600]: drop: short capture
Sep 22 19:04:47 ares last message repeated 11 times
Sep 22 19:17:07 ares last message repeated 4 times
Sep 22 20:00:01 ares syslogd: restart
Sep 22 20:31:27 ares ftpsesame[15600]: drop: short capture
Sep 22 21:31:43 ares ftpsesame[15600]: drop: short capture
Sep 22 21:31:47 ares last message repeated 3 times
Sep 22 21:34:32 ares last message repeated 6 times
Sep 22 21:53:06 ares last message repeated 8 times
Sep 22 22:00:01 ares syslogd: restart
Sep 22 22:01:34 ares ftpsesame[15600]: drop: short capture
Sep 22 22:02:28 ares ftpsesame[15600]: drop: short capture
Sep 22 22:09:45 ares ftpsesame[15600]: drop: short capture
Sep 22 22:10:00 ares last message repeated 62 times
Sep 23 00:00:01 ares syslogd: restart
Sep 23 00:08:46 ares ftpsesame[15600]: drop: short capture
Sep 23 00:09:02 ares last message repeated 3 times
Sep 23 00:09:28 ares last message repeated 2 times
Sep 23 00:33:06 ares ftpsesame[15600]: drop: short capture
Sep 23 00:34:02 ares last message repeated 4 times
Sep 23 00:47:01 ares ftpsesame[15600]: drop: short capture
Sep 23 01:30:54 ares ftpsesame[15600]: drop: short capture
Sep 23 01:38:49 ares last message repeated 20 times
Sep 23 01:47:12 ares last message repeated 2 times
Sep 23 01:56:28 ares last message repeated 6 times
Sep 23 02:00:01 ares syslogd: restart
Sep 23 02:06:11 ares ftpsesame[15600]: drop: short capture
Sep 23 02:06:20 ares ftpsesame[15600]: drop: short capture
Sep 23 02:08:15 ares last message repeated 4 times
Sep 23 04:00:01 ares syslogd: restart
Sep 23 04:10:20 ares ftpsesame[15600]: drop: short capture
Sep 23 04:10:35 ares last message repeated 2 times
Sep 23 04:12:33 ares last message repeated 3 times
Sep 23 04:13:43 ares ftpsesame[15600]: drop: short capture
Sep 23 04:32:26 ares last message repeated 5 times
Sep 23 04:35:09 ares last message repeated 2 times
Sep 23 06:00:01 ares syslogd: restart
Sep 23 08:00:01 ares syslogd: restart
Sep 23 08:18:10 ares ftpsesame[15600]: drop: short capture
Sep 23 08:39:54 ares ftpsesame[15600]: drop: short capture
Sep 23 08:40:10 ares ftpsesame[15600]: drop: short capture
Sep 23 08:54:00 ares ftpsesame[15600]: drop: short capture
Sep 23 09:07:24 ares ftpsesame[15600]: drop: short capture
Sep 23 09:15:40 ares last message repeated 10 times
Sep 23 09:29:56 ares ftpsesame[15600]: drop: short capture
So, I've donwload the ftpsesame sources and search the concrete string:
$ grep -ir short capture *
ftpsesame.c:logmsg(LOG_WARNING, drop: short capture);
$ vim ftpsesame.c
[...]
if (h-caplen != h-len) {
logmsg(LOG_WARNING, drop: short capture);
return;
[...]
I understand that it's a basic check about the length of the processed
packet. Anyway, I'm not a coder... only a learner.
¿It's really a problem or a simply warning about malformed packets?
It's not a problem, just a warning that bpf did not capture the full packet.
But maybe the '!=' should be a '' though because of ethernet padding.
Can you change the logmsg line into:
logmsg(LOG_WARNING, drop: short capture, len: %d, caplen: %d, h-len,
h-caplen);
Re: ftpsesame questions
Jordi Espasa Clofent wrote: The scenario: bridged-based PF box with ftpsesame. OpenBSD 4.2, production environment. A lot of of FTP concurrents sessions. 1. The last goal is make possible active and passive FTP client connections AND do it with best performance (using symon I see that the ftpsesame processes are slowly sometimes). It uses a lot of CPU you mean? Do you have a lot of activity on port 21? (lots of small transfers maybe?). Note that ftpsesame doesn't have anything to do with the actual FTP data transfers, it just takes care to insert PF rules that allows those, after that is all kernel. At present moment, I use the next rules: # FTP passive anchor ftpsesame/* in on $bridge proto tcp from any to ftp_servers anchor ftpsesame/* out on $bridge proto tcp from any to ftp_servers # FTP active anchor ftpsesame/* in on $bridge proto tcp from ftp_servers to any anchor ftpsesame/* out on $bridge proto tcp from ftp_servers to any pass quick on $bridge inet proto tcp from any to ftp_servers port 21 I don't want to control any outbound connection (indeed I've a nice 'pass quick all' rule), so... ¿are these rules the best in relation to performance issues? That's all fine. 2. ftpsesame works fine, great app. I see it's a 0.95 version... and this version was made for OpenBSD 3.6. I suppose the program has not changed because the anchors treatment is the same in 3.6 as 4.2/4.3. ¿Am I right? Currently I use ftpsesame in production environment, so will be very unpleasant to upgrade from 4.2 to 4.3 and discover that ftpsesame not works... Should work, if it doesn't contact me. :-) I can vouch for OpenBSD 4.0. ¿Is ftpsesame actively developed/supported nowadays? Sure, but it has not been needed the last 3 years...
Re: deleting a rule
On Wed, 19 Jul 2006, Rajkumar S. wrote: PS: I still would love to see an example program to use pf ioctl, or some documentation, now just for academic purpose. pfctl is bit complex, especially when it gets to the parse.y and because it uses pfctl structure for most of the data. /usr/src/usr.sbin/ftp-proxy/filter.c is pretty bare bones. -- Cam
Re: Active failover with local Squid and ftp-proxy.
On Wed, 21 Jun 2006, Karl O. Pinc wrote: Too bad that pfsync (or something) can't sync anchors. I imagine there'd be some configuration involved, maybe to say which anchors the current box will allow to be synced, but that would take care of ftp-proxy failover. It would also No, that wouldn't be enough. What would have to be synced is the state and buffers of all established TCP connections in the kernel _and_ the internal state of the ftp-proxy. I don't think that's feasible.
Re: pf+ftp-proxy / pf company example questions
On Sat, 8 Apr 2006, Michal Soltys wrote: I have two (unreleated) questions - the first one regarding new ftp-proxy (the one using anchors) and the other regarding company example in official obsd faq (http://www.openbsd.org/faq/pf/queueing.html#example2) 1)... This is how I understand pf + ftp-proxy functionality: First, two simple rules (one to pass traffic going from ftp-proxy, the other to redirect the internal traffic to proxy) must be added - it's all clear and they are provided as example at the bottom of the man page: rdr pass on $int_if proto tcp from $lan to any port 21 - \ 127.0.0.1 port 8021 pass out proto tcp from $proxy to any port 21 keep state Now, in case of passive connections - ftp-proxy negotiates port to which the client should connect, and installs 2 rules: - a snat rule, that rewrites internal address to proxy's one: nat from $client to $server port $port - $proxy - and a filter rule to actually allow this connection leave the firewall: pass out quick inet proto tcp \ from $proxy to $server port $port flags S/SAFR keep state And as far as I understand, that covers everything that should be done - 2 anchored rules (nat, filter) cover ftp data connection. Earlier explicitely added rdr and filter rules cover initial control connection. So why is the following rule anchored as well : pass in quick inet proto tcp \ from $client to $server port $port flags S/SAFR keep state I can't really find the situation during which it would be needed. Especially that anchored nat rule (as nat/rdr are always executed before filtering, as per faq and man pages) seems to make it never actually happen. What do I miss ? The control (port 21) connection is proxied. It is rdr'ed to ftp-proxy which makes a real TCP connection to the server itself. The data connections are not proxied. The client makes the TCP connection to the server, and it is _not_ rdr'ed to the ftp-proxy. It is subjected to nat+rdr though, so that traffic from the client to the FTP server always originates from the proxy address. In short, it's ftp-proxy's job to make sure that: - the client always thinks it's talking to the server - the server always thinks it's talking to the proxy This is why you always need the nat and rdr anchors, even if you otherwise don't use NAT. To answer your question: data connections go _through_ the firewall, so both an 'in' and 'out' pass rule are needed. On a closing note: the example rules in the manpage are a bit simplified. The proxy rewrites source and destination ports for security and to minimize collisions. (Example of a collission: Imagine two freshly booted Windows machines connecting to the same server: they would both pick port 1024 for an active transfer. If the proxy would rewrite the source address, but not the source port, and the server connects back to port 1024, the proxy cannot tell for who it is.) -- Cam
Re: scrub blocking SF, but not logging
On Fri, 24 Feb 2006, Jon Hart wrote: scrub all no-df random-id fragment reassemble Any ideas why this is not logged, or is this operator error? I don't think it's very well known, but you can set 'log' on the scrub rule. That will show you more info if scrub kicks in: 10:01:06.100845 rule 0/(fragment) scrub in on sis0: 193.0.0.195 82.217.x.x: (frag 61843:[EMAIL PROTECTED]) (DF) (ttl 61, len 630) 10:01:06.100972 rule 0/(fragment) scrub in on sis0: 193.0.0.195.53 82.217.x.x.29785: 58221*-[|domain] (frag 61843:[EMAIL PROTECTED]) (DF) (ttl 61, len 1500) 10:01:06.106046 rule 0/(fragment) scrub in on sis0: 193.0.0.195 82.217.x.x: (frag 61844:[EMAIL PROTECTED]) (DF) (ttl 61, len 642) 10:01:06.106200 rule 0/(fragment) scrub in on sis0: 193.0.0.195.53 82.217.x.x.29785: 34991*-[|domain] (frag 61844:[EMAIL PROTECTED]) (DF) (ttl 61, len 1500) (but it looks like tcpdump cannot filter on action scrub yet) -- Cam
Re: ftp server behind OpenBSD PF, I'm almost mad
On Mon, 9 Jan 2006, Can Erkin Acar wrote: 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. Yes, this is much sounder advice then what I wrote in a previous email in this thread. :-} Don't use ftpsesame in combination with NAT, you can never make it work 100% because it cannot rewrite the data connection. -- Cam
Re: ftp server behind OpenBSD PF, I'm almost mad
Is there any standalone project page for ftp-proxy (pftpx). I'm just curios because in daily changelog I think I saw some buffer overrflow fix for ftp-proxy so I guess that this bug is in pftpx 0.8 as well and I should rather use ftp-proxy from OpenBSD -current. Am I right? No, such a page does not exist. Since 0.8 a couple of bugs were fixed but none security critical (including the buffer overflow, which was theoretical: snprintf with a static string). -- Cam
Re: ftp-proxy vs. ftpsesame
On Mon, 18 Jul 2005, Daniel T. Staal wrote: My setup is fairly simple: I have a NATed home network with several users and a web host that I serve a couple of websites off of. Ideally, of course, I'd like everything to Just Work: active and passive, both from all the clients and to the server. I'm just wondering what parts should be delegated to which handler, or if some direction/connection should be left off. From a scan of the man pages, ftpsesame looks to be able to handle just about everything except active client connections, and ftp-proxy seems to be able to handle everything major, but requires a lot of ports open. What else should I consider? Warning: I wrote two of the three available proxies... There are 3 options (in order of age): 1) ftp-proxy 2) ftpsesame 3) pftpx (but now available in OpenBSD _cvs_ in usr.sbin/ftp-proxy) ftp-proxy is a real proxy. With the help of pf rdr it intercepts the control connection and opens real (tcp) data connections on the users behalf. Except if you use the -n mode, where it assumes that passive connections are allowed globally by the pf ruleset. ftpsesame use bpf to sniff the control connections. To allow the data connections it commits rules into a special anchor. Advantages: totally passive, works on a bridge as well. Disadvantages: can not handle NAT situations well, since it cannot rewrite commands in the control connection. It can also be racy, eg. that rules are not commited in time, but that does not seem be a problem in practice. pftpx uses a combination. It intercepts the control connection with rdr like ftp-proxy does, but commits rules into an anchor to allow data connections like ftpsesame does. It can handle all types of NAT, IPv6 and all types of FTP. I guess the last one is best for your situation. While it is available at: http://www.sentia.org/downloads/pftpx-0.8.tar.gz the last and best version is in OpenBSD cvs in src/usr.sbin/ftp-proxy It's not connected to the build yet though, so it's not available in snapshots. I can also not tell if it will make OpenBSD 3.8 or not. Hope that sheds some light in the already confusing world of FTP. :-) -- Cam
Re: ftp connections not working on FreeBSD firewall box with pftpx
On Sat, 16 Jul 2005, Michael Weiser wrote: Unfortunately this only catches connections coming in via the internal interface bound for the internet. FTP connections originating on the machine itself don't work. They never get redirected but leave directly via the external interface. So pftpx doesn't see them to add the proper firewall rules. Consequently the return connections for active ftp and high port data connections for passive ftp bounce at the firewall. Is there a workaround or proper solution for this (possibly including a rant about my braindamage ;) ? Nope, there is no way to rdr connections originating on the local box, hence no way for pftpx to get involved. Why are you doing ftp from the firewall anyway? ;-) Seriously, my other ftp proxy ftpsesame does handle this situation but might be racy with connections from the local box. See http://www.sentia.org/projects/ftpsesame -- Cam
Re: sample NAT logs and analysis tools (OBSD- fp)
On Thu, 28 Apr 2005, Russell Fulton wrote: I am shortly going to have to set up NAT our residences firewall and one of the things I am going to deal with is storage of NAT logs so we can trace nefarious traffic after the fact. I am still in the planning phase and I would be grateful if someone could forward me some sample NAT logs from pf so I can see what I am dealing with. There are no seperate NAT logs in pf. You can now only correlate loglines from different interfaces using the timestamp and the destination ip and port. (for nat, vice versa for rdr). I for one would like to see nat actions logged seperately, but I think it requires major surgery in pf and tcpdump (and maybe pflogd). I dabbled a bit in that area because I wanted logging on 'nat|rdr pass' rules, but reached nothing conclusive... -- Cam
Re: Still no answer on my bridge question
On Thu, 7 Apr 2005, Russell Fulton wrote: I am seeing packets being dropped by pf that should not traverse the bridge at all (i.e. packets between hosts that are on the same side of the bridge). After a little thought I came to the conclusion that this is quite plausible since the filtering is taking place on the interface closest to the affected hosts and the packets are hitting pf before they get to the bridging logic. No, bridging comes first. And yes, the packet _should_ be dropped when the destination interface (according to the bridgecache) is the same as the source interface of the packet.
Re: pf and ftp
On Mon, 21 Mar 2005, Peter Fraser wrote: A while a go I had trouble if ftp-proxy and windows ftp clients. The windows clients were checking to see if the ftp responses were actually coming from the ip address they expected, and they were not, and as a result the ftp client would object and the session would end. It was suggest that I try pftpx by Camiel Dobbelaar [EMAIL PROTECTED] I did, and it has been working very well for my for about 6 weeks. Thank you! Let me seize this opportunity to plug a new version, which I would appreciate if people could test it. http://www.sentia.org/downloads/pftpx-0.8.tar.gz Changes: - fix a critical bug where pftpx might crash on prematurely aborted sessions - use pf rollback where appropriate. It also tries commits twice when pf is busy. - rewrite source and destination ports so they are random. This minimizes port collisions (which are already pretty rare) and adds security (some systems pick weak ports). - sourceport can fixed to port 20 for _really_ antique clients -- Cam
Re: Re: (why can't)/(does) carp work on bridges ?
On Fri, 17 Dec 2004, Joel CARNAT wrote: my test is pinging 192.168.10.200 (the carp interface). it's OK until I brconfig bridge0 up. from then, I can see (tcpdump) echo request on bge0 and bge1 but nowhere else (and no ack anywhere). then I brconfig bridge0 down and the ping works back. that's why I'm pretty sure the bug is the bridge (or @least the way I configured it ;)... I thought, maybe, setting the bridge confuses carp because paquets are first forwarded from bge0 to bge1 and as carp0 is linked to bge0, it doesn't work on the paquet (yes, I already tried to set carp0 on bge1 and same error occurs). It's something I'm working on at the moment. The bridge does not recognize that the CARP MAC address is destined for itself (bge0), and tries to bridge it to no avail. At the moment there is no simple solution.
Re: Re: (why can't)/(does) carp work on bridges ?
On Fri, 17 Dec 2004, Joel CARNAT wrote: that's why I'm pretty sure the bug is the bridge (or @least the way I configured it ;)... I thought, maybe, setting the bridge confuses carp because paquets are first forwarded from bge0 to bge1 and as carp0 is linked to bge0, it doesn't work on the paquet (yes, I already tried to set carp0 on bge1 and same error occurs). You're lucky, Chris Pascoe just fixed it in -current. Go try it! ;-)
Re: new ftp proxy: pftpx
On Tue, 14 Dec 2004, Tobias Wigand wrote: hope it doesn´t have any severe exploitable bugs, though. ;-) Peer review would be good... but it already does some mitigation: check the security section below. I've put up the latest version at http://www.sentia.org/downloads/pftpx-0.5.tar.gz it includes a manpage as well, which is pretty short so I'll paste it below. -- Cam PFTPX(8)OpenBSD System Manager's Manual PFTPX(8) NAME pftpx - FTP proxy SYNOPSIS pftpx [-6d] [-b address] [-c port] [-D level] [-f address] [-g port] [-m maxsessions] [-p address] [-q queue] [-t timeout] DESCRIPTION pftpx is a proxy for the Internet File Transfer Protocol. FTP control connections should be redirected into the proxy using the pf(4) rdr com- mand, after which the proxy connects to the server on behalf of the client. The proxy allows data connections to pass, rewriting and redirecting them so that the right addresses are used. All connections from the client to the server have their source address rewritten so they appear to come from the proxy. Consequently, all connections from the server to the proxy have their destination address rewritten, so they are redirected to the client. The proxy uses the pf(4) anchor facility for this. Assuming the FTP control connection is from $client to $server, the proxy connected to the server using the $proxy source address, and $port is ne- gotiated, then pftpx adds the following rules to the various anchors. (These example rules use inet, but the proxy also supports inet6.) In case of active mode (PORT or EPRT): rdr from $server to $proxy port $port - $client pass log quick inet proto tcp \ from $server to $client port $port flags S/SAFR keep state In case of passive mode (PASV or EPSV): nat from $client to $server port $port - $proxy pass log quick inet proto tcp \ from $client to $server port $port flags S/SAFR keep state pass log quick inet proto tcp \ from $proxy to $server port $port flags S/SAFR keep state The options are as follows: -6 IPv6 mode. The proxy will expect and use IPv6 addresses for all communication. Only the extended FTP modes EPSV and EPRT are al- lowed with IPv6. The proxy is in IPv4 mode by default. -b address Address where the proxy will listen for redirected connections. The default is 127.0.0.1, or ::1 in IPv6 mode. -c port Port where the proxy will listen for redirected connections. The default is port 8021. -d Do not daemonize. The process will stay in the foreground, log- ging to stderr. -D level Debug level, ranging from 0 to 7. Higher is more verbose. The default is 5. (These levels correspond to the syslog(3) levels.) -f address Fixed server address. The proxy will always connect to the same server, regardless of where the client wanted to connect to (be- fore it was redirected). Use this option to proxy for a server behind NAT, or to forward all connections to another proxy. -g port Fixed server port. Only used in combination with the previous option. The default is port 21. -m maxsessions Maximum number of concurrent FTP sessions. When the proxy reach- es this limit, new connections are denied. The default is 100. -p address Proxy source address. The proxy will use this as the source ad- dress to connect to servers. -q queue Create rules with queue queue appended, so that data connections can be queued. -t timeout Number of seconds that the control connection can be idle, before the proxy will disconnect. The default is 24 hours. Do not set this too low, because the control connection is usually idle when large data transfers are taking place. CONFIGURATION To make use of the proxy, pf.conf(5) needs the following rules. All an- chors are mandatory. The rdr pass rule can be adjusted as needed. In the NAT section: nat-anchor pftpx/* rdr-anchor pftpx/* rdr pass on $int_if proto tcp from $lan to any port 21 - 127.0.0.1 port 8021 In the rule section: anchor pftpx/* SECURITY Negotiated data connection ports below 1024 are not allowed. The negotiated IP address for active modes is ignored for security rea- sons. This makes third party file transfers impossible. pftpx chroots to /var/empty and changes to user proxy to drop privi- leges. SEE ALSO ftp(1), pf(4), pf.conf(5),
new ftp proxy: pftpx
Ok, bleeding edge pf people... I wrote a new FTP proxy called pftpx and I'd like to solicit some feedback from the community... Why should you try it? What advantages does pftpx offer? 1) it handles all ftp modes: PORT, PASV, EPRT, EPSV 2) it handles ipv6 3) it should scale: one process handles all sessions using libevent 4) it works with strict ftp clients (clients that want data connections to the same IP as the control connection) Quick guide: - you need libevent-0.8 (OpenBSD 3.6 has it) - download http://www.sentia.org/downloads/pftpx-0.3.tar.gz - untar, make - add this to pf.conf in the nat section: nat-anchor pftpx/* rdr-anchor pftpx/* rdr pass on $if proto tcp from any to any port 21 - 127.0.0.1 port 8021 - add this to pf.conf in the rule section: anchor pftpx/* - run the proxy in debug mode: sudo pftpx -d -D7 - ready to go... Sorry, no manpage yet, this is bleeding edge after all. Don't run this in production if your job depends on it. :-) All feedback welcome, also if you want to suggest a better name. :-) Regards, Cam
Re: new ftp proxy: pftpx
On Thu, 25 Nov 2004, Marcos Biscaysaqu - ThePacific.net wrote: Do you know if work on freebsd? Not sure. The two most important parts are: - recursive anchors (appeared in OpenBSD 3.6). Maybe Max knows when those when into FreeBSD? - libevent 0.8 (from ports/devel/libevent) Anything else that crops up should be easily fixable. -- Cam
Re: ftp throu transparent filtering bridge
On Tue, 23 Nov 2004, Roman Marcinek wrote: Are there any smarted solutions I haven't found yet? I know that linux's iptables make use of special connection tracking module for ftp to handle that problem but ... is there anything like this for OpenBSD? Ok, let me plug my own program again: http://www.sentia.org/ftpsesame
Re: ftp throu transparent filtering bridge
On Tue, 23 Nov 2004, Camiel Dobbelaar wrote: On Tue, 23 Nov 2004, Roman Marcinek wrote: Are there any smarted solutions I haven't found yet? I know that linux's iptables make use of special connection tracking module for ftp to handle that problem but ... is there anything like this for OpenBSD? Ok, let me plug my own program again: http://www.sentia.org/ftpsesame Duh, at least get the link right: http://www.sentia.org/projects/ftpsesame Sorry about that.
Re: FTP active mode desn't work properly with nat on PF
On Tue, 26 Oct 2004, Greg Hennessy wrote: On 25 Oct 2004 16:41:21 -0700, [EMAIL PROTECTED] (Marcos Biscaysaqu - ThePacific.net) wrote: somebody know how fix this, or if it another option to make work ftp clients on Active mode with PF? Yes, its called ftpsesame. Unfortunately, ftpsesame cannot handle this (active mode w/ NAT) either. I'm afraid there is no solution for these strict clients at the moment. -- Cam
ftpsesame new releases
First things first, ftpsesame has a home on the web now: http://www.sentia.org/projects/ftpsesame And these are the new versions: * version 0.91 for OpenBSD 3.4 and 3.5: http://www.sentia.org/downloads/ftpsesame-0.91.tar.gz Changes: - removal of layer-2 MAC checking, because it causes problems in some networks - log priority tweaks * version 0.95 for OpenBSD 3.6 http://www.sentia.org/downloads/ftpsesame-0.95.tar.gz Changes: - see changes for 0.91 - make it work with improved anchors on OpenBSD 3.6 Enjoy. -- Cam
Re: Ftpsesame and booting up...
On Mon, 4 Oct 2004, Henrik Bro wrote: I am new to openbsd and ftpsesame. How do I get ftpsesame to start on boot? I use /etc/rc.local: if [ -x /usr/local/bin/ftpsesame ]; then echo -n ' ftpsesame'; /usr/local/bin/ftpsesame -i em0 fi
Re: blocking DHCP requests
On Sat, 2 Oct 2004, [ISO-8859-1] Björn Ketelaars wrote: I'm trying to block wireless clients in using my DHCP-server. The problem is that these clients are still able to retrieve IP-information from the DHCP-server. If I understand the hereby included pf.conf, everything (except UDP domain and TCP ssh) is blocked into entering $wir_if (which comes from $wir_if:network). Doesn't this also mean that an DHCP-request is blocked? Any suggestions in what I'm missing? dhcpd (like tcpdump) uses bpf/libpcap, which gets a copy of the network data before pf does. This means you cannot use pf to filter what gets to dhcpd. -- Cam
Re: pf ftpsesame - multiple interfaces?
On Thu, 26 Aug 2004, matthew zeier wrote: I'm trying to use pf for a shared customer firewall. Each customer is an anchor and lives on its own vlan interface. I want/need ftpsesame to act as a global anchor. Do I need to run multiple instances of ftpsesame or is there a way to have ftpsesame listen to every interface? Nope, one interface per instance. There is no interface where all traffic passes through; an external interface for example? -- Cam
Re: pf ftpsesame - multiple interfaces?
On Thu, 26 Aug 2004, matthew zeier wrote: I had it running on the outside interface (fxp0) but that didn't seem to see all the FTP traffic from the server. Running '-d -D 7' produced zero output when I ran with '-i fxp0'. That may be a bug in ftpsesame. To prevent layer-2 spoofing ftpsesame tracks that all traffic is from mac A to mac B and vice versa. That assumption seems to be flawed. For example, my own cable provider: the default gateway is 82.x.x.1 with mac 0:0:5e:0:1:2a (that's in my arp table). zigzag$ sudo tcpdump -i fxp0 -env tcp and port 21 and \( tcp[13] = 2 or tcp[13] = 18 \) tcpdump: listening on fxp0 01:03:25.793122 0:90:27:d6:26:14 0:0:5e:0:1:2a 0800 78: 82.x.x.x.18768 194.109.21.26.21: S ^ 01:03:25.805642 0:f:8f:7e:de:0 0:90:27:d6:26:14 0800 74: 194.109.21.26.21 82.x.x.x.18768: S snip ack ^^ So, traffic I get back has a different mac (and may indeed be from another system). With the tcpdump above you can try if that's the reason why ftpsesame fails for you on that interface. I'll probably remove the layer-2 spoof prevention from the next release, for this reason (contact me if you'd like to try it sooner). -- Cam
Re: Have I compiled ftpsesame wrong?
If the Soekris is on a snapshot (3.6-ish), then ftpsesame from a 3.5 box does not work. I'm working on an update of ftpsesame for OpenBSD 3.6. It needs changes because the anchors functionality changed in pf. -- Cam On Wed, 25 Aug 2004, Jonny Baird wrote: Hi, I have a Soekris 4501 using flashboot, http://www.mindrot.org/flashboot.html I wanted to use ftpsesame to access internal ftp servers but couldn't get it working: Session info: # ftpsesame -d -D 7 -i sis0 listening on sis0, filter 'tcp and port 21', snaplen 500 #1 session init: client x.x.x.x:2513, server y.y.y.y:21 sessions after purging: 0 #2 session init: client x.x.x.x:2523, server y.y.y.y:21 sessions after purging: 1 #2 session finish test pf.conf: ext_if = sis0 block in on $ext_if all block out on $ext_if all pass in quick on $ext_if proto tcp from any to any port=21 flags S/SA keep state anchor ftpsesame on $ext_if I presume that my problem is that I have compiled ftpsesame on a different openbsd box (AMD + Openbsd 3.5) - is this correct? Many Thanks, Jonny
Re: ftpsesame output
On Tue, 13 Apr 2004, Eaton, Andy wrote: Why would I get output from ftpsesame like the following but not have anything in the anchor ftpsesame ruleset? Apr 13 14:54:59 igg ftpsesame[2458]: #42 allowing 128.252.142.52 to 172.16.8.97 port 1930 There should be something there while a session is running. What command did you use to list them? Also note that rules are purged pretty quickly. Will decreasing the debug level stop it? I don't see the information in the man page and I am not sure which part of the previous line is making ftpsesame output to console and ssh sessions. The messages above are logged to daemon.info. This line causes it to appear on your screen: *.notice;auth.debug root Running ftpsesame with -D4 should stop them. -- Cam
Re: Ftpsesame on vanilla 3.4
On Thu, 8 Apr 2004, Eaton, Andy wrote:
Quick question for those using ftpsesame on 3.4 that is up to date with
the stable source:
1. I was able to make the source but not make install the source.
I get:
You need ftpsesame 0.9 for make install to work.
2. In the ruleset I can't use a line like the following...
anchor ftpsesame on { $int_if, $ext_if } pfctl issues an error.
It's an example. You have to define int_if and ext_if in your ruleset as
well. (but I guess you need all_ints and all_exts here). But with this
many interfaces you're probably better of with just anchor ftpsesame.
I need ftpsesame to listen on each or at least the external vlans,
right now I have not figured out a way to start ftpsesame so that it
will
listen on all the vlans. ftpsesame -i $ext_if will not work. It
gives the following:
# ftpsesame -i $all_exts
ftpsesame does not use pf.conf itself so you cannot use macros here.
Another problem is that ftpsesame (like most bpf programs) can only listen
on one interface at a time, so you have to run multiple ftpsesame's, one
for each interface.
It can do that, and memory and performance wise it should not be that bad.
You may run out of bpf devices though (8 in the generic kernel).
--
Cam
Re: pf bridges in parallel
On Fri, 26 Mar 2004, Russell Fulton wrote: We have now been running with our pf perimeter firewall for 3 months. It is set up as a bridge. We have installed a second (more or less identical system) in parallel but when we plug it in neither bridge passes traffic. On reading the brconfig man pages (again) I see the stp option and this is probably the cause of our 'problem'. Yes, with two bridges in parallel, you _must_ use spanning tree, otherwise you have a loop and traffic storms can occur. What isn't clear to me is which interface should I specify in the stp option on each bridge? You should specify 'stp' on all interfaces. You may want to set 'priority' to a lower value on one of the systems as well, to manually set the primary firewall.
Re: ftpsesame and pf.conf
On Tue, 23 Mar 2004, Russell Fulton wrote: I'm about to try out ftpsesame on our firewall. The system is set up as a bridge and I only filter on $ext_if. I intend running ftpsesame as ftpsesame -i $ext_if # ftp rules anchor ftpsesame out on $ext_if pass in quick on $ext_if proto tcp from any to (ftpc_in port=21 flags S/SA modulate state anchor ftpsesame in on $ext_if proto tcp from any to ftpc_in I want ftpsesame to handle all outbound and inbound ftp traffic. Outbound we have other rules which control whether particular addresses have internet access on not, Inbound we have a table ftpc_in which lists all addresses on campus that have inbound access on port 21. Will this do what I want? To be sure: ftpc_in contains _servers_ that can be accessed from the internet right? Then yes, this will work ok to allow active and passive mode to the servers listed in ftpc_in. However, if you allow ftp from campus users to the internet, active mode will not work. You might want to consider the more general: anchor ftpsesame on $ext_if proto tcp all
Re: HA pf setup ?
On Fri, 12 Mar 2004, matthew zeier wrote: However, if just the outside interface on the master goes done, the other unit becomes master for the outside but remains backup on the inside and routing is broken. How have others solved this? ifstated is meant to solve these type of problems. See usr.sbin/ifstated in a current src tree.
Re: HA pf setup ?
On Sat, 13 Mar 2004, matthew zeier wrote: ifstated is meant to solve these type of problems. See usr.sbin/ifstated in a current src tree. The man page for that is pretty light and there isn't any sample config file. src/etc/ifstated.conf
Re: first release: ftpsesame
On Fri, 9 Jan 2004, sandolo wrote: filter.c:130: `DIOCXCOMMIT' undeclared (first use in this function) I'm running OBSD 3.4 RELEASE, any help ? Hmm, yes, it turns out that atomic commits were added after 3.4. Please try this one: http://www.sentia.org/downloads/ftpsesame-0.8.tar.gz Other changes: - check that pf is enabled - use BIOCIMMEDIATE on bpf descriptor - stricter matching of server replies - more notes in manpage SECURITY section -- Cam
first release: ftpsesame
Announcing ftpsesame... one of those christmas time projects. :-)
ftpsesame helps the FTP protocol get through your pf firewall without
having to open up whole ranges of ports. It works for FTP clients and
FTP servers, and you do not have to redirect any traffic.
How does it work?
ftpsesame sniffs FTP control connections using bpf, and adds rules to
allow active or passive data connections into an anchor when appropriate.
For full details, see the manpage below.
It was developed on OpenBSD -current and should work fine on 3.4. It can
be made to work on 3.3 if tagging support is removed (drop me a note if
you want the diff).
Because anchor support is essential, OpenBSD 3.2 and below are not
supported.
Download: http://www.sentia.org/downloads/ftpsesame-0.7.tar.gz
Comments, suggestions, etc. welcome.
--
Cam
NAME
ftpsesame - automagic packet filter configurator for FTP
SYNOPSIS
ftpsesame [-d] [-D level] [-i interface] [-t tag] [-q queue] [expression]
DESCRIPTION
ftpsesame tracks FTP control connections to be able to timely add pf(4)
packet filter rules that allow active and passive FTP data transfers to
commence. This results in the efficiency of a packet filter, and the
fine-grained control of a proxy. It can run on both FTP clients and FTP
servers, or a firewall in front thereof.
ftpsesame uses bpf(4) to get a copy of the data inside all FTP control
connections passing the specified interface. This data is searched for
negotiations about data connections. For passive mode, this is a port
that a client should use to connect to a server. For active mode this is
a port and an IP address that a server should use to connect to a client.
Assuming the FTP control connection is from $client to $server, and $port
is negotiated, ftpsesame adds one of the following rules to pf(4), inside
the anchor named ftpsesame.
In case of active mode (PORT or EPRT):
pass in log quick inet proto tcp \
from $server to $client port $port flags S/SAFR keep state
In case of passive mode (PASV or EPSV):
pass in log quick inet proto tcp \
from $client to $server port $port flags S/SAFR keep state
In the special case of passive mode where the client is subject to NAT,
an extra rule is added, where $client_real is the client's real IP ad-
dress:
pass in log quick inet proto tcp \
from $client_real to $server port $port flags S/SAFR keep state
The options are as follows:
-D level
Debug level, ranging from 0 to 7. Higher is more verbose. The
default is 5. (These levels correspond to the syslog (3) levels.)
-d
Do not daemonize. The process will stay in the foreground, log-
ging to stderr.
-i interface
Listen on interface.
-t tag
Create rules with tag tag. Also, option quick is not used. This
way the anchor always returns to the main ruleset, with the tag
set on approved FTP data connections. The tag can then be used
in pass rules below the anchor.
-q queue
Create rules with queue queue appended.
expression
Selects the packets that bpf(4) will pass on to ftpsesame. An
expression consist of the primitives described in tcpdump(8).
For efficiency, the expression should narrow down the traffic as
much as possible. The default is tcp and port 21.
CONFIGURATION EXAMPLES
To use the rules set up by ftpsesame, pf.conf(5) should be modified to
use the anchor. Below are examples that show most of the possibilities.
# (1) Allow internal LAN to access FTP servers anywhere.
# (passive mode only if $lan is subject to NAT, see below)
# cmd: ftpsesame -i $ext_if
anchor ftpsesame on { $int_if, $ext_if }
pass in quick on $int_if proto tcp from $lan to any port 21 keep state
pass out quick on $ext_if proto tcp from $lan to any port 21 keep state
# (2) Allow access to FTP servers in the DMZ, while queueing the data
# transfers.
# cmd: ftpsesame -i $dmz_if -q ftp
queue ftp bandwidth 10%
# passive
anchor ftpsesame in on $ext_if proto tcp from any to { $ftp_servers }
anchor ftpsesame out on $dmz_if proto tcp from any to { $ftp_servers }
# active
anchor ftpsesame in on $dmz_if proto tcp from { $ftp_servers } to any
anchor ftpsesame out on $ext_if proto tcp from { $ftp_servers } to any
# ... rules for port 21 omitted ...
# (3) Allow access to FTP servers in the DMZ, using tagging for fine
# grained control.
# cmd: ftpsesame -i $dmz_if -t ftpok
anchor ftpsesame
# passive
pass in quick on $ext_if proto tcp from to any to $realftp \
port 49151 tagged ftpok keep state
pass in quick on $ext_if proto tcp from any to $msftp \
port 1023 5001 tagged ftpok keep state
pass out quick on $dmz_if all tagged ftpok keep state
# active
pass in quick on $dmz_if proto tcp from $realftp to any \
tagged ftpok keep state
pass in quick on $dmz_if proto tcp from $msftp port 20 to any \
tagged ftpok keep state
pass out quick on $ext_if all tagged ftpok keep state
# ...
Re: bridge, but when ?
On Wed, 7 Jan 2004, Ed White wrote: So what are the advantages of a bridge for a classic 3-if firewall ? Bridging and routing are not interchangeable... it all depends on the network topology. If you filter between segments that are the same IP network (A/24) you bridge. If you filter between segments that are different IP networks (A/24 and B/24) you usually route... In practice you choose bridge when you don't want to waste precious IP addresses on subnetting (to make routing possible). Or if you cannot even subnet because you do not control all routers (think ISP). -- Cam
Re: CheckPoint SecureRemote Client through pf
I have secureclient working fine here through a pf firewall, with NAT. No special tricks really... if I tcpdump I first see isakmp traffic (500/udp), then encapsulated traffic using 2746/udp. Let me know if you need more info. -- Cam On Fri, 28 Feb 2003, siivv wrote: Is a connection with the checkpoint secureremote client possible through a obsd 3.2 nat'd pf firewall? I am refering to an outbound connection from my home network, through the pf fwall, and to the checkpoint fwall I have read that it is not possible with NAT, but figured I would run it by those who may have used it. Also, if this is possible, can someone point me in the direction of documentation or explain how exactly it can be done
new pf.vim
I've uploaded a new version of pf.vim to www.vim.org. http://www.vim.org/scripts/script.php?script_id=341 Older 'screenshot' here: http://www.sentia.org/downloads/pf.conf.html Changes: - recognizes altq and table statements - recognizes ipv4 shorthands: 10/8, 172.16/12 - folding Folding is a cool Vim feature that's very suited to large pf rulesets. Inside pf.conf all you have to do is use '###' to denote a section, '##' for a subsection, and '#' for a sub-subsection. Example below, but it really doesn't do it justice. :-) -- Cam If you structure your ruleset like this: ### MACROS ### TABLES ### OPTIONS ### NORMALIZE ### QUEUE ### NAT ### FILTER ## lo0 - localhost ## enc0 - encryption interface ## $int_if - internal interface (lan) ## $wlan_if - wavelan interface (bridged with lan) ## $ext_if - external interface ## Default policy then this is what Vim can show you (three folds open): +-- 16 lines: ### MACROS +-- 4 lines: ### TABLES +-- 6 lines: ### OPTIONS--- ### NORMALIZE scrub in all min-ttl 2 +-- 13 lines: ### QUEUE- +-- 4 lines: ### NAT--- ### FILTER +--- 4 lines: ## lo0 - localhost--- +--- 4 lines: ## enc0 - encryption interface-- +--- 5 lines: ## $int_if - internal interface (lan) +--- 4 lines: ## $wlan_if - wavelan interface (bridged with lan)--- +--- 32 lines: ## $ext_if - external interface-- ## Default policy block log all ~ ~ ~ ~ ~
Re: PF Reflection (cont'd)
On 15 Nov 2002, Jason Dixon wrote: Well, things started to clear up a bit just now when I captured the session with ethereal. Around the 7th packet into the connection, the gateway sends an ICMP redirect (type 5, code 1) to the server with the client's IP as the gateway! This appears to be causing the server to route the return packets directly to the client interface, even though the IP says otherwise. Any idea what would cause this behavior? Is this normal? Is it a byproduct of some weird conflicting pf rule? Gateways send ICMP redirects if they notice that a routed packet leaves the same interface as where it came in on. That's normal behavior. In your case the packet is NAT'ed twice though, which probably confuses the network stack as much as it does me. :-) Blocking those redirects on the gateway may well not be possible, since pf matches ICMP errors automagically to existing states. What does the ICMP redirect look like exactly? -- Cam
new pf.conf syntax highlighting for Vim
Dear misc and pf, I've uploaded a new version of pf.vim to www.vim.org. Please download it from http://www.vim.org/script.php?script_id=341 and _vote_ to improve the script karma. If you do both, pf.vim might end up in Vim itself, so it does no longer have to be downloaded and installed seperately. If you don't know what I'm talking about, here's a screenshot of what Vim can do for your pf.conf: http://www.sentia.org/downloads/pf.conf.html The new version has the following improvements: - groks IPv6 addresses - highlights most well-known services (by name) - strings can be single quoted - assignment matching is simplified - antispoof keyword is new - some more obscure highlightings have been removed so the set command options do not look like a rainbow anymore :-) And I promise this is the last time I wildly cross-post like this. :-) -- Cam
