Using iptables along with firewalld
I'm running Tumbleweed and using firewalld. If I want to block some incoming IP addresses and I add iptables reject rules will that work to block them? I do a iptables -L and iptables appears to be available. I have my reasons for wanting to use iptables for this blocking.
On 8/8/24 8:42 PM, Curtis J Blank wrote:
I'm running Tumbleweed and using firewalld. If I want to block some incoming IP addresses and I add iptables reject rules will that work to block them?
I do a iptables -L and iptables appears to be available.
I have my reasons for wanting to use iptables for this blocking.
I am not that familiar with firewalld, though I do use it on Tumbleweed. Others will have to fill in specifics, but generally when you have an app managing iptables, which I presume firewalld does similar to ipset or nftables, then you have to be careful writing iptables rules manually. (firewalld uses nftables sets) At least with ipset/nftables/fail2ban there is a careful ordering of "sets" so it all works together. You will have your blocklists (blacklist/whitelist ordered first) and then whatever stateful rules the firewall manager uses next. If you go in and just add a DROP rule, it may come after all other rules and essentially be ignored. I'll have to look more into how firewalld does things. A good nuts-and-bolts reference is: https://wiki.archlinux.org/title/Firewalld -- David C. Rankin, J.D.,P.E.
On 2024-08-08 19:42, Curtis J Blank wrote:
I'm running Tumbleweed and using firewalld. If I want to block some incoming IP addresses and I add iptables reject rules will that work to block them?
I do a iptables -L and iptables appears to be available.
I have my reasons for wanting to use iptables for this blocking. I don't know what reasons you might have for wanting to use iptables, but I wouldn't recommend it. With firewalld, it is easy to set up a rule (called an IPset) that will block as many ip addresses as you want, all with just one rule. In addition to the URL David Rankin gave, the official firewalld documentation is at https://firewalld.org/documentation/ I suggest using the firewalld GUI: in the application launcher, go to System/ and run Firewall. You will need the root password.
I said I had reasons. For one it be kind of difficult to have a program that runs in real time monitoring network hacking attempts use a GUI per your suggestion to add a rule to block the IP address of the perpetrator. This is a very dynamic application that responds and blocks these attempts typically within 2 seconds. It's written to use iptables and it does checks to see if a rule already exists for the IP address in question and if it is active or not, if not it is added. So rewriting it to use firewalld it would need to be able to do that and at the moment I'm not familiar enough with firewalld to know how to get a list of these rules that are in place in real time for that check. The rules are not permanent that is by design and are cleared by the nature of a reboot. Previous rules can be added on boot if the necessity arises.
On Aug 8, 2024, at 22:50, Darryl Gregorash <raven@accesscomm.ca> wrote:
On 2024-08-08 19:42, Curtis J Blank wrote:
I'm running Tumbleweed and using firewalld. If I want to block some incoming IP addresses and I add iptables reject rules will that work to block them?
I do a iptables -L and iptables appears to be available.
I have my reasons for wanting to use iptables for this blocking. I don't know what reasons you might have for wanting to use iptables, but I wouldn't recommend it. With firewalld, it is easy to set up a rule (called an IPset) that will block as many ip addresses as you want, all with just one rule. In addition to the URL David Rankin gave, the official firewalld documentation is at https://firewalld.org/documentation/ I suggest using the firewalld GUI: in the application launcher, go to System/ and run Firewall. You will need the root password.
On 2024-08-08 23:13, Curtis J Blank wrote:
I said I had reasons. For one it be kind of difficult to have a program that runs in real time monitoring network hacking attempts use a GUI per your suggestion to add a rule to block the IP address of the perpetrator. This is a very dynamic application that responds and blocks these attempts typically within 2 seconds. I didn't say that firewalld runs inside a GUI, only that it is easier to set up the IPsets in the GUI. Firewalld itself runs as a systemd service. But from what you say now, it seems likely that you should stick with what you know, since it's working for you now. You should be aware that firewalld and iptables appear to work independently of each other; therefore, what is done when you add a new rule in iptables isn't even known to firewalld. At this point, I suggest you stick with what you know -- do everything in iptables, and leave firewalld alone until you have had a chance to study it and learn how to do what you want with it.
PS, it is not necessary to send me a personal copy of your replies. In fact, I would prefer if you do not send any to me.
I do use firewalld on this server although in reality I probably don't really need to. I have multiple VLANs and everything is behind a pfSense router NAT'd and blocked and passed as needed. This server is my postfix, imap and apache server so as such when I see hackers or script kitties trying to find vulnerabilities I block 'em. When creating this new server using Tumbleweed I looked into doing this blocking using firewalld instead of iptables. But it wasn't readily apparent to me how to get a list of rules listed out that I had put in to do the blocking. Putting the rules in command line seemed straight forward but not listing them out. And as mentioned I don't want the blocks to be --permanent so I saw that option but I failed to find the equivalent of "iptables -L -n" to get a human readable list of the actual active rules. These log & block rules are in the iptables INPUT table and are the only thing is all of iptables. My server hard failed and I was in a pinch to get its replacement online mainly for my email.
On Aug 9, 2024, at 02:41, Darryl Gregorash <raven@accesscomm.ca> wrote:
On 2024-08-08 23:13, Curtis J Blank wrote:
I said I had reasons. For one it be kind of difficult to have a program that runs in real time monitoring network hacking attempts use a GUI per your suggestion to add a rule to block the IP address of the perpetrator. This is a very dynamic application that responds and blocks these attempts typically within 2 seconds. I didn't say that firewalld runs inside a GUI, only that it is easier to set up the IPsets in the GUI. Firewalld itself runs as a systemd service. But from what you say now, it seems likely that you should stick with what you know, since it's working for you now. You should be aware that firewalld and iptables appear to work independently of each other; therefore, what is done when you add a new rule in iptables isn't even known to firewalld. At this point, I suggest you stick with what you know -- do everything in iptables, and leave firewalld alone until you have had a chance to study it and learn how to do what you want with it.
PS, it is not necessary to send me a personal copy of your replies. In fact, I would prefer if you do not send any to me.
On 8/9/24 9:32 PM, Curtis J Blank wrote:
I do use firewalld on this server although in reality I probably don't really need to. I have multiple VLANs and everything is behind a pfSense router NAT'd and blocked and passed as needed. This server is my postfix, imap and apache server so as such when I see hackers or script kitties trying to find vulnerabilities I block 'em.
When creating this new server using Tumbleweed I looked into doing this blocking using firewalld instead of iptables. But it wasn't readily apparent to me how to get a list of rules listed out that I had put in to do the blocking. Putting the rules in command line seemed straight forward but not listing them out.
And as mentioned I don't want the blocks to be --permanent so I saw that option but I failed to find the equivalent of "iptables -L -n" to get a human readable list of the actual active rules. These log & block rules are in the iptables INPUT table and are the only thing is all of iptables.
My server hard failed and I was in a pinch to get its replacement online mainly for my email.
Oh... I feel your pain! The absolute best solution I've found is iptables, ipset and fail2ban. Others will promote nftables as covering most of that -- and it does (ipset is part of nftables -- from the same folks) I just like putting the individual pieces together myself. (see https://wiki.archlinux.org/title/Ipset - which also links to nftables, https://wiki.archlinux.org/title/Simple_stateful_firewall, and https://wiki.archlinux.org/title/Fail2ban which cover the basics) fail2ban is amazing. It manages ban lists (jails) that are just ipset(s), so it integrates seamlessly with other ipset(s) you want to maintain. I set fail2ban to trigger after 3 attempts in 30 minutes. Not perfect with all the kiddies using proxies to show up from multiple IPs, but not bad either. When triggered the IP is banned for 48 hours. I also have 3 ipset sets I maintain beyond the fail2ban jails. Named "blocklist" where ip blocks in CIDR format are blacklists, a "whitelist" for whitelisting IP addresses and "whilelistnet" where I whitelist ip blocks in CIDR format. Configuring iptables, fail2ban and ipset isn't that bad, but it does get a bit tedious and in-the-weeds. The basic idea is you set up fail2ban, it manages its jails -- pretty simple to do. You create your ipset(s) and then configure iptables to order the rules so they all work together. A simple iptables.rules files sewing all the pieces together with a fail2ban jail for dovecot and postfix can look something like: # Generated by iptables-save v1.8.10 on Fri Apr 12 02:16:54 2024 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [301459:354292940] :TCP - [0:0] :UDP - [0:0] :f2b-dovecot - [0:0] :f2b-postfix - [0:0] -A INPUT -m set --match-set whitelistnet src -j ACCEPT -A INPUT -m set --match-set whitelist src -j ACCEPT -A INPUT -m set --match-set blocklist src -j DROP -A INPUT -p tcp -m multiport --dports 110,995,143,993,587,465,4190 -j f2b-dovecot -A INPUT -p tcp -m multiport --dports 25,465,587 -j f2b-postfix -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable -A TCP -p tcp -m tcp --dport 80 -j ACCEPT -A TCP -p tcp -m tcp --dport 443 -j ACCEPT -A TCP -p tcp -m tcp --dport 993 -j ACCEPT -A TCP -p tcp -m tcp --dport 587 -j ACCEPT -A TCP -p tcp -m tcp --dport 25 -j ACCEPT -A TCP -p tcp -m tcp --dport 53 -j ACCEPT -A TCP -p tcp -m tcp --dport 5432 -j ACCEPT -A TCP -p tcp -m tcp --dport 445 -j ACCEPT -A TCP -p tcp -m tcp --dport 143 -j ACCEPT -A UDP -p udp -m udp --dport 53 -j ACCEPT -A f2b-dovecot -j RETURN -A f2b-postfix -j RETURN COMMIT # Completed on Fri Apr 12 02:16:54 2024 It can always be improved upon, but does the job. You can see how fail2ban (f2b) jails are list first, then my ipset(s) whitelistnet whitelist and blocklist come next, and then fail2ban ports, a semi-stateless set of rules along with ports to open. Compared to simply trying to ban offending blocks with iptables alone -- this is a quantum improvement. (though I do still swing a pretty big ban-hammer for LATNIC, APNIC and AFRINIC ip blocks in the "blocklist") Lately, it's not uncommon to have fail2ban ban 20-50 IPs a day. (you get a whois report from fail2ban which is nice). If it's from an address block I don't do business with and isn't one cloud providers user -- the address block is added to the blocklist manually -- and I never have to deal with them again. Latin American, whether by proxy or otherwise, has become as big a problem as China and the old Soviet block countries during the past year or two. I even had an idiot try an intrusion with conspiracy Musk's Starlink network. No matter what you use, it's still a game of whack-a-mole. The more whacking the tools can do just means less I have to do. Choose the tools that suit your needs and preferences the best. -- David C. Rankin, J.D.,P.E.
On 2024-08-09 09:41, Darryl Gregorash wrote:
On 2024-08-08 23:13, Curtis J Blank wrote:
I said I had reasons. For one it be kind of difficult to have a program that runs in real time monitoring network hacking attempts use a GUI per your suggestion to add a rule to block the IP address of the perpetrator. This is a very dynamic application that responds and blocks these attempts typically within 2 seconds. I didn't say that firewalld runs inside a GUI, only that it is easier to set up the IPsets in the GUI.
There are also CLI commands to interact with firewalld. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-08-13 06:38, Carlos E. R. wrote:
On 2024-08-09 09:41, Darryl Gregorash wrote:
I didn't say that firewalld runs inside a GUI, only that it is easier to set up the IPsets in the GUI.
There are also CLI commands to interact with firewalld.
Doesn't "easier to set up in the GUI" say precisely the same thing?
On 2024-08-13 16:43, Darryl Gregorash wrote:
On 2024-08-13 06:38, Carlos E. R. wrote:
On 2024-08-09 09:41, Darryl Gregorash wrote:
I didn't say that firewalld runs inside a GUI, only that it is easier to set up the IPsets in the GUI.
There are also CLI commands to interact with firewalld.
Doesn't "easier to set up in the GUI" say precisely the same thing?
The OP is doing some kind of dynamic blocking of bad hosts, from some kind of script. That means a GUI is not viable. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 09.08.2024 04:42, Curtis J Blank wrote:
I'm running Tumbleweed and using firewalld. If I want to block some incoming IP addresses and I add iptables reject rules will that work to block them?
In most cases, yes.
I do a iptables -L and iptables appears to be available.
I have my reasons for wanting to use iptables for this blocking.
Thanks. I gave it a try. It does work. And saved me a lot of work. I'm willing to push the envelope and work outside the box... 😄
On Aug 8, 2024, at 22:58, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On 09.08.2024 04:42, Curtis J Blank wrote:
I'm running Tumbleweed and using firewalld. If I want to block some incoming IP addresses and I add iptables reject rules will that work to block them?
In most cases, yes.
I do a iptables -L and iptables appears to be available. I have my reasons for wanting to use iptables for this blocking.
participants (5)
-
Andrei Borzenkov -
Carlos E. R. -
Curtis J Blank -
Darryl Gregorash -
David C. Rankin