Some of my servers have kernels built by a cloud provider which, does not have
security tables available and have nf_conntrack_* modules builtin.
When I could, I updated the kernel, as recently suggested to another user in
But, the doesn't looks like a solution for kernel we can't update.
Moreover, these tables looks not mandatory to firewalld and limit the use of
firewalld where iptables could be used.
Would you like to accept patches which make:
- security tables optional;
- support kernel with builtin network modules ?
Side question: Why is firewalld altering ipXtables when the backend is
Sébastien "Seblu" Luttringer
I have set up firewalld to forward any incoming udp port 162 traffic to a remote server. I would like to add a second rule to forward udp port 162 traffic from a specific source IP to a different destination address, but it seems it will only match the first rule it finds.
Is this possible?
new here and a newbie, when it comes to using firewalld. After setting up my
first firewalld system yesterday, I came across the first issue today.
The system act as an asterisk host, based on openSUSE 15.0, using
firewalld-0.5.4 (for now).
Since the provider doesn't support SIPS, and I was bitten already from SIP
misuse before, and given, that Asterisks security mechanics aren't that shiny
(with chan_sip at least), I established a couple of measures to reduce the
risk to be misused:
* SIP port is relocated to a non standard port
* complex sip extensions and passwords
The box sits behind a router, that is dealing with other VoIP accounts
already. Therefore, RTP port range is relocated as well. The firewalld setup
on this box is looking like this:
$ firewall-cmd --get-active-zones
$ firewall-cmd --zone=public --list-all
services: ssh dhcpv6-client
ports: 15060/udp 20000-20999/udp 4559/tcp
Now, I noticed a "war dialer" from Moscow yesterday, who systematically
scanned for weak sip accounts from extension 10 to 10000.
$ geoiplookup 126.96.36.199
GeoIP Country Edition: RU, Russian Federation
GeoIP City Edition, Rev 1: RU, 48, Moscow City, Moscow, 101752, 55.752201,
37.615601, 0, 0
GeoIP ASNum Edition: AS51659 LLC Baxet
Since I knew, my setup was safe, I tried to stop that guy with firewalld,
$ firewall-cmd --zone=public --add-rich-rule="rule family='ipv4' source
but this hadn't any effect. Guess, because port 15060/udp was allowed before.
Is there any way to order the firewalld rules somehow?
This might be interesting to be used within a fail2ban procedure later on.
While at it, what is the best practice to limit access to such a port like
15060/udp to a couple of sources?
Thanks in advance,