Hi,
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 public interfaces: eth0
$ firewall-cmd --zone=public --list-all public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: ssh dhcpv6-client ports: 15060/udp 20000-20999/udp 4559/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
Now, I noticed a "war dialer" from Moscow yesterday, who systematically scanned for weak sip accounts from extension 10 to 10000.
$ geoiplookup 46.29.160.140 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, using:
$ firewall-cmd --zone=public --add-rich-rule="rule family='ipv4' source address='46.29.160.140' drop"
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, Pete
On 27.10.2018 15:19, Hans-Peter Jansen wrote:
$ firewall-cmd --zone=public --add-rich-rule="rule family='ipv4' source address='46.29.160.140' drop"
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?
I suspect it would be reasonable to use a separate active zone instead. So you would have public and drop zones active simultaneously. At least I am doing so for trusted IPs allowing extra services access. You would have to make it look like the following:
drop (active) target: default icmp-block-inversion: yes interfaces: sources: 46.29.160.140/32 services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
You may update it on fly and do not commit to permanent because foes IPs would change all the time.
--On Saturday, October 27, 2018 4:19 PM +0200 Hans-Peter Jansen hpj@urpla.net wrote:
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?
Use an ipset rule. It's easy to add and remove lots of IP addresses without changing the firewall. fail2ban can also use ipsets within firewalld. I suggest asking on the fail2ban mailing list to see if someone has a suitable jail definition.
On 27.10.2018 18:07, Kenneth Porter wrote:
--On Saturday, October 27, 2018 4:19 PM +0200 Hans-Peter Jansen hpj@urpla.net wrote:
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?
Use an ipset rule. It's easy to add and remove lots of IP addresses without changing the firewall. fail2ban can also use ipsets within firewalld. I suggest asking on the fail2ban mailing list to see if someone has a suitable jail definition.
Honestly I did not know firewalld has support for ipset. If so then ipset indeed the better way to handle malicious IPs. Here is the brief tutorial from firewalld:
On Samstag, 27. Oktober 2018 20:29:54 Oleg Cherkasov wrote:
On 27.10.2018 18:07, Kenneth Porter wrote:
--On Saturday, October 27, 2018 4:19 PM +0200 Hans-Peter Jansen hpj@urpla.net wrote:
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?
Use an ipset rule. It's easy to add and remove lots of IP addresses without changing the firewall. fail2ban can also use ipsets within firewalld. I suggest asking on the fail2ban mailing list to see if someone has a suitable jail definition.
Honestly I did not know firewalld has support for ipset. If so then ipset indeed the better way to handle malicious IPs. Here is the brief tutorial from firewalld:
Thank you, Kenneth and Oleg, for your hints.
Unfortunately, I still haven't figured out, how to limit a certain service to a couple of source addresses, namely I would like to accept connections on 15060/udp from internal and selected external sources only: e.g. 172.16.123.0/24 and 213.167.161.0/26. It might be possible with ipsets, but no example shows, how to use that as a white list with the destination port requirement.
Any ideas?
TIA, Pete
On 11/6/2018 10:24 AM, Hans-Peter Jansen wrote:
Unfortunately, I still haven't figured out, how to limit a certain service to a couple of source addresses, namely I would like to accept connections on 15060/udp from internal and selected external sources only: e.g. 172.16.123.0/24 and 213.167.161.0/26. It might be possible with ipsets, but no example shows, how to use that as a white list with the destination port requirement.
I have this in direct.xml:
<passthrough ipv="ipv4">-I INPUT 1 -p tcp -m multiport --dports ssh,submission,465,pop3,pop3s,imap,imaps,sieve -m set --match-set BanList src -m conntrack --ctstate NEW -j DROP</passthrough>
BanList is the ipset list of address blocks not allowed to use my authenticated services. Create the ipset first using firewall-cmd or by creating /etc/firewalld/ipsets/BanList.xml with suitable contents.
On Dienstag, 6. November 2018 19:24:09 Hans-Peter Jansen wrote:
On Samstag, 27. Oktober 2018 20:29:54 Oleg Cherkasov wrote:
On 27.10.2018 18:07, Kenneth Porter wrote:
--On Saturday, October 27, 2018 4:19 PM +0200 Hans-Peter Jansen hpj@urpla.net wrote:
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?
Use an ipset rule. It's easy to add and remove lots of IP addresses without changing the firewall. fail2ban can also use ipsets within firewalld. I suggest asking on the fail2ban mailing list to see if someone has a suitable jail definition.
Honestly I did not know firewalld has support for ipset. If so then ipset indeed the better way to handle malicious IPs. Here is the brief tutorial from firewalld:
Thank you, Kenneth and Oleg, for your hints.
Unfortunately, I still haven't figured out, how to limit a certain service to a couple of source addresses, namely I would like to accept connections on 15060/udp from internal and selected external sources only: e.g. 172.16.123.0/24 and 213.167.161.0/26. It might be possible with ipsets, but no example shows, how to use that as a white list with the destination port requirement.
I think, I got it:
$ firewall-cmd --permanent --new-zone=voip $ firewall-cmd --permanent --zone=voip --add-source=172.16.123.0/24 $ firewall-cmd --permanent --zone=voip --add-source=213.167.161.0/26 $ firewall-cmd --permanent --zone=voip --add-source=213.167.162.0/26 $ firewall-cmd --permanent --zone=voip --add-port=15060/udp $ firewall-cmd --permanent --zone=voip --add-port=10000-10099/udp $ firewall-cmd --zone=voip --permanent --list-all voip (active) target: default icmp-block-inversion: no interfaces: sources: 172.16.123.0/24 213.167.161.0/26 213.167.162.0/26 services: ports: 15060/udp 10000-10099/udp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
What I still not grok is the relationship between the different zones, and how overlapping and non-overlapping rules are handled?!?
Because: $ firewall-cmd --get-active-zones voip ...
but I'm still able to use ssh, although it is defined in zone "external"
$ firewall-cmd --zone=external --permanent --list-all external target: default icmp-block-inversion: no interfaces: sources: services: http ports: 4559/tcp 22/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: address-unreachable bad-header beyond-scope communication- prohibited destination-unreachable echo-reply failed-policy fragmentation- needed host-precedence-violation host-prohibited host-redirect host-unknown host-unreachable ip-header-bad network-prohibited network-redirect network- unknown network-unreachable no-route packet-too-big parameter-problem port- unreachable precedence-cutoff protocol-unreachable reject-route required- option-missing source-route-failed time-exceeded timestamp-reply timestamp- request tos-host-redirect tos-host-unreachable tos-network-redirect tos- network-unreachable ttl-zero-during-reassembly ttl-zero-during-transit unknown-header-type unknown-option rich rules:
I can disable/enable nginx: $ firewall-cmd --zone=external --remove-service=http $ firewall-cmd --zone=external --add-service=http
but a command like: $ firewall-cmd --remove-service=http You're performing an operation over default zone ('external'), but your connections/interfaces are in zone 'voip' (see --get-active-zones) You most likely need to use --zone=voip option.
success
After a reboot, things clear up (a bit):
$ firewall-cmd --get-active-zones external interfaces: eth0 voip sources: 172.16.123.0/24 213.167.161.0/26 213.167.162.0/26
but how does firewalld knows, which zones are active? In case of voip, this is controlled from the sources okay, but in case of external, the interface isn't defined in the zone, nor in the interface script (no NetworkManager).
To rephrase my question: what triggers the activeness?
Sorry for these dump questions, but I really try to make up some consistent idea of the inner logical connections, that appear to be important to me, in order to avoid to have applied rules at the wrong places (zones), or, even badder, doesn't have them applied at all!
So, please bear with me, Pete
On Tue, Nov 06, 2018 at 10:49:28PM +0100, Hans-Peter Jansen wrote:
On Dienstag, 6. November 2018 19:24:09 Hans-Peter Jansen wrote:
On Samstag, 27. Oktober 2018 20:29:54 Oleg Cherkasov wrote:
On 27.10.2018 18:07, Kenneth Porter wrote:
--On Saturday, October 27, 2018 4:19 PM +0200 Hans-Peter Jansen hpj@urpla.net wrote:
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?
Use an ipset rule. It's easy to add and remove lots of IP addresses without changing the firewall. fail2ban can also use ipsets within firewalld. I suggest asking on the fail2ban mailing list to see if someone has a suitable jail definition.
Honestly I did not know firewalld has support for ipset. If so then ipset indeed the better way to handle malicious IPs. Here is the brief tutorial from firewalld:
Thank you, Kenneth and Oleg, for your hints.
Unfortunately, I still haven't figured out, how to limit a certain service to a couple of source addresses, namely I would like to accept connections on 15060/udp from internal and selected external sources only: e.g. 172.16.123.0/24 and 213.167.161.0/26. It might be possible with ipsets, but no example shows, how to use that as a white list with the destination port requirement.
I think, I got it:
$ firewall-cmd --permanent --new-zone=voip $ firewall-cmd --permanent --zone=voip --add-source=172.16.123.0/24 $ firewall-cmd --permanent --zone=voip --add-source=213.167.161.0/26 $ firewall-cmd --permanent --zone=voip --add-source=213.167.162.0/26 $ firewall-cmd --permanent --zone=voip --add-port=15060/udp $ firewall-cmd --permanent --zone=voip --add-port=10000-10099/udp $ firewall-cmd --zone=voip --permanent --list-all voip (active) target: default icmp-block-inversion: no interfaces: sources: 172.16.123.0/24 213.167.161.0/26 213.167.162.0/26 services: ports: 15060/udp 10000-10099/udp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
What I still not grok is the relationship between the different zones, and how overlapping and non-overlapping rules are handled?!?
Overlapping zones by sources is undefined. You should avoid creating zones with overlapping "sources".
Interfaces may only be bound to a _single_ zone.
Because: $ firewall-cmd --get-active-zones voip ...
but I'm still able to use ssh, although it is defined in zone "external"
The incoming connection is probably falling through to the "default" (external) zone. You can avoid this by setting the policy (--set-target) of the "voip" to something like "reject" or "drop".
If you're SSHing from an IP _not_ in the sources list for the "voip" zone, then it makes sense that SSH is allowed (no other zone matches).
$ firewall-cmd --zone=external --permanent --list-all external target: default icmp-block-inversion: no interfaces: sources: services: http ports: 4559/tcp 22/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: address-unreachable bad-header beyond-scope communication- prohibited destination-unreachable echo-reply failed-policy fragmentation- needed host-precedence-violation host-prohibited host-redirect host-unknown host-unreachable ip-header-bad network-prohibited network-redirect network- unknown network-unreachable no-route packet-too-big parameter-problem port- unreachable precedence-cutoff protocol-unreachable reject-route required- option-missing source-route-failed time-exceeded timestamp-reply timestamp- request tos-host-redirect tos-host-unreachable tos-network-redirect tos- network-unreachable ttl-zero-during-reassembly ttl-zero-during-transit unknown-header-type unknown-option rich rules:
I can disable/enable nginx: $ firewall-cmd --zone=external --remove-service=http $ firewall-cmd --zone=external --add-service=http
but a command like: $ firewall-cmd --remove-service=http You're performing an operation over default zone ('external'), but your connections/interfaces are in zone 'voip' (see --get-active-zones) You most likely need to use --zone=voip option.
success
After a reboot, things clear up (a bit):
$ firewall-cmd --get-active-zones external interfaces: eth0 voip sources: 172.16.123.0/24 213.167.161.0/26 213.167.162.0/26
but how does firewalld knows, which zones are active? In case of voip, this is controlled from the sources okay, but in case of external, the interface isn't defined in the zone, nor in the interface script (no NetworkManager).
To rephrase my question: what triggers the activeness?
There are various ways a zone becomes active: - The zone is the default zone - The zone has "sources" - If an interface is managed by NetworkManager and assigned to the zone and is "up" and has an IP address - If an interface is NOT managed by NetworkManager, but is added to the zone
Sorry for these dump questions, but I really try to make up some consistent idea of the inner logical connections, that appear to be important to me, in order to avoid to have applied rules at the wrong places (zones), or, even badder, doesn't have them applied at all!
So, please bear with me, Pete
Dear Eric,
thanks for your answers.
On Donnerstag, 8. November 2018 10:34:53 Eric Garver wrote:
On Tue, Nov 06, 2018 at 10:49:28PM +0100, Hans-Peter Jansen wrote:
On Dienstag, 6. November 2018 19:24:09 Hans-Peter Jansen wrote:
What I still not grok is the relationship between the different zones, and how overlapping and non-overlapping rules are handled?!?
Overlapping zones by sources is undefined. You should avoid creating zones with overlapping "sources".
Interfaces may only be bound to a _single_ zone.
Okay, things clear up.
This is, what I have now:
$ firewall-cmd --get-default-zone external
$ firewall-cmd --get-active-zones external interfaces: eth0 voip sources: 172.16.123.0/24 213.167.161.0/26 213.167.162.0/26
$ firewall-cmd --zone=external --permanent --list-all external (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: ports: 22/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" source address="172.16.123.0/24" service name="http" accept rule family="ipv4" source address="172.16.123.0/24" port port="4559" protocol="tcp" accept rule family="ipv4" source address="172.16.123.0/24" port port="19150" protocol="tcp" accept
$ firewall-cmd --zone=voip --permanent --list-all voip (active) target: default icmp-block-inversion: no interfaces: sources: 172.16.123.0/24 213.167.161.0/26 213.167.162.0/26 services: ports: 10000-10099/udp 15060/udp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
Now, this behaves, how I would like it to, but I do have some overlapping sources, once in voip, and those in the external rich rules, and the whole thing starts to feel like I'm misusing the zones concepts again.
But hopefully, this demonstrates, what I'm after.
I'm about to combine these zones into external, using more rich rules, similar to those, that I'm using already, and changing the external target to drop.
Is that considered good practice?
Thanks, Pete
On Donnerstag, 8. November 2018 20:09:07 Hans-Peter Jansen wrote:
I'm about to combine these zones into external, using more rich rules, similar to those, that I'm using already, and changing the external target to drop.
This is, how it looks now:
drop (active) target: DROP icmp-block-inversion: no interfaces: eth0 sources: services: ports: 22/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: address-unreachable bad-header beyond-scope communication-prohibited destination-unreachable echo-reply failed-policy fragmentation-needed host-precedence-violation host-prohibited host-redirect host-unknown host-unreachable ip-header-bad network-prohibited network-redirect network-unknown network-unreachable no-route packet-too-big parameter-problem port-unreachable precedence-cutoff protocol-unreachable reject-route required-option-missing source-route-failed time-exceeded timestamp-reply timestamp-request tos-host-redirect tos-host-unreachable tos-network-redirect tos-network-unreachable ttl-zero-during-reassembly ttl-zero-during-transit unknown-header-type unknown-option rich rules: rule family="ipv4" source address="172.16.123.0/24" service name="http" accept rule family="ipv4" source address="172.16.123.0/24" port port="4559" protocol="tcp" accept rule family="ipv4" source address="172.16.123.0/24" port port="19150" protocol="tcp" accept rule family="ipv4" source address="172.16.123.0/24" port port="15060" protocol="udp" accept rule family="ipv4" source address="172.16.123.0/24" port port="10000-10099" protocol="udp" accept rule family="ipv4" source address="213.167.161.0/26" port port="15060" protocol="udp" accept rule family="ipv4" source address="213.167.161.0/26" port port="10000-10099" protocol="udp" accept rule family="ipv4" source address="213.167.162.0/26" port port="15060" protocol="udp" accept rule family="ipv4" source address="213.167.162.0/26" port port="10000-10099" protocol="udp" accept rule family="ipv4" source address="172.16.123.0/24" icmp-type name="echo-reply" accept rule family="ipv4" source address="172.16.123.0/24" icmp-type name="echo-request" accept
Is that considered good practice?
Thanks, Pete
On Thu, Nov 08, 2018 at 11:32:56PM +0100, Hans-Peter Jansen wrote:
On Donnerstag, 8. November 2018 20:09:07 Hans-Peter Jansen wrote:
I'm about to combine these zones into external, using more rich rules, similar to those, that I'm using already, and changing the external target to drop.
This is, how it looks now:
drop (active) target: DROP icmp-block-inversion: no interfaces: eth0 sources: services: ports: 22/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: address-unreachable bad-header beyond-scope communication-prohibited destination-unreachable echo-reply failed-policy fragmentation-needed host-precedence-violation host-prohibited host-redirect host-unknown host-unreachable ip-header-bad network-prohibited network-redirect network-unknown network-unreachable no-route packet-too-big parameter-problem port-unreachable precedence-cutoff protocol-unreachable reject-route required-option-missing source-route-failed time-exceeded timestamp-reply timestamp-request tos-host-redirect tos-host-unreachable tos-network-redirect tos-network-unreachable ttl-zero-during-reassembly ttl-zero-during-transit unknown-header-type unknown-option rich rules: rule family="ipv4" source address="172.16.123.0/24" service name="http" accept rule family="ipv4" source address="172.16.123.0/24" port port="4559" protocol="tcp" accept rule family="ipv4" source address="172.16.123.0/24" port port="19150" protocol="tcp" accept rule family="ipv4" source address="172.16.123.0/24" port port="15060" protocol="udp" accept rule family="ipv4" source address="172.16.123.0/24" port port="10000-10099" protocol="udp" accept rule family="ipv4" source address="213.167.161.0/26" port port="15060" protocol="udp" accept rule family="ipv4" source address="213.167.161.0/26" port port="10000-10099" protocol="udp" accept rule family="ipv4" source address="213.167.162.0/26" port port="15060" protocol="udp" accept rule family="ipv4" source address="213.167.162.0/26" port port="10000-10099" protocol="udp" accept rule family="ipv4" source address="172.16.123.0/24" icmp-type name="echo-reply" accept rule family="ipv4" source address="172.16.123.0/24" icmp-type name="echo-request" accept
Is that considered good practice?
I don't follow why you have these rich rules instead of just adding the services/ports to your "voip" zone.
Ideally you'd have a zone per logical grouping of source IP address. I think zones setup as below get you what you desire without rich rules.
voip-plus-more (active) target: default icmp-block-inversion: yes interfaces: http sources: 172.16.123.0/24 services: http ports: 10000-10099/udp 15060/udp 4559/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: echo-reply echo-request rich rules:
voip (active) target: default icmp-block-inversion: no interfaces: sources: 213.167.161.0/26 213.167.162.0/26 services: ports: 10000-10099/udp 15060/udp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
drop (active) target: DROP icmp-block-inversion: yes interfaces: eth0 sources: services: ports: 22/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
firewalld-users@lists.fedorahosted.org
-
Eric Garver -
Hans-Peter Jansen -
Kenneth Porter -
Oleg Cherkasov