x-forward-for and Firewalld
Is it possible to set Firewalld to block traffic based on an x-forward-for value?
Thanks
Responses
This will require packet/protocol inspection which to my knowledge isn't supported out of the box with firewalld/iptables. Blocking traffic based on this value sounds like it may be an architecture issue, can you not block the traffic at the point that the x-forward-for header is injected?
Definitely interested if someone can provide a supported DPI solution on RHEL.
Google suggests iptables can do this with a string match on the data portion of the packet:
iptables -I INPUT 1 -p tcp --dport 80 -m string --algo bm --string 'X-Forwarded-For:' -j DROP
So just change that syntax into a firewalld direct rule:
firewall-cmd --direct --add-rule ipv4 filter INPUT_direct 10 -p tcp --dport 80 -m string --algo bm --string 'X-Forwarded-For:' -j DROP
This is valid firewall syntax though I don't have a webserver and client to test it. I'm not sure how much this will affect performance, the firewall is now performing an inspection of every incoming packet. At some point it will get too computationally expensive to do this.
You are probably better to handle this at the application layer with a reverse proxy or webserver configuration.
I would be very careful attempting to block traffic using the basic string matching capability. From the netfilter documentation:
Please do use this match with caution. A lot of people want to use this match to stop worms, along with the DROP target. This is a major mistake. It would be defeated by any IDS evasion method.
In a similar fashion, a lot of people have been using this match as a mean to stop particular functions in HTTP like POST or GET by dropping any HTTP packet containing the string POST. Please understand that this job is better done by a filtering proxy. Additionally, any HTML content with the word POST would get dropped with the former method. This match has been designed to be able to queue to userland interesting packets for better analysis, that's all. Dropping packet based on this would be defeated by any IDS evasion method.
Source: http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.18
In the 'X-Forwarded-For' example, if you were carrying out basic string match against an address with the 'X-Forwarded-For', manipulation of the header (even as simple as adding spacing) will evade the check.
You are probably better to handle this at the application layer with a reverse proxy or webserver configuration.
Agree with this! Or block it at the network layer before it gets to whichever device is adding the X-Forward-For header.
That seems too reactionary to me. Someone sends you a request you don't like. When you see the successful request in the logs, you block the person. Shouldn't it have been stopped earlier than that? Like before the request succeeded?
I'm still in favor of either configuring the httpd to reject these requests, or block them at a reverse proxy. A quick Google search turns up several ways to block this with an nginx reverse proxy before the real httpd.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
