Reject host(not ip) using firewalld / firewalld.richlanguage
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
Is it possible to add a rule in linux firewalld to reject an entire host(not ip or ip range) ?
For example, I wish to reject all connection coming from my133y.org.
Using firewall rich language I can drop ip, but host rejection is not provided in man pages.
Example to reject ip
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.100.4/24" drop'
when modified to :
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="my133t.org" drop'
I got the error:
Error: INVALID_ADDR: my133t.org
linux centos7 firewalld
New contributor
user3127456 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
1
down vote
favorite
Is it possible to add a rule in linux firewalld to reject an entire host(not ip or ip range) ?
For example, I wish to reject all connection coming from my133y.org.
Using firewall rich language I can drop ip, but host rejection is not provided in man pages.
Example to reject ip
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.100.4/24" drop'
when modified to :
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="my133t.org" drop'
I got the error:
Error: INVALID_ADDR: my133t.org
linux centos7 firewalld
New contributor
user3127456 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Is it possible to add a rule in linux firewalld to reject an entire host(not ip or ip range) ?
For example, I wish to reject all connection coming from my133y.org.
Using firewall rich language I can drop ip, but host rejection is not provided in man pages.
Example to reject ip
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.100.4/24" drop'
when modified to :
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="my133t.org" drop'
I got the error:
Error: INVALID_ADDR: my133t.org
linux centos7 firewalld
New contributor
user3127456 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Is it possible to add a rule in linux firewalld to reject an entire host(not ip or ip range) ?
For example, I wish to reject all connection coming from my133y.org.
Using firewall rich language I can drop ip, but host rejection is not provided in man pages.
Example to reject ip
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.100.4/24" drop'
when modified to :
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="my133t.org" drop'
I got the error:
Error: INVALID_ADDR: my133t.org
linux centos7 firewalld
linux centos7 firewalld
New contributor
user3127456 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
user3127456 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 2 hours ago
Sven♦
83.9k10140195
83.9k10140195
New contributor
user3127456 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 3 hours ago
user3127456
61
61
New contributor
user3127456 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
user3127456 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
user3127456 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
The man page for firewall-cmd tells the facts:
A source address or address range is either an IP address or a network
IP address with a mask for IPv4 or IPv6 or a MAC address or an ipset
with the ipset: prefix. For IPv4, the mask can be a network mask or a
plain number. For IPv6 the mask is a plain number. The use of host
names is not supported.
There's a good reason for this. The firewalld is a packet filter. It compares the packet to the rules it has. The IP packet has both source and destination IP address, but not the host name. Therefore, using the host as a criteria would require gathering additional information from additional sources, namely the domain name system DNS. Such implementation would be vulnerable for denial-of-service attacks as it would be easy to make your server generate new traffic while trying to filter the packets.
Furthermore, while a host name is easy to translate to an IP address by querying for A
records in DNS, detecting all host names for an IP address is not that straightforward. Sure an IP can have a reverse PTR
record, but it's not mandatory nor trustworthy.
E.g. some unified threat management (UTM) solutions with content filters blocks HTTPS traffic based on forbidden host names without encrypting the TLS traffic. This means it can't use the URL, as the HTTP request and its Host:
header are encrypted: it only sees the IP address, just like your firewall. Instead of filtering the content it blocks all HTTPS traffic to that IP address, using a pre-fetched list of IP addresses for that hostname. This is exactly what you must do.
If you really would like to use host names, you would need to query for the IP addresses, first. Say you would like to prevent your employees surfing on serverfault.com
on their precious working hours.
dig +short serverfault.com
- Block those destination IP addresses.
- Repeat this at regular intervals, starting from removing the outdated rules.
It is possible for a hostname to have multiplePTR
records. And https traffic often has the domain name in clear through SNI. But regardless of that, this answer is still pretty much correct on why firewall rules based on hostnames isn't a good idea.
– kasperd
1 hour ago
Thanks, tweaked those details. In what phase of the TLS handshake the information on SNI hostname is shared? Is it possible to read it from the traffic without interfering at all?
– Esa Jokinen
45 mins ago
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
The man page for firewall-cmd tells the facts:
A source address or address range is either an IP address or a network
IP address with a mask for IPv4 or IPv6 or a MAC address or an ipset
with the ipset: prefix. For IPv4, the mask can be a network mask or a
plain number. For IPv6 the mask is a plain number. The use of host
names is not supported.
There's a good reason for this. The firewalld is a packet filter. It compares the packet to the rules it has. The IP packet has both source and destination IP address, but not the host name. Therefore, using the host as a criteria would require gathering additional information from additional sources, namely the domain name system DNS. Such implementation would be vulnerable for denial-of-service attacks as it would be easy to make your server generate new traffic while trying to filter the packets.
Furthermore, while a host name is easy to translate to an IP address by querying for A
records in DNS, detecting all host names for an IP address is not that straightforward. Sure an IP can have a reverse PTR
record, but it's not mandatory nor trustworthy.
E.g. some unified threat management (UTM) solutions with content filters blocks HTTPS traffic based on forbidden host names without encrypting the TLS traffic. This means it can't use the URL, as the HTTP request and its Host:
header are encrypted: it only sees the IP address, just like your firewall. Instead of filtering the content it blocks all HTTPS traffic to that IP address, using a pre-fetched list of IP addresses for that hostname. This is exactly what you must do.
If you really would like to use host names, you would need to query for the IP addresses, first. Say you would like to prevent your employees surfing on serverfault.com
on their precious working hours.
dig +short serverfault.com
- Block those destination IP addresses.
- Repeat this at regular intervals, starting from removing the outdated rules.
It is possible for a hostname to have multiplePTR
records. And https traffic often has the domain name in clear through SNI. But regardless of that, this answer is still pretty much correct on why firewall rules based on hostnames isn't a good idea.
– kasperd
1 hour ago
Thanks, tweaked those details. In what phase of the TLS handshake the information on SNI hostname is shared? Is it possible to read it from the traffic without interfering at all?
– Esa Jokinen
45 mins ago
add a comment |Â
up vote
2
down vote
The man page for firewall-cmd tells the facts:
A source address or address range is either an IP address or a network
IP address with a mask for IPv4 or IPv6 or a MAC address or an ipset
with the ipset: prefix. For IPv4, the mask can be a network mask or a
plain number. For IPv6 the mask is a plain number. The use of host
names is not supported.
There's a good reason for this. The firewalld is a packet filter. It compares the packet to the rules it has. The IP packet has both source and destination IP address, but not the host name. Therefore, using the host as a criteria would require gathering additional information from additional sources, namely the domain name system DNS. Such implementation would be vulnerable for denial-of-service attacks as it would be easy to make your server generate new traffic while trying to filter the packets.
Furthermore, while a host name is easy to translate to an IP address by querying for A
records in DNS, detecting all host names for an IP address is not that straightforward. Sure an IP can have a reverse PTR
record, but it's not mandatory nor trustworthy.
E.g. some unified threat management (UTM) solutions with content filters blocks HTTPS traffic based on forbidden host names without encrypting the TLS traffic. This means it can't use the URL, as the HTTP request and its Host:
header are encrypted: it only sees the IP address, just like your firewall. Instead of filtering the content it blocks all HTTPS traffic to that IP address, using a pre-fetched list of IP addresses for that hostname. This is exactly what you must do.
If you really would like to use host names, you would need to query for the IP addresses, first. Say you would like to prevent your employees surfing on serverfault.com
on their precious working hours.
dig +short serverfault.com
- Block those destination IP addresses.
- Repeat this at regular intervals, starting from removing the outdated rules.
It is possible for a hostname to have multiplePTR
records. And https traffic often has the domain name in clear through SNI. But regardless of that, this answer is still pretty much correct on why firewall rules based on hostnames isn't a good idea.
– kasperd
1 hour ago
Thanks, tweaked those details. In what phase of the TLS handshake the information on SNI hostname is shared? Is it possible to read it from the traffic without interfering at all?
– Esa Jokinen
45 mins ago
add a comment |Â
up vote
2
down vote
up vote
2
down vote
The man page for firewall-cmd tells the facts:
A source address or address range is either an IP address or a network
IP address with a mask for IPv4 or IPv6 or a MAC address or an ipset
with the ipset: prefix. For IPv4, the mask can be a network mask or a
plain number. For IPv6 the mask is a plain number. The use of host
names is not supported.
There's a good reason for this. The firewalld is a packet filter. It compares the packet to the rules it has. The IP packet has both source and destination IP address, but not the host name. Therefore, using the host as a criteria would require gathering additional information from additional sources, namely the domain name system DNS. Such implementation would be vulnerable for denial-of-service attacks as it would be easy to make your server generate new traffic while trying to filter the packets.
Furthermore, while a host name is easy to translate to an IP address by querying for A
records in DNS, detecting all host names for an IP address is not that straightforward. Sure an IP can have a reverse PTR
record, but it's not mandatory nor trustworthy.
E.g. some unified threat management (UTM) solutions with content filters blocks HTTPS traffic based on forbidden host names without encrypting the TLS traffic. This means it can't use the URL, as the HTTP request and its Host:
header are encrypted: it only sees the IP address, just like your firewall. Instead of filtering the content it blocks all HTTPS traffic to that IP address, using a pre-fetched list of IP addresses for that hostname. This is exactly what you must do.
If you really would like to use host names, you would need to query for the IP addresses, first. Say you would like to prevent your employees surfing on serverfault.com
on their precious working hours.
dig +short serverfault.com
- Block those destination IP addresses.
- Repeat this at regular intervals, starting from removing the outdated rules.
The man page for firewall-cmd tells the facts:
A source address or address range is either an IP address or a network
IP address with a mask for IPv4 or IPv6 or a MAC address or an ipset
with the ipset: prefix. For IPv4, the mask can be a network mask or a
plain number. For IPv6 the mask is a plain number. The use of host
names is not supported.
There's a good reason for this. The firewalld is a packet filter. It compares the packet to the rules it has. The IP packet has both source and destination IP address, but not the host name. Therefore, using the host as a criteria would require gathering additional information from additional sources, namely the domain name system DNS. Such implementation would be vulnerable for denial-of-service attacks as it would be easy to make your server generate new traffic while trying to filter the packets.
Furthermore, while a host name is easy to translate to an IP address by querying for A
records in DNS, detecting all host names for an IP address is not that straightforward. Sure an IP can have a reverse PTR
record, but it's not mandatory nor trustworthy.
E.g. some unified threat management (UTM) solutions with content filters blocks HTTPS traffic based on forbidden host names without encrypting the TLS traffic. This means it can't use the URL, as the HTTP request and its Host:
header are encrypted: it only sees the IP address, just like your firewall. Instead of filtering the content it blocks all HTTPS traffic to that IP address, using a pre-fetched list of IP addresses for that hostname. This is exactly what you must do.
If you really would like to use host names, you would need to query for the IP addresses, first. Say you would like to prevent your employees surfing on serverfault.com
on their precious working hours.
dig +short serverfault.com
- Block those destination IP addresses.
- Repeat this at regular intervals, starting from removing the outdated rules.
edited 48 mins ago
answered 2 hours ago
Esa Jokinen
21.4k23057
21.4k23057
It is possible for a hostname to have multiplePTR
records. And https traffic often has the domain name in clear through SNI. But regardless of that, this answer is still pretty much correct on why firewall rules based on hostnames isn't a good idea.
– kasperd
1 hour ago
Thanks, tweaked those details. In what phase of the TLS handshake the information on SNI hostname is shared? Is it possible to read it from the traffic without interfering at all?
– Esa Jokinen
45 mins ago
add a comment |Â
It is possible for a hostname to have multiplePTR
records. And https traffic often has the domain name in clear through SNI. But regardless of that, this answer is still pretty much correct on why firewall rules based on hostnames isn't a good idea.
– kasperd
1 hour ago
Thanks, tweaked those details. In what phase of the TLS handshake the information on SNI hostname is shared? Is it possible to read it from the traffic without interfering at all?
– Esa Jokinen
45 mins ago
It is possible for a hostname to have multiple
PTR
records. And https traffic often has the domain name in clear through SNI. But regardless of that, this answer is still pretty much correct on why firewall rules based on hostnames isn't a good idea.– kasperd
1 hour ago
It is possible for a hostname to have multiple
PTR
records. And https traffic often has the domain name in clear through SNI. But regardless of that, this answer is still pretty much correct on why firewall rules based on hostnames isn't a good idea.– kasperd
1 hour ago
Thanks, tweaked those details. In what phase of the TLS handshake the information on SNI hostname is shared? Is it possible to read it from the traffic without interfering at all?
– Esa Jokinen
45 mins ago
Thanks, tweaked those details. In what phase of the TLS handshake the information on SNI hostname is shared? Is it possible to read it from the traffic without interfering at all?
– Esa Jokinen
45 mins ago
add a comment |Â
user3127456 is a new contributor. Be nice, and check out our Code of Conduct.
user3127456 is a new contributor. Be nice, and check out our Code of Conduct.
user3127456 is a new contributor. Be nice, and check out our Code of Conduct.
user3127456 is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f936415%2freject-hostnot-ip-using-firewalld-firewalld-richlanguage%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password