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@xxxxxxxxxx>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> 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
++++++++++++++++++++++++++++++++++++++++
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
