From: Michael Weiser <michael@weiser.dinsnail.net>
To: netfilter@vger.kernel.org
Subject: Restrictive FTP egress using conntrack helper
Date: Sat, 11 Feb 2017 18:14:31 +0100 [thread overview]
Message-ID: <20170211171431.GD31183@weiser.dinsnail.net> (raw)
Hi,
in the script that sets up my iptables firewall I found a comment I must
have written some time between 2005 and 2012:
# allowing RELATED outgoing connections makes passive FTP work without
# the need to allow all high ports out
So the following kind of very restrictive egress policing should have
worked at some point in time (2.6.x or 3.x kernels):
# Generated by iptables-save v1.6.0 on Sat Feb 11 16:45:51 2017
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [4:240]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 21 -j ACCEPT
COMMIT
# Completed on Sat Feb 11 16:45:51 2017
Of course the conntrack helper is loaded as well:
# lsmod | grep _ftp
nf_conntrack_ftp 20480 0
My expectation is for the FTP conntack helper to recognise the 227
response in the control connection of a passive FTP session and consider
the ensuing data connection initiated by the FTP client as RELATED.
Looking at the helper's kernel code doesn't really burst that bubble
either. But I can't seem to get it to work with recent 4.x kernels
(tested with Debian kernels 4.8 and 4.9 as well as a static,
self-compiled 4.8/4.9 with Gentoo).
Am I completely off base here or just missing something trivial?
BTW: I just tried the same with nftables to no avail:
flush ruleset
table inet firewall {
chain incoming {
type filter hook input priority 0;
ct state established,related accept
log reject
}
chain outgoing {
type filter hook output priority 0;
ct state established,related accept
tcp dport {domain, ftp} accept
udp dport domain accept
log reject
}
}
I still get:
ftp> ls
227 Entering Passive Mode (134,76,12,6,119,247).
ftp: connect: Connection refused
ftp>
and
[ 4594.097676] IN= OUT=eth0 SRC=192.168.137.190 DST=134.76.12.6 LEN=60
TOS=0x00 PREC=0x00 TTL=64 ID=35848 DF PROTO=TCP SPT=58314 DPT=30711
WINDOW=29200 RES=0x00 SYN URGP=0
[ 4595.116297] IN= OUT=eth0 SRC=192.168.137.190 DST=134.76.12.6 LEN=60
TOS=0x00 PREC=0x00 TTL=64 ID=35849 DF PROTO=TCP SPT=58314 DPT=30711
WINDOW=29200 RES=0x00 SYN URGP=0
--
thanks, Micha
next reply other threads:[~2017-02-11 17:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-11 17:14 Michael Weiser [this message]
2017-02-11 22:13 ` Restrictive FTP egress using conntrack helper Robert White
2017-02-12 9:14 ` Pascal Hambourg
2017-02-12 12:30 ` Michael Weiser
2017-02-12 14:19 ` Pablo Neira Ayuso
2017-02-12 15:42 ` Michael Weiser
2017-02-12 11:32 ` Michael Weiser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170211171431.GD31183@weiser.dinsnail.net \
--to=michael@weiser.dinsnail.net \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.