Be extremely careful when creating custom services on SRX



  • Not sure if this issue has been highlighted before but in any case it is worth mention it again… this has caused us a lot of grief!

    While performing a firewall rule clean-up we noticed that one policy was receiving traffic on all TCP ports.

    This particular policy was not configured with an open service. In fact this policy was tied down to only allow well known Microsoft AD Services.

    On further investigation it was noticed by a member of the team that custom service, ldap_ssl, was configured without a source a destination ports details.

    Normally when creating custom services on SRX the administrator would specify source ports and destination ports (at very least destination ports).

    Example 1: a correctly configured custom TCP port 8080:

    user@SRX3400> show configuration | display set | match applications | match TCP_8080

    set applications application TCP_8080 protocol tcp

    set applications application TCP_8080 source-port 1-65535

    set applications application TCP_8080 destination-port 8080

    Example 2: Our problem service was only configured with the “protocol tcp” line:

    user@SRX3400> show configuration | display set | match applications | match ldap-ssl

    set applications application ldap-ssl protocol tcp

    Clearly in example 2 the administrator forgot to add source and destination port details. This probably happened last year.

    Now: I would expect the firewall not to pass this incomplete service configuration during the “commit” or “commit check” commands OR at least ignore this line altogether.

    Instead the firewall translate example 2 as:

    set applications application ldap-ssl protocol tcp

    source-port 1-65535

    destination-port 1-65535

    Therefore by making this basic mistake, the administrator has open the entire TCP range of ports for that policy, on other words a policy that allows ANY TCP traffic.

    Clearly this is an issue, we have escalated within Juniper.



  • But not all policies require a source or destination port at all. I just don’t see the problem here.

    It’s great that you’ve created a script to change the firewall to suit your needs though, this IMHO is the best way to fix business specific issues like this.



  • Well I disagree, the firewall should not “assume” that by not defining destination port means go and open all TCP ports 1-65535.

    Nobody should create a service like that, so the code should not have behaviour by default. It should just ignore the line or set the destination port to 0 like the SSGs do it:

    SSG:primary(M)-> set service test protocol tcp
    SSG:primary(M)-> get service test
    Name:      test
    Category:  other          ID:  0  Flag:  User-defined

    Transport    Src port    Dst port  ICMPtype,code  Timeout(min|10sec*) Application
    tcp          0/65535          0/0                        30

    FYI: for anybody who wants to prevent this. I created this script to stop the firewall from committing if the destination port details are missing:

    version 1.0;
    #damianhinojosa www.juniperforum.com
    #2012
    
    ns junos = "http://xml.juniper.net/junos/*/junos";
    ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
    ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
    import "../import/junos.xsl";
    match configuration {
        expr "\n-->\n";
    /*#############################################*/
    for-each (applications/application){
    call error-if-missing($must = destination-port, $statement = "destination port missing on application") {
            with $message = {
                expr "Make sure the following application has defined destination-port :  ";
                expr name;
             }    }}
    /*#############################################*/
    }
    template error-if-missing ($must, $statement = "unknown", $message = "missing mandatory configuration statement") {
        if (not($must)) {
            <xnm:error>{
                <edit-path>{
                    copy-of $statement;            }
                <message>{
                    copy-of $message;           }        
    }   
     }
    }</message></edit-path></xnm:error> 
    


  • I do not see the issue here, the error was a configuration issue. The policy worked as entered.

    You do not need to set all options for the policy to be valid.


 

30
Online

38.4k
Users

12.7k
Topics

44.5k
Posts