SRX Services Gateway
Reply
Contributor
Gorf
Posts: 43
Registered: ‎08-04-2010
0
Accepted Solution

How to handle blocking massive ranges of IP's

I'm running into a little issue here, as part of our contract with some of our game developers we block IP ranges that are tied to different countries.  However out of those blocks very specific IP addresses have to be allowed.  For instance, in one of our US datacenters we host a Chinese game developer's game.  We want to prevent a number of asian countries from accessing it (as best as is possible...) but need to allow the Chinese developer access to it. 

 

This is pretty trivial in our OpenBSD firewalls.  We just create a table with the list of IP's to block, and in that table just simply add the negator to the /32 address we want to be exempt from the table.  However I have yet to come up with a good solution in my SRX650's.  Filling an address-set doesn't seem to work as it looks like an address-set won't hold enough entries and seems to lack the ability to negate addresses from the ranges I put in.

 

Any ideas?

Distinguished Expert
aarseniev
Posts: 1,722
Registered: ‎08-21-2009
0

Re: How to handle blocking massive ranges of IP's

Hello,

It depends on how you define "blocking".

If you don't want sending TCP RST or ICMP Unreach then You can just null-route the unwanted contiguous IP ranges.

If the ranges are not contiguous then I'd suggest to use a firewall filter to discard the packets on ingress.

If You wish to send TCP RST or ICMP Unreach then FW filter with "reject" action will accomplish that but I don't recommend it because "rejecting" large amount of packets is an attack vector under DoS/DDoS conditions.

HTH

Rgds

Alex

___________________________________
Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Contributor
Gorf
Posts: 43
Registered: ‎08-04-2010
0

Re: How to handle blocking massive ranges of IP's

So specifically they look like this (china example):

 

 

58.14.0.0/15
58.16.0.0/16
58.17.0.0/17
58.17.128.0/17
58.18.0.0/16
58.19.0.0/16
<...snipping about 1200 entries...>
222.249.160.0/20
222.249.176.0/20
222.249.192.0/18

 

Now image that I have a couple dozen lists of addresses like above for various other countries.  But say out of that first block of 58.14.0.0/15 I need to specifically allow 1 or 2 addresses in.  I don't need to send back RST or anything, just black-holing the connection if fine. BUT I can't configure a route that will affect everything.  Since we host like 20 games, those same address blocks shouldn't be blocked for access to other ports.

 

Distinguished Expert
aarseniev
Posts: 1,722
Registered: ‎08-21-2009
0

Re: How to handle blocking massive ranges of IP's

Hello,

I think this should help. I use TCP port 80 in this example and ge-0/0/0.0 is the ingress interface for TCP/80 traffic from China:

 

 

root@CRAIG# show | compare 
[edit interfaces ge-0/0/0 unit 0 family inet]
+       filter {
+           input block.cn;
+       }
[edit policy-options]
+   prefix-list block.cn {
+       58.14.0.0/15;
+       58.16.0.0/16;
+       58.17.0.0/17;
+       58.17.128.0/17;
+       58.18.0.0/16;
+       58.19.0.0/16;
+   }
+   prefix-list unblock.cn {
+       58.14.1.1/32;
+       58.14.2.2/32;
+   }
[edit]
+  firewall {
+      family inet {
+          filter block.cn {
+              term 1 {
+                  from {
+                      source-prefix-list {
+                          block.cn;
+                          unblock.cn except;
+                      }
+                      protocol tcp;
+                      destination-port 80;
+                  }
+                  then {
+                      discard;
+                  }
+              }
+              term 2 {
+                  then accept;
+              }
+          }
+      }
+  }

 

HTH

Regards

Alex

 

___________________________________
Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Contributor
Gorf
Posts: 43
Registered: ‎08-04-2010
0

Re: How to handle blocking massive ranges of IP's

Oh man that is bad ass.  Thanks!!

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.