Hello, Le dimanche 01 septembre 2013 à 17:11 +1000, Nick Edwards a écrit : > Hi Eric, > > Thank you for that, one thing though on PREROUTING, is that just extra > security, not critical for ftp to work,or not really needed after I > fix my forwarding rule up. FORWARD changes are not needed at a functional level. It is a security improvement. Using CT target in PREROUTING (raw) to affect helper to flow will be needed once the automatic helper affectation will be disabled by default. > As you can tell I'm far from an expert, but since the CT line wouldnt > take with IPv6, I am assuming it is not critical to its functioning > (bless I hit a IPv6 bug) CT target is working with IPv6. The same change will needs to be made. BR, > Thanks > > > > > > > On 8/31/13, Eric Leblond <eric@xxxxxxxxx> wrote: > > Hello, > > > > Le samedi 31 août 2013 à 16:09 +1000, Nick Edwards a écrit : > >> Hi, > >> This message is now appearing on some of our servers.. > >> google is full of much info, and confusion. > > > > This is linked with the document that can be found here: > > https://home.regit.org/netfilter-en/secure-use-of-helpers/ > > > > Don't hesitate to command this document if you find some part needs > > explanation. > > > > The change in automatic helper assignment is motivated by an attack > > found on helper and implemented in the tool named opensvp: > > > > https://home.regit.org/2012/06/opensvp-a-new-tool-to-analyse-the-security-of-firewalls-using-algs/ > > > >> I understand it to be > >> iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT > >> becomes > >> iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT > >> > >> with new rules to add being > >> -A FORWARD -m conntrack --ctstate RELATED -m helper --helper ftp -p > >> tcp --dport 21 -j ACCEPT > > > > This change you have just described is a security improvement. By the > > way, it should not work. The last rule you wrote states that packets > > RELATED to a connection, going to port 21 and linked with the FTP helper > > have to be accepted. This is not what you want as port 21 is the > > original connection. > > > > A correct rule will be something like > > iptables -A FORWARD -m conntrack --ctstate RELATED -m helper \\ > > --helper ftp -p tcp \\ > > --dport 1024: -j ACCEPT > > > > You accept all packets RELATED to an ftp connection on port > 1024. If > > you know where the FTP connection took place, you can add more filter to > > discriminate the flow. > > > >> then some sites talk about > >> -A PREROUTING -t raw -p tcp --dport 21 -j CT --helper ftp > > > > Here, you say: traffic to port 21 IS FTP. This will mimic the current > > behavior of helper (automatic assignement) and this only rule (without > > the previously mentioned change) will allow you to support the future > > change to non automatic assignment (assuming you only need the ftp > > helper on your system). > > > >> > >> So, does removal of ESTABLISHED on original rules, now mean we need > >> one of, of both of, these new rules? > >> > >> I tried on our IRC server, but it balked with ip6tables at xt_CT: No > >> such helper "irc" > >> same command with iptables seemed to take.. > >> > >> What is the correct way to replace this ESTABLISED since nf_conntrack > >> will soon be removed > > > > No removal of nf_conntrack is planned. The only change planned is the > > removal of automatic assignement ie 21->ftp helper is used. > > > >> > >> Are they even needed anymore? (I think irc helper is only needed for dcc > >> etc) > >> is FTP still needed for ftp? > > > > As mentioned before NO change on helper logic. They are still needed to > > handle protocol with dynamic connection opening. > > > > BR, > > -- > > Eric > >
Attachment:
signature.asc
Description: This is a digitally signed message part
