I have been working on a new project which is to provide a service that would allow you to peer with my router over BGP. My router would then advertise a list of bogons and known malicious networks including botnet command and control networks. You can then drop these networks at your border router thus protecting your network from attacks and saving precious router and firewall resources. Right now I am not offering the peering service but I do have a route-view server available that allows you to login and get a full list of the malicious ip networks for ipv6 and ipv4. To access the router please ssh to rviews.techinvasion.net. If you have ipv6 access there is a AAAA record as well, allowing you to access the router on both ipv4 and ipv6.

The command limits the number of ssh attempts per minute per source ip to 2. Just enough incase you make a mistake during login, but not enough for a script kiddie to run 500 attacks a minute against your firewall.

services {
   ssh {
     rate-limit 2;
  }
}

The important part here is I wanted to create a web form which requests the internal and external address ranges of anyones network. Once that person submits that information I will have a Peal script pull those messages from the web form, parse the information, insert the networks and IP addresses into a J-Script template and apply it to my Juniper SRX router automatically.

This project will enable Cisco and Juniper students to participate in the environment and create a public VPN network where p2p APPS and anything else can run over the network without having to worry about any prying eyes. I want to see how far this project will scale. I was even envisioning a time when other people with idle equipment can volunteer to become a secondary hub to take some of the load once my connection reaches 10 thousand or so tunnels. Because of the way DMVPN works. The tunnels between sites will open up as needed when a user from site A needs to talk to site B. This combined with using BGP as the routing protocol will mean that it will require very little bandwidth as traffic destined from site A to C will not transit site B if site B in this scenario is the hub.

Anyways if anyone out there is interested please leave a comment.

Juniper is also big on naming things, in JUNOS everything has a name, the Filter Lists have names, the terms in the Filter Lists have names, and even the address’s you are matching on have names. This is a big concept in JUNOS because it allows you to write snippets of Filter-Lists and use them for many different Filter Lists. JUNOS also supports grouping Filter Lists and applying an entire group of filter to an interface. If you apply Filter groups to a JUNOS interface they individual Filter Lists are evaluated in order sequentially.

To facilitate out discussion of Filter-Lists let’s take a look at a standard anti-spoofing access list which would be applied to most edge routers. First let’s talk about what a vanilla anti-spoofing ACL should contain! A standard ACL at a minimum should block all RFC-1918 address space from the internet, it should also block undesirable types of ICMP traffic, and depending on the setup should block packets with illegal combinations of TCP flags set, for example packets with the SYN-FIN flag set at the same time or FIN-URG-PSH or URG-ACK-PSH-RST-SYN-FIN at the same time. All of these combinations of TCP flags are illegal and should never be together as part of a legitimate packet. So without further ado lets talk about Filter Lists.
Filter Lists are defined under the Firewall section of the JUNOS configuration. Prefix Lists which are groups of networks, IP address ranges, or single hosts such as 1.1.1.1/32 are defined in these lists. These lists can later be used in as many Filter Lists as you define.

Below I will show you the actual Filter Lists as it looks in the configuration and some of the commands to create the list. For brevity I have opted to only show some of the commands used in creating the list as they are basically repetitive. The important thing to remember is that like all Access-Lists the terms in the Filter List are evaluated from top to bottom so it is important that the last term be an allow all statement otherwise the anti-spoofing filter will block all communication even legitimate communication.

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 192.168.0.0/16

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 172.16.0.0/12

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 10.0.0.0/8

[edit]
john# edit firewall

[edit firewall]
john# edit filter anti-spoofing

[edit firewall filter anti-spoofing]
john# edit term block-rfc1918

[edit firewall filter anti-spoofing term block-rfc1918]
john# set from source-prefix-list rfc1918-prefix-list

[edit firewall filter anti-spoofing term block-rfc1918]
john# set then log discard

[edit]
john# show policy-options

prefix-list rfc1918-prefix-list {
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;
}

[edit firewall]
john# show

filter anti-spoofing {
    term block-rfc1918 {
        from {
            source-prefix-list {
                rfc1918-prefix-list; ## 'rfc1918-prefix-list' is not defined
            }
        }
        then {
            log;
            discard;
        }
    }
    term block-fin-urg-psh {
        from {
            protocol tcp;
            tcp-flags fin,psh,urg;
        }
        then {
            log;
            discard;
        }
    }
    term block-syn-fin {
        from {
            protocol tcp;
            tcp-flags fin,syn;
        }
        then {
            log;
            discard;
        }
    }
    term block-urg-ack-syn-fin-rst-psh {
        from {
            protocol tcp;
            tcp-flags urg,ack,psh,rst,fin,syn;
        }
        then {
            log;
            discard;
        }
    }
    term block-icmp {
        from {
            protocol icmp;
            icmp-type-except echo-reply,unreachable,source-quench,time-exceeded;
        }
        then {
            log;
            discard;
        }
    }
    term accept-all {
        then accept;
    }
}

Remember to apply the Filter-List to the interface with the following command:

[edit]
john#set interfaces fe-0/0/0.0 family inet filter input anti-spoofing

Here is a related Article on ACL’s

Now I thought this would be an easy job, configure the Juniper to connect to our checkpoint r55 box the same as the pix had done before! Man was I surprised to realize that the Juniper did not like the r55. The r55 sends proxy id’s through the tunnel for every device connecting. Now the interesting this is that the r55 uses the supernet for the address requesting access through the vpn. On the cisco pix and asa devices, this does not much matter. So for instance if you hav 10.0.0.0/24, 172.16.2.0/23 and 192.168.0.0/24 on 1 side all trying to access a remote site through the Juniper, the checkpoint send the juniper proxy id’s for each of those networks. Now like I said the cisco determines what traffic matches the tunnel with access-lists and doesn’t much care what the proxy ID says. The juniper on the other hand does! If it sees a proxy id for say a host that is not part of the tunnel, it will tear down the tunnel!!!!  

You can imagine this is a big problem. So what has to be done is that you have to go to autoike and add a gateway for each network that is on the other side. Make sure you also go to advanced and select the checkbox for proxy ID. Once this box is checked enter the information for source and destination. the best way to do this is to check the event logs on the junipers and put in exactly what it says the received proxy ID is.

Once you do this the tunnel will come up. the only other issue is to go to the network –> routing __> destination tab and add a route for each network that you need to go to the tunnel interface.

Thats it, 6 hours of work and the answer was very simple once you figure it out.