Geo-Blocking Test

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.

Toshi

<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  220.242.212.254

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 220.242.212.254.
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.

Ahmad

You may use GeoIP override to temporarily assign some safe/controlled by you IP address to RU category and try accessing it. 

You can only do it in CLI:

https://docs.fortinet.com/document/fortigate/6.0.0/cli-reference/717251/system-geoip-override

Thank you all for the great replies and suggestions!

Here are our planned policies. Do they look like they'd block all communication to and from the Geo-Block address group countries?

Outgoing Policy:
Name: Geo-Block - Outgoing
Incoming Interface: LAN1
Outgoing Interface: WAN1
Source: all
Destination: Geo-Block address group
Schedule: always
Service: ALL
Action: Deny

Incoming Policy:
Name: Geo-Block - Incoming
Incoming Interface: WAN1
Outgoing Interface: LAN1
Source: Geo-Block address group
Destination: all
Schedule: always
Service: ALL
Action: Deny

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.

Toshi

Thank you Toshi. 

No, we are not aware of any attacks from Russia, we just want to protect ourselves just in case.

There is no VIP, and to our knowledge we don't have any local-in policies.

In light of this, does it make sense that this policy below is sufficient and should work?

Outgoing Policy:
Name: Geo-Block - Outgoing
Incoming Interface: LAN1
Outgoing Interface: WAN1
Source: all
Destination: Geo-Block address group
Schedule: always
Service: ALL
Action: Deny

If you just want to block somebody inside of your network from getting to those country's destinations, that should do it when you put it above all LAN1->WAN1 policies.

Toshi

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.

Yuri

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.

Toshi