This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Fixing UTM, Topic #3, The Difficulty of Blocking Hostile IPs

There are several common problems created by the lack of integration between the proxies and the firewall rules.  Here is one of them. 

Suppose you use the logs to determine that some remote IP addresses are actively probing or attacking your network, so you want to block all traffic with them.  You cleverly create a network group called "Hostile IPs" for this purpose.   How many places does it need to be configured?

  • Firewall rules:   
    From Any to Hostile IPs, any port, BLOCK
    From Hostile IPs to ANY, any port, BLOCK

  • Standard Web Proxy:
    Need to modify EVERY Filter Action to block by DNS name and IP, using either the website block list by RegEx, website block list by Domain, or tags.  Since tags can be created for name and IP in one step, it might be easiest. 
    You cannot use the "Hostile IPs" Network Group at all.   
    You cannot specify a network range, but you might be able to approximate an IP range using regular expressions.   
    It will be challenging to keep these entries synchronized over time with the Hostile IPs list, because the configuration must be replicated to any new Filter Actions created in the future. 

  • Transparent Web Proxy:
    Option 1:   Use the same mechanism as for Standard Web.
    Option 2 (easier): Add the "Hostile IPs" object to the Transparent Mode Skip list.  This causes the packet to be handled by the firewall rules, where it will be blocked by the rules created above.

  • FTP Proxy (Standard/Transparent/Both):
    Add the "Hostile IPs" object to the (FTP) transparent Mode Skip List.  Do NOT check the box to allow FTP traffic.   Packets will be handled by the firewall where it will be blocked.

  • EMail Proxy:
    Under Relaying tab, add  the "Hostile IPs" object to the Blocked Hosts/Networks list.

  • Generic Proxy:
    If  used for outbound, not needed, as the proxy connects to a designated list of hosts.
    If used for inbound, "Allowed Networks" will need to be reworked to create a hole in the network ranges so that the Hostile IPs are not allowed.    

  • Socks Proxy: 
    Not appropriate for inbound traffic.
    Not restrictable for outbound traffic.

  • WAF
    On EVERY Site Path Routing object, enable "Access Control", and add the "Hostile IPs" object to the Denied list. 
    Needs to be replicated to any new Site Path Routing objects that are created in the future.

  • VPN (Client and Site-to-Site)
    Firewall rules will apply.

This is a simple task in every other firewall product.   It could be and should be in UTM as well.



This thread was automatically locked due to age.
Parents
  • I dont know but one IP pissed me of every day last month on port 22 (to be precise 46.17.96.12). Maybe the owner is in this forum
    What I did?

    I created a DNAT rule:
    From any using (tcp/udp 22) Change to 46.17.96.12

    And I masquerade ANY network ty my WAN (to get DNAT work)
    So, all who will try my port 22 will go to this NL ip 

Reply
  • I dont know but one IP pissed me of every day last month on port 22 (to be precise 46.17.96.12). Maybe the owner is in this forum
    What I did?

    I created a DNAT rule:
    From any using (tcp/udp 22) Change to 46.17.96.12

    And I masquerade ANY network ty my WAN (to get DNAT work)
    So, all who will try my port 22 will go to this NL ip 

Children
No Data