SRX

do some one know how to block https website on juniper srx 100 like facebook  or gmail chat.i spoke to  jtec support team they are denying it,can any one had done it on srx 100

Hello there,

You can do it in several ways:

1/  DNS doctoring (make your SRX return 127.0.0.1 for *.facebook.com) - SRX must be inline for DNS requests-replies

This will block HTTP and HTTPS acccess to Facebook  but I guess you don't need HTTP acccess to Facebook either?

2/ write an IDP policy which matches on SSL Client Hello extension "server_name" and sends a TCP RST if this extension contains "*.facebook.com"

3/ most crude method - write a prefix-list which contains Facebook prefixes (below is from whois query I executed few mins ago)

Facebook, Inc. TFBNET2 (NET-69-63-176-0-1) 69.63.176.0 - 69.63.191.255

 -- and block TCP port 443 outbound towards these prefixes, using output FW filter.

As for gmail chat, I guess blocking gmail access altogether (which is over HTTPS anyway) shoul do:

Name:		gmail.com
IP:		74.125.230.119, 		74.125.230.117, 		74.125.230.118, 		74.125.230.120

HTH

Rgds

Alex 

---

@aarseniev wrote:

1/  DNS doctoring (make your SRX return 127.0.0.1 for *.facebook.com) - SRX must be inline for DNS requests-replies

This will block HTTP and HTTPS acccess to Facebook  but I guess you don't need HTTP acccess to Facebook either?

---

Would you be able to provide a configuration example of DNS doctoring, aarseniev?  Although the documentation alludes to such a feature it doesn't give any instructions on configuring it.

Thanks.

Sure

http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/release-notes/10.1/topic-42298.html#jd0e9757

DNS doctoring support—This feature is supported on all SRX Series and J Series devices.

Domain Name System (DNS) ALG functionality has been extended to support static NAT. You should configure static NAT for the DNS server first. Then if the DNS ALG is enabled, public-to-private and private-to-public static address translation can occur for A-records in DNS replies.

Basically, DNS doctoring is DNS ALG+static NAT for DNS server IP and IPs in A-replies. DNS ALG is enabled by default, only thing to configure is static NAT entries + address-book entries.

Also, from 11.1 there are 2 additional knobs for DNS doctoring :

http://www.juniper.net/techpubs/en_US/junos11.1/information-products/topic-collections/release-notes/11.1/topic-53320.html#rn-junos-srx-j-CIDBS

The restoring/doctoring is performed in two parts:

    Packet sanity check
    NAT

Doctoring feature is disabled by using the two new CLI commands listed below:

    set security alg dns doctoring none – This command disables all the doctoring features.
    set security alg dns doctoring sanity-check – This command disables the NAT feature and retains the sanity-check feature.

However, DNS doctoring is successful only for non-clued-up (non-privileged) users who don't know how to (or cannot)  change/manually assign DNS server in their PCs. Clued-up privileged user could simply re-point his/her PC to any public Internet DNS server (e.g. Google DNS 8.8.8.8/8.8.4.4) so one has to block DNS packets outbound to internet as well.

There are ways around this as well (using non-standard DNS port, using public VPN servers etc) but it is even more complicated.

HTH

Rgds

Alex

Hi Alex,

Your ideas for blocking a particular site are really very interesting, I did not think
of it that way! But can you clarify some points please?

1) How should SRX be configured to return 127.0.0.1 for particular site (e.g. *.facebook.com)?
From what is seen in the doc/ release notes, this feature is rather dumb and does not
allow fine-tuning. DNS proxy is also not working on SRX now, AFAIK.

2) Do you have an example of IDP policy of that sort? The name of the site is sent
in header unencrypted, so there is no problem here, but from what I can see (in custom
IDP attack object guide), there is no predefined IDP context for hello extensions,
so we are going to use non-service (stream) contexts, right? And this can be resource
consuming for SRX-100. [Offtopic: why don't they use that idea for web filtering of
HTTPS traffic?]

3) I agree with this method, but someone has to ask that: why not just use security
policies? 🙂 You can use a DNS name in address book entry, and SRX will renew
the IP (or IPs - it works if DNS returns several IPs) if it changes in DNS.

Hello Peter,

(1) and (2) - I need to lab the thing up which takes time. I'll see if I can get it done this week.

(3) security policy might be a good idea BUT - you have to populate address book with dozens of names such as facebook.com, www.facebook.com, login.facebook.com, my.facebook.com etc.You may also miss some obscure facebook URL and leave a hole for clued-up users.

Same for gmail.com. Better to block the whole CIDR block though it is also most crude method.

HTH

Rgds

Alex

Hello folks,

below is a tested example of DNS doctoring for facebook. It doctors the DNS resolution for facebook.com, www.facebook.com, my.facebook.com, login.facebook.com and star.facebook.com. Tested with SRX210H-POE and JUNOS 10.4R6.5.

C:\>nslookup facebook.com. 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    facebook.com
Addresses:  127.0.181.12, 127.0.189.11, 127.0.189.16


C:\>nslookup www.facebook.com. 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    www.facebook.com
Address:  127.1.228.12


C:\>nslookup my.facebook.com. 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    star.facebook.com
Address:  127.1.224.56
Aliases:  my.facebook.com


C:\>nslookup login.facebook.com. 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    login.facebook.com
Address:  127.2.146.21


C:\>nslookup star.facebook.com. 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    star.facebook.com
Address:  127.1.224.29

The only thing which is explicitly needed is static NAT entries for facebook.com server IP blocks:

root@srx210h-poe> show configuration security nat static 
rule-set facebook-DNS-doctoring {
    from zone untrust;
    rule 1 {
        match {
            destination-address 69.63.0.0/16;
        }
        then {
            static-nat prefix 127.0.0.0/16;
        }
    }
    rule 2 {
        match {
            destination-address 69.171.0.0/16;
        }
        then {
            static-nat prefix 127.1.0.0/16;
        }
    }
    rule 3 {
        match {
            destination-address 66.220.0.0/16;
        }
        then {
            static-nat prefix 127.2.0.0/16;
        }
    }
}     

The full config is attached.

HTH

Rgds

Alex

P.S. Stay tuned for SSL Client hello IDS blocking example

Attachment(s)

srx210_DNS_doctoring_full_config.txt   4 KB 1 version

Hi Alex,

Thanks for the example, its very instructive, but again there is a
disadvantage (from my point of view) that you need to know address blocks
in advance. It would be great to be able to filter on URLs in DNS requests,
but it is another task for IDP, I think...

Hello Peter,

I feel your pain ...

Below is an example of facebook blocking using custom IDP policy matching on SSL client Hello extension "server_name".:

root@srx210h-poe> show configuration security idp custom-attack fb-https 
recommended-action close-client;
severity major;
attack-type {
    signature {
        context ssl-client-hello;
        pattern ".*facebook\.com.*";
        direction client-to-server;
    }
}

root@srx210h-poe> show configuration security policies from-zone trust to-zone untrust 
policy fb-https-block {
    match {
        source-address any;
        destination-address any;
        application junos-https;
    }
    then {
        permit {
            application-services {
                idp;
            }
        }
        log {
            session-close;
        }
    }
}
policy default-permit {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}        

As one can see, I do NOT match on src or dst prefixes here.

And the proof is in screenshot below. The full config is attached. I am able to browse to other HTTPS sites (tried https://gmail.com and https://encrypted.google.com/, both work fine) but NOT fhttps://www.facebook.com OR https://my.facebook.com.

Caveat: this policy does NOT block https://login.facebook.com/ because SSL client hello does NOT contain extension "server_name" for whatever reason. 

HTH

Rgds

Alex

Attachment(s)

srx210_IDP_policy_2_block_facebook.txt   51 KB 1 version

Hello again, Peter et al,

I solved the problem with https;//login.facebook.com - the following IDP config blocks them all (well, it blocks known-to-me HTTPS facebook URLs):

[edit security idp]
root@srx210h-poe# show custom-attack fb-https-server 
recommended-action close-client;
severity major;
attack-type {
    signature {
        context ssl-cert-common-name;
        pattern ".*facebook\.com.*";
        direction server-to-client;
    }
}

[edit security idp]
root@srx210h-poe# show custom-attack fb-https-client    
recommended-action close-client;
severity major;
attack-type {
    signature {
        context ssl-client-hello;
        pattern ".*facebook\.com.*";
        direction client-to-server;
    }
}

[edit security idp]
root@srx210h-poe# show custom-attack-group facebook-https-block 
group-members [ fb-https-server fb-https-client ];

root@srx210h-poe# show idp-policy fb-https-drop                               
rulebase-ips {
    rule 1 {
        match {
            from-zone trust;
            to-zone untrust;
            application junos-https;
            attacks {
                custom-attack-groups facebook-https-block;
            }
        }
        then {
            action {
                recommended;
            }
            notification {
                log-attacks;
            }
            severity major;
        }
    }
}

CAVEAT: if the SSL server certificate is cached by browser (because browser already has successfully visited HTTPS facebook URL) then SSL server Hello does not contain certificate and this policy does not work.

Full config is attached.

HTH

Rgds

Alex

Attachment(s)

srx210_IDP_policy_2_block_facebook_v2.txt   51 KB 1 version

All good examples, thanks Alex!

Good solutions, but the only drawback to this is that it is very taxing on the CPU (especially with this being an SRX-100).  Performance in general on the box may suffer as a result of this.

Hi aarseniev ,

Thanks for the helpful example , i have a question : how will the IDP encrypt  the SSL traffic to look for : ".*facebook\.com.*";   ?

Hi all!

Is it possible to use IDP to match DNS requests containing "facebook" string and drop them? This way the client will not get IP address for any facebook site. I know that problem with this approach is when client manually enters IP address, or when DNS record is cashed on PC.

Can anybody suggest the configuration?

Thank you in advance!

Hello there,

I would imagine it is possible (though I haven't tested it) but IDP policy dropping DNS requests for facebook.com or any other unwanted website is easily circumvented by editing HOSTS file (C:\WINDOWS\system32\drivers\etc\hosts file in Windows).

Thanks

Alex

Could you tell me what context should I use to match DNS request?

custom-attack DNS-SKYPE {
    severity warning;
    attack-type {
        signature {
            context dns-rr-type-rdata;
            pattern ".*skype\.com.*";
            direction client-to-server;
        }
    }
}

I have configured IDP custom attack like this, but it doesn't work.

Kind regards!

From 11.4 release we support EWF ( Enhanced Web filtering) using which you can block https websites. You can define categories specific to the url to block or permit them.

Hi smprasanna,

Thanks a lot for the info; may be you can answer this question as well?

http://forums.juniper.net/t5/SRX-Services-Gateway/Is-UTM-on-non-standard-ports-possible-on-SRX/td-p/90728

Hi All,

UTM now supports HTTPS with 11.2 onwards.It is mentioned in 11.2 release notes

Ref http://www.juniper.net/techpubs/en_US/junos11.2/information-products/topic-collections/release-notes/11.2/junos-release-notes-11.2.pdf Page 138

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

UTM Web filtering uses the IP address of the HTTPS packet to make blacklist, whitelist, permit, or block decisions.

During a block decision, UTM Web filtering does not generate a block page because the clear text is not available for an HTTPS session. However, the solution terminates the session and sends resets to the client and the server for the blocked HTTPS sessions. The UTM Web filtering configuration for HTTP is also applicable for the HTTPS sessions

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

Hope this helps.

Regards,

Visitor

-------------------------------------------------------------------------------------------------------

If this post was helpful, please mark this post as an "Accepted Solution".Kudos are always appreciated!