Resolved Juggernaut Security and Firewall Plesk Addon

[MacGyver]

Thank you for your fast reply. This matter is of great concern to our team.

 

[MacGyver]

October 17th is only three weeks away. How do we fix this?

This is clearly still a concern that has not been addressed as the team promised. We received this email from MaxMind Today:

Action Required: Use HTTPS for GeoIP database downloads

Dear MaxMind customer,​ We’re writing to follow up on our email from August. Between September 1 and 18, we saw GeoIP download requests from your account that are not being sent with HTTPS (see details below). To improve our server infrastructure and allow for better performance and efficiency, MaxMind will begin requiring HTTPS for GeoIP download requests in March 2024. To help customers get ready for this change, we will have a planned, temporary enforcement of this policy on October 17, 2023. What is the policy? MaxMind will only accept GeoIP download requests sent with the more secure HTTPS protocol. What do I need to do? To ensure that you can continue to download GeoIP databases, please make the change(s) listed below prior to October 17, 2023. The policies will be permanently enforced in March 2024: You sent 3 GeoIP database download queries to the endpoint http://download.maxmind.com/app/geoip_download. Note that these queries were sent without using the more secure HTTPS protocol. Update your integration to send these GeoIP database download queries to https://download.maxmind.com/app/geoip_download. Note that you should be using the more secure HTTPS protocol. What if I need more help? If you need more help or have additional questions, please contact us at [email protected]. What’s next? On October 17, 2023 we will conduct a planned, temporary enforcement of our API policies. If you have not made the requested changes before this date, you may experience a period in which database download requests fail. We will post additional details about the planned enforcement to our release notes. Thanks for your attention. Sincerely, The Team at MaxMind

 

[danami]

@MacGyver You can see the CSF team reply here: MaxMind DB must be HTTPS starting October - ConfigServer Community Forum

 

[MacGyver]

If there is a solution in there, I'm afraid I don't understand it. Is this going to be fixed before 10/17/2023?

 

[danami]

If you want to apply the fix before the CSF team pushes their own fix then edit the file /usr/local/csf/lib/ConfigServer/Config.pm and change lines 336 to 338 changing http:// to https://:

Before:

$config{cc_country} = "http://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-Country-CSV&suffix=zip&license_key=$config{MM_LICENSE_KEY}";
$config{cc_city} = "http://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-City-CSV&suffix=zip&license_key=$config{MM_LICENSE_KEY}";
$config{cc_asn} = "http://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-ASN-CSV&suffix=zip&license_key=$config{MM_LICENSE_KEY}";

After:

$config{cc_country} = "https://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-Country-CSV&suffix=zip&license_key=$config{MM_LICENSE_KEY}";
$config{cc_city} = "https://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-City-CSV&suffix=zip&license_key=$config{MM_LICENSE_KEY}";
$config{cc_asn} = "https://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-ASN-CSV&suffix=zip&license_key=$config{MM_LICENSE_KEY}";

Then restart LFD:

systemctl restart lfd

 

[MacGyver]

Is this going to be fixed before 10/17/2023?

 

[danami]

Is this going to be fixed before 10/17/2023?

Yes, that's what the CSF team said.

 

[MacGyver]

It's now one week until deadline. Has this been fixed?

Thanks.

 

[danami]

It's now one week until deadline. Has this been fixed?

Yes the fix was pushed automatically last week.

 

[MacGyver]

That's awesome. Thank you so much. Will Juggernaut take this update automatically, or is there anything we need to do?

 

[MacGyver]

What is the best way to view GEO action reports? We have some challenges where at times a client will timeout, and we need a way to verify that they are not being blocked by GEO. When I use a VPN to go to a forbidden GEO location, and then try to access our sites, it gets blocked, but I can't find the IP I was using in the Juggernaut logs.

Thanks in advance.

 

[danami]

That's awesome. Thank you so much. Will Juggernaut take this update automatically, or is there anything we need to do?

No there is nothing that you need to do. CSF updates automatically by default so you already have the fix.

What is the best way to view GEO action reports? We have some challenges where at times a client will timeout, and we need a way to verify that they are not being blocked by GEO. When I use a VPN to go to a forbidden GEO location, and then try to access our sites, it gets blocked, but I can't find the IP I was using in the Juggernaut logs.

Thanks in advance

You can search for the IP address in the IPtables search on the dashboard. If it's being blocked by one of the firewall country blocks then it should tell you. You can also use the following command on the command line:

csf --grep <ip_address>

 

[MacGyver]

That's what I had assumed; however, it doesn't appear in that search. In fact, if I go to the IP Tables log, no blocked countries at all show in the logs, and I know our server gets connect attempts from outside the U.S. consistently if for no other reason than SPAM. That's why we installed Juggernaut.

In this case, I know the IP, but often I won't. I was trying to find a way to go to the logs, and see what IP tried to connect at the time of the failure so I could see if it might be GEO related.

 

[danami]

The ipables log and the dashboard search are not the same. Like I told you before you have to use the Juggernaut dashboard search (Internally it will run the csf --grep command). A country block might have thousands of different subnets in it so CSF has to use ipset NOT iptables . If you use the dashboard it will call csf --grep <ip address> and will search the both iptables and ipsets and give you any matches.

Example from the command line:

# csf --grep 205.210.31.156

Table  Chain            num   pkts bytes target     prot opt in     out     source               destination         
No matches found for 205.210.31.156 in iptables

IPSET: Set:bl_DSHIELD Match:205.210.31.156 Setting:DSHIELD file:/etc/csf/csf.blocklists
IPSET: Set:chain_DENY Match:205.210.31.156 Setting: File:/etc/csf/csf.deny

ip6tables:

Table  Chain            num   pkts bytes target     prot opt in     out     source               destination         
No matches found for 205.210.31.156 in ip6tables

You can list all your ipsets directly using the ipset command also:

ipset list | more

 

[MacGyver]

I did search it that way from the dashboard, and as I mentioned, it did not appear.

That said, even if that would work, I still need a way to see what IPs where blocked in a log when I don't know the IP address to use for a dashboard search.

 

[danami]

>That said, even if that would work, I still need a way to see what IPs where blocked in a log when I don't know the IP address to use for a dashboard search.

The only way to see if an IP address is being blocked is to know the IP address. Just blocking a single country might have thousands of subnets and millions of IP addresses. Just looking at a list of thousands of CIDR notation subnets isn't going to tell you anything useful.

 

[MacGyver]

>The only way to see if an IP address is being blocked is to know the IP address. Just blocking a single country might have thousands of subnets and millions of IP addresses. Just looking at a list of thousands of CIDR notation subnets isn't going to tell you anything useful.

No, but if I have a user here in this office, who is trying to execute a script that is timing out, and we don't know from where the connection originates, then we could look at a log for the exact time of the execution and see if we have a connection that is originating from an IP that we would then whitelist.

That is what was happening last night. Though the script was being run on a server in Chicago, we do not know where the developer's servers are located. We needed to see if perhaps the ftp connection was being blocked by GEO. We have no idea what IP it may use, but we could compare the logs to a time of execution that we could replicate.

 

[danami]

You can easily whitelist your developers IP addresses on the firewall so they never get blocked (even if they have a dynamic IP address). They can sign up to any dynamic DNS service (most routers have this now too). Then the login failure daemon will check if their IP address changes and update it accordingly. You can use Juggernaut -> Allow -> Allow DynDNS and Juggernaut -> Ignore -> Ignore DynDNS depending on your needs. An allowed IP address will bypass any firewall based country blocking.

 

[MacGyver]

>ou can easily whitelist your developers IP addresses on the firewall...

Yes, we do that, but if we don't know what location or IP is being blocked, we can't whitelist it. We have a list of "Trusted Locations" for static ips. On the ones we know about, they are whitelisted. This is not one of our developers. This is not an entity over which we have any control whatsoever.

Let's try this a different way. Let's say that someone here in this country is trying to send me an email, but they're using something like Outlook 365 and we're not getting the emails because Microsoft is sending them through a server in some place like Transylvania. The sender has no way of controlling that, and we have no idea why we're not getting their email. We could have them send several emails in a row, and if we see that it's coming from an IP range in Transylvania, we would be able to diagnose the problem. Yes, I know that MS will use a thousand different addresses, but this is just an example. Last night, a user was trying to set up an automated backup through a third party gaming system. The point is that we need to be able to see what is being blocked in able to diagnose the problem.

 

[danami]

If you really want to log dropped connections from ipset then you can enable drop logging under Settings -> Firewall Settings -> Logging Settings -> Drop IP logging then dropped IP address will show up under Logs -> IPtables log. Just be advised that you will have to turn off Settings -> Tracking Settings -> Port Scan Tracking as you can't have both enabled at the same time.