Great, thanks! It looks like I will survive even if they drop "iptables-service" in some future to come. Just for my understanding which of the following is incorrect: 1. firewalld is a front end to the iptables kernel module (pretty much as "iptables-service" is) 2. therefore the rules syntax is pretty much the same (well, is pretty close), only in config file(s) all is wrapped into xml (to please GUI front end used by GUI people). 3. in the past we had both kernel module and front end written by the same team of programmers (iptables), from now on we are using front end by one team of programmers for kernel module written by another team. Thanks for all your help in understanding where do we stand now! Valeri On Tue, August 12, 2014 10:58 am, Jonathan Billings wrote: > On Tue, Aug 12, 2014 at 09:59:17AM -0500, Valeri Galtsev wrote: >> >> Wonderful! >> >> Can you do with firewalld an equivalent of the following done with >> iptables: >> >> :SSHSCAN - [0:0] >> -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN >> -A SSHSCAN -m recent --set --name SSH >> -A SSHSCAN -m recent --update --seconds 300 --hitcount 10 --name SSH -j >> DROP >> -A INPUT -p tcp --dport 22 -j ACCEPT > > Yes, I believe that's possible with the 'firewall-cmd --direct > --addchain ...' and 'firewall-cmd --direct --add-rule ...' syntax: > > # firewall-cmd --permanent --direct --add-chain ipv4 filter SSHSCAN > success > # firewall-cmd --permanent --direct --add-rule ipv4 filter IN_public_allow > -p tcp --dport 22 -m state --state NEW -j SSHSCAN > success > # firewall-cmd --permanent --direct --add-rule ipv4 filter IN_public_allow > 0 -p tcp --dport 22 -m state --state NEW -j SSHSCAN > success > # firewall-cmd --permanent --direct --add-rule ipv4 filter SSHSCAN 0 -m > recent --set --name SSH > success > # firewall-cmd --permanent --direct --add-rule ipv4 filter SSHSCAN 1 -m > recent --update --seconds 300 --hitcount 10 --name SSH -j DROP > success > # firewall-cmd --permanent --direct --add-rule ipv4 filter IN_public_allow > 1 -p tcp --dport 22 -j ACCEPT > success > > This has the handy side-effect of being able to just drop this in > /etc/firewalld/direct.xml: > > # cat /etc/firewalld/direct.xml > <?xml version="1.0" encoding="utf-8"?> > <direct> > <chain table="filter" ipv="ipv4" chain="SSHSCAN"/> > <rule priority="0" table="filter" ipv="ipv4" chain="IN_public_allow">-p > tcp --dport 22 -m state --state NEW -j SSHSCAN</rule> > <rule priority="1" table="filter" ipv="ipv4" chain="IN_public_allow">-p > tcp --dport 22 -j ACCEPT</rule> > <rule priority="0" table="filter" ipv="ipv4" chain="SSHSCAN">-m recent > --set --name SSH</rule> > <rule priority="1" table="filter" ipv="ipv4" chain="SSHSCAN">-m recent > --update --seconds 300 --hitcount 10 --name SSH -j DROP</rule> > </direct> > > > You could also make sure that it's added to other zones other than > 'public' (by using something other than IN_public_allow). > > This is a *great* example of why firewalld wins over the old > monolithic /etc/sysconfig/iptables. It's just a file I can manage > with my CM tools. Changes to other firewall rules (such as allowing > in port 80 for web servers) doesn't rewrite editing this file. > > > -- > Jonathan Billings <billings at negate.org> > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++