Country Blocking and SMTP traffic

You need good log analysis tools to understand the consequences, since it blocks all traffic on all ports.

Recommend deploying both standard and transparent web proxies before you start.  The proxy logs provide url and country name, while the firewall log does not, so you want as much data as possible in the web logs.   Replace transparent host skip lists with exclude-everything exceptions for the same reason.

Transparent web includes traffic for antivirus, remote PC access, and autoupdate, and other fat client apps, much of which is https using IP addresses rather than fqdn, so partitioning traffic between proxies helps to reverse engineering what a blocked entry represents.

Some resources float around the world.   We have had great difficulty getting TeamViewer to work, because we have not been able to create a sufficient exclude list.

Standard web dproxy ignores country blocking exceptions, and many entries do not get a country code.   Level 3 support is investigating.  Use URL filtering exceptions as a workaround.   This disables more than country checks, which is unfortunate, but it allows more powerful exclude strategies.  You can exlude all of TeamViewer.com using a website exception that assigns a tag to the company name and all subdomains.   Regex is also an option, but more error prone.   Country blocking exceptions have to be network objects, so you cannot whitelist an entire company based on  DNS domain.

Inbound country blocking has fewer issues because they tend to be devices that are logically fixed in the internet geography.

Good luck.

I analyzed that one DVR was opening  connection with China. NO DynDns no Internet DNAT or open ports.

The DVD says in the label Made In China.

What I have to analyse more to block China?

I analyzed that one DVR was opening  connection with China. NO DynDns no Internet DNAT or open ports.

The DVD says in the label Made In China.

What I have to analyse more to block China?

I had a devil of a job with this. I had some spam coming from Japan and blocked it. Problem solved.

Then all of a sudden I had mail bouncing from a key partner because they were using a Trendmicro spam solution which bounced our mail because the Trendmicro server (in Japan) couldn't connect back to us for one of their spam checks.

I think at the time, we asked for an exception (if country blocking was enabled) for any mail that was sent to XXX, that a reply/response wouldn't be blocked for a limited period.

eg so even if Japan was blocked, if we sent a mail to mailserver spamserver.japan.com, that mail server could respond rather than get blocked outright by country blocking.

My approach:

1. If you have a small home network or a tiny business network, you may be able to review all of your logs visually.   I am assuming that most networks will generate logs that are too big for reliable review using visual methods.
   
   
2. Begin the country blocking rollout with two assumptions:
   1. The network is currently clean, so existing traffic is harmless (but not necessarily essential.)
   2. We have no need to communicate with high-risk country X, so we should block future traffic to or from there
      
      
3. It would be immediately useful to capture your existing traffic to prove those assumptions.   Web logs can do this if you have one or both proxies enabled, but the firewall logs cannot.   So the launch sequence involves (a) deploying Web Proxy with logging, (b) reviewing the logs to see if you have any allowed traffic with country X, and (c) implementing appropriate exceptions for the desired traffic.
   
   
4. You could, of course, skip step 2 and proceed directly to blocking country X.   The firewall log will show anything blocked because of country blocking, but not the country name.  If you have only blocked one country, this is easy.   If you block more than one country at once, it gets more complicated.
   
   
5. Once you start blocking country X, it becomes necessary to see what is blocked, then evaluate whether it should remain blocked or be whitelisted.   If a whitelist is needed, you also need to determine the scope of that whitelist.   Figuring out the appropriate whitelist entry can be challenging.
   
   
6. The bigger problem with the firewall logs is when you see a blocked connection from 192.168.1.15:10101 to 215.14.99.33:45454.  What installed application or business function does this represent?  Reverse DNS is worth checking, but often is of little value.    If it is web traffic that you can capture in the web logs, the URL information is much more useful .  For Windows PC, running "netstat -a -b -n" may help with this process, if the originating process is still active when you do your check.
   
   
7. Within the web logs, the challenge is to separate user-initiated browser traffic from everything else.   As I indicated earlier, "everything else" is a lot more stuff than I ever expected, and it often uses IP addresses instead of URLs.   So if your Antivirus software is blocked because it cannot connect to 99.99.99.99 and 201.201.101.101, what is the complete list of addresses that it will try in the future?   I found that using both proxy modes was a big help, because most browser traffic used the standard proxy, and most non-browser traffic use the transparent proxy.

At this point, you start discovering that Microsoft telemetry is sending a lot of data to *nexus*.live.com on servers scattered all over the world.   Should this be always allowed, always blocked, or allowed on the occasions that it picks an allowed country.  Web sites that you trust are using tracking services and content networks that pull data from all over the world.   It is easy to hate tracking services, but how do you predict whether blocking the foreign component will break a website that your user needs?

It is messy, but possible.   I have been surprised by how rarely our users notice and complain.

To cut things short. I have nothing in contrary  with your approach, BUT
The question was about allowing one service or port, no web no webcam, blogs, vpn etc from/or to that country!

Here a Screenshot of my Firewall Log for Port TCP/3389 (I suppose you know what it is and has nothing to do with other services, just Firewall)

This Port its not even open in my side

Sorry.  Not the first time that I have been told my long answer did not address the correct question.

So I think the correct question is:

You want to block one device (the DVR) from reaching China, and you know the port that it uses.

Ideas:

• Turn on transparent web so you know whether it is using a fixed URL, variable URL, fixed IP, or variable IP  (as well as whether the port is fixed, which sounds likely).
• It will help for the DVR to have a fixed IP.   I think UTM can do this by assigning an IP to a MAC address.   If addresses are assigned somewhere else, look for a way to create a DHCP reservation.
• If the destination address or destination port is fixed, you should be able to create a firewall rule to block traffic from <DVR source IP> to <any>:<known port> or <known ip>:<any port>.  (This does not require country blocking).
• To do country blocking for everything except port 9999, you would have to create service objects for 1:9998 and 1000:65535.   Then create a country blocking exception for those port ranges.

One question
I have to much SMTP attempts to relay from my IP, from one Country.
Should i see web logs etc. ? My DHCP doesnt give IP to not known MAC's

We are seeing this as well.   There is also a huge spike in password guessing attacks in remote access devices.  

Hopefully your UTM does not allow authenticated relay at all, and only allows unauthenticated relay from your internal mail servers.  If this is true, the attacks will never succeed, and they can be ignored.   Nothing can be done to prevent their packets from arriving.   To minimize overhead, you could disable logging of those failures.

The more important defense is 2factor authentication for remote access, probably coupled with country blocking for incoming traffic to your remote access ports.