On Sunday, November 04, 2012 04:23:59 PM Csordás Csaba Ifj. wrote: > Hi List, > > I would like to ask you about the correctness of the information > published in a blog (www.sns.ias.edu/~jns/wp) around 2006. > > The rules in the FTP part of the document seems too lazy for me and > the ICMP rules seems also "uncommon". But most probably _I'm wrong_ > and need to further investigate. When allowing conns, you need only specify port 21 when you have the FTP helper running. (These two rules normally include port 115 for sftp which is why I use 'multiport'.) # Allow all outbound client ftp conns to remote servers (actually a # conn to anything listening on port 21, FTP or not). iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 21 \ -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT # Allow only related inbound (s)ftp conns to local clients iptables -A INPUT -i eth0 -p tcp -m multiport --sports 21 \ -m state --state RELATED,ESTABLISHED -j ACCEPT The forward chain uses similar rules when passing packets between two interfaces. The FTP helper recognizes when the first packet of a new FTP DATA conn is related to an existing FTP CTRL conn, regardless of the DATA packet's src & dest ports. This scheme works just great when allowing conns through the firewall. [Digression] The scheme falls down when using the 'time' functions to shut down existing conns. At least I haven't found a way to tell a rule to include *established conns related to this rule*. Once a conn becomes ESTABLISHED, the DATA conn's relation to its CTRL conn is lost; that is, it is no longer RELATED. Thus, these rules: # Allow all outbound client ftp packets to remote servers. But first reject # them Mondays from 2AM to 5AM and reset the TCP conn.* iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 21 \ -m time --timestart 02:00:00 --timestop 05:00:00 --weekdays Mon \ -m state --state NEW,RELATED,ESTABLISHED -j REJECT --reject-with tcp-reset iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 21 \ -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT # Allow only related/est'ed inbound ftp packets to local clients, but reject # them Mondays from 2AM to 5AM iptables -A INPUT -i eth0 -p tcp -m multiport --sports 21 \ -m time --timestart 02:00:00 --timestop 05:00:00 --weekdays Mon \ -m state --state RELATED,ESTABLISHED -j REJECT --reject-with tcp-reset iptables -A INPUT -i eth0 -p tcp -m multiport --sports 21 \ -m state --state RELATED,ESTABLISHED -j ACCEPT will reset only existing CTRL conns--and block new conn attempts--Mondays 2AM-5AM. If you add port 20, they'll handle ACTV data conns. But while they can block new PASV conns, they can never see existing PASV data conns to reset them *because the ports in use cannot be known to the netfilter rules*. Yes, I know I could use CONNMARKs to mark related conns, but that's a lot of extra rules. There should be a packet/conn state, perhaps something like RELCONN, that essentially says, "this rule also applies to packets belonging to conns that were RELATED to this rule." With such states, netfilter firewalls would become much more solid in that while it is important to allow and block unwanted new connections, it is also important to be able to implement time-based access controls that can allow new connections and immediately sever existing connections. This can't be done right now in all cases. N * Actually, the rejection process is more involved. If it's an established TCP conn, it gets reset. Otherwise (UDP/GRE/etc., SYN) it gets an ICMP admin- prohibited packet. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
