We are in the process of testing firewall policies meant to geo-block certain countries such as Russia. Is it possible for us to test this geo-blocking? So far, the traffic for the geo-block policy is showing 0 B of traffic, and we aren't sure if this means the policy isn't working, or if we simply aren't communicating with Russian networks.
We considered just going to a Russian government website, but given the current security situation with Russia, this seemed potentially risky.
What kind of policy did you applied Geo-blocking? An out-to-in policy to block access to a server behind or a local-in policy to block attacks AT the FGT? And, are you sure attacking from Russia actually happening? Easiest way to test is to geo-block traffic from your own country at night or whenever it's safe.
We recently had an incident one of our servers got SYN flood attacks from all over the worlds. We applied a combination of Geo-blocking (about a dozen countries) and subnet blocking where we can't do geo-blocking like Amazon's or Google's IPs. It has rescued the server and I'm seeing reasonable amount of traffic xxMB with those blocking policies.
<Edit> Forgot to mention, make sure you're not coming through the interface for your admin access when you apply geo-blocking for your own country to the interface for obvious reason.
Here is the idea you can test the geo-IP policies: 1. Locate one unused port on the Fortigate, let`s assume that the unused port is port5
2. Run this command in the cli of the Fortigate: diag firewall ipgeo ip-list RU
This command will give you the list of IPs associated with the Russia.
3. Pick one IP address from these ranges, let`s say 188.8.131.52
4. Connect a router or any other firewall to the unused port of the Fortigate.
5. Connect a PC to that router or firewall. Setup should be like this:
PC---router or firewall-----[port5]Fortigate[LAN]----Destination server 6. Configure NAT on the router or firewall so the connections coming from the PC towards the Destination Server will be SNATed to 184.108.40.206. 7. Configure a GEO-IP policy from port5 to lan, that denies access from a certain geo-ip.
8. Trigger traffic from the PC towards to the Destination Server.
Outgoing is a regular firewall policy but incoming needs to be applied to local-in policy unless you have VIP policies and those attacks come through the policy to hit your internal servers. If that's the case you need to place the blocking policy above VIP policies, which was our case I mentioned before.
Local-in policies are for protecting the Fortigate itself, as when someone is trying to break into the Fortigate, and not servers behind it. Problems with Local-in policies are:
Custom rules are done in CLI, and are NOT seen in GUI, which may mislead/confuse future Fortigate admins.
Making a mistake, as you mentioned in the 1st post, may lock out legit admins from accessing the FGT and there will be no easy way to undo it unless someone accesses the FGT via console.
The bottom line: if you are doing it "just in case", the Local-in policy is better be left alone. The policies you created: WAN to LAN -> block, and LAN to WAN -> block, should be enough for the case in question.
I have a different view about local-in policies from Yuri's. If you're a reasonable FW admin, the behavior of local-in policy is reliable enough not to block yourself out. We use it all FGT installations.
Besides, local-in policy is a 'must' in retail and other business situations, which requires compliance to PCI-DSS including pen-test against FWs that are facing the internet.
So at least you shouldn't be afraid of using this important feature when you need it.