Cloudflare & UFW

[Onlyme]

Hi guys,

I'm ruining apache, mod_Remoteip to show all correct IPs in apache logs.

Ufw setup:
Deny all incoming
Allow Outgoing
Allow ssh

I've used a script to only allow cloudflares IP range to my server on port 80 & 443.

cloudflare-ufw/cloudflare-ufw.sh at master · marlon07021/cloudflare-ufw

Script to update UFW with Cloudflare IPs. Contribute to marlon07021/cloudflare-ufw development by creating an account on GitHub.

github.com

My problem is when I manually ban an IP
Example: sudo ufw deny from 95.468.1.5 to any

Why can that IP still vist my site? It's banned from ssh and like I said apache is logging the correct IP.

 

[Jeremy P]

Apache is receiving the IP via a special header, the connection itself is made via Cloudflare. The only IPs going through your firewall are Cloudflare IPs, so you would have to block the IP at the Cloudflare level.

 

[Onlyme]

Apache is receiving the IP via a special header, the connection itself is made via Cloudflare. The only IPs going through your firewall are Cloudflare IPs, so you would have to block the IP at the Cloudflare level.

I was expecting that answer, but wanted to ask just to make sure.

This is disappointing as it makes some fail2ban jails for Apache useless.

 

[m1ne]

An alternative would be to use ConfigServer Firewall. Blocked IP's can be synced with CloudFlare both ways.

 

[eva2000]

This is disappointing as it makes some fail2ban jails for Apache useless.

not really, fail2ban can be configured to talk to Cloudflare Firewall via CF Firewall API. That's what I do for my fail2ban nginx implementation with a Cloudflare Firewall API based action/unban configuration

CF Firewall API has 3 levels

1. User Level https://api.cloudflare.com/#user-level-firewall-access-rule-properties
2. Account Level https://api.cloudflare.com/#account-level-firewall-access-rule-properties
3. Organization Level https://api.cloudflare.com/#organization-level-firewall-access-rule-properties

Most folks including me have done fail2ban to CF Firewall API via User level API but Cloudflare is deprecating that User Level API as it only supports Cloudflare Global API keys which give users access to entire Cloudflare Account and not newer Cloudflare API Tokens which you can generate to restrict them to specific Cloudflare features instead of entire account.

Cloudflare is deprecating User level Firewall API in favour of Account level Firewall API which supports both Global API Keys as well as newer CF API tokens. I'm testing my fail2ban Cloudflare Firewall API with my updated changes to support CF Account level Firewall API with CF API tokens

 

[eva2000]

My problem is when I manually ban an IP
Example: sudo ufw deny from 95.468.1.5 to any

Why can that IP still vist my site?

manual ban via ufw or via fail2ban. Those are 2 separate issues. Fail2ban can be configured to read your web server logs and get IPs to ban and then if configured you can tell fail2ban to talk to Cloudflare Firewall via API to pass that IP ban to Cloudflare's edge Firewall to block a visitor on that IP.

But manual ban via native system firewalls/wrappers like ufw, iptables, firewalld, csf firewall etc won't work as system doesn't have a way to natively translate visitor real IP to the system native firewall system. Native firewalls will only see Cloudflare's server IP as it lacks the ability to restore a visitor's real IP when behind Cloudflare as a reverse proxy like you can at web server/log level which can restore the visitor's real IP via https://support.cloudflare.com/hc/e...ing-visitor-IP-addresses-with-mod-cloudflare-

When behind Cloudflare, if you want to be able to ban visitor IPs manually via native system firewalls, you would need a separate script/solution which can interface with Cloudflare Firewall's API so you ban/unban IP actions are passed on to Cloudflare Firewall. I wrote a separate custom CF Firewall API script which can do bans/unbans by IP, IP ranges and even unban based on IP ban age just for that purpose outside of fail2ban + Cloudflare firewall usage.

 

[eva2000]

An alternative would be to use ConfigServer Firewall. Blocked IP's can be synced with CloudFlare both ways.

read the CSF Firewall readme documentation, it's integration with Cloudflare is fairly limited to specific use cases https://download.configserver.com/csf/readme.txt

27. CloudFlare
##############

This features provides interaction with the CloudFlare Firewall.

As CloudFlare is a reverse proxy, any attacking IP addresses (so far as
iptables is concerned) come from the CloudFlare IP's. To counter this, an
Apache module (mod_cloudflare) is available that obtains the true attackers
IP from a custom HTTP header record (similar functionality is available
for other HTTP daemons.

However, despite now knowing the true attacking IP address, iptables cannot
be used to block that IP as the traffic is still coming from the CloudFlare
servers.

CloudFlare have provided a Firewall feature within the user account where
rules can be added to block, challenge or whitelist IP addresses.

Using the CloudFlare API, this feature adds and removes attacking IPs from that
firewall and provides CLI (and via the UI) additional commands.

There are several restrictions to using this feature:

1. All lfd blocks will be temporary blocks so that csf/lfd can keep blocks in
sync with CloudFlare

2. Automatic blocks via lfd are limited to LF_MODSEC and LF_CXS triggers as
only through these can the domain name be determined. Any users that own
domains that are involved in the trigger will get a block in their
CloudFlare Firewall. Additionally, any users with the special case "any"
will also get blocks

3. The temporary/permanent config of the lfd settings are ignored and CF_TEMP
is used instead

4. LF_TRIGGER must not be used, the feature will not work with it enabled

5. mod_cloudflare or similar must be used to report real IP in the Apache logs

6. URLGET must be set to 2 (i.e. LWP) must be used

7. If PERMBLOCK is used, the last tempblock will remain and never be cleared.
So any CloudFlare Firewall entries must be manually cleared in CloudFlare
or via CLI

8. There are restrictions imposed by CloudFlare to the number of rules that
can be created depending on the type of account used. See
https://goo.gl/ssGu7v for more information

9. When restarting csf, any old temporary blocks will still be created for lfd
to clear when it restarts

10. All interaction with CloudFlare is at User-level, not Zone-level

11. If using the CloudFlare cPanel user plugin, it must be v7+

CF_TEMP should be configured taking into account the maximum number of rules
that the CloudFlare account allows: https://goo.gl/ssGu7v

All CloudFlare users for the domains that are involved in LF_MODSEC and
LF_CXS triggers will have a CloudFlare rule added. Any CloudFlare account
configured to use the special case "any" field value in csf.cloudflare will
have a CloudFlare rule added regardless of domain.

NOTE: You should always list the CloudFlare IP addresses in /etc/csf/csf.ignore
to prevent them from being blocked by lfd from https://www.cloudflare.com/ips/

specifically 7 to 11

7. If PERMBLOCK is used, the last tempblock will remain and never be cleared.
So any CloudFlare Firewall entries must be manually cleared in CloudFlare
or via CLI

8. There are restrictions imposed by CloudFlare to the number of rules that
can be created depending on the type of account used. See
https://goo.gl/ssGu7v for more information

9. When restarting csf, any old temporary blocks will still be created for lfd
to clear when it restarts

10. All interaction with CloudFlare is at User-level, not Zone-level

11. If using the CloudFlare cPanel user plugin, it must be v7+

CF_TEMP should be configured taking into account the maximum number of rules
that the CloudFlare account allows: https://goo.gl/ssGu7v

All CloudFlare users for the domains that are involved in LF_MODSEC and
LF_CXS triggers will have a CloudFlare rule added. Any CloudFlare account
configured to use the special case "any" field value in csf.cloudflare will

again #10 CSF Firewall native Cloudflare uses User level Firewall API and requires using Global API Key with full access to your CF account and all sites within that CF account instead of CF API Tokens and which Cloudflare will eventually deprecate the User level Firewall API.

#7 restriction means you need a separate tool/script to purge and remove those tempblocks which never clear from Cloudflare's Firewall