SRX

 View Only

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



  • 1.  HOWTO: Management on different port and permitted ip's (ScreenOS Style management)

    Posted 08-21-2009 05:41

    Hello Everybody,

     

    I've been breaking my head on how to change managment to different ports and limit it to th correct source-ip's. When i was in bed last night, an idea popped in my head, which i just tested. All seems to work fine and i want to share it with you, for a few kudos 😉

     

    This example is based on ssh/port 22 which i want available from port 1022 on the public ip. I don't see any limitation in doing this with other services like http/https or ftp, but did not yet test this.

     

    Step 1
    Create a loopback interface with a dummy ip address:

    [edit interfaces lo0]
    root@core-router# show
    unit 0 {
        family inet {
            address 1.1.1.1/32;
        }
    }


    Step 2
    Enable management services on the loopback interface:

    [edit system services]
    root@core-router# show
    ftp;
    ssh;
    web-management {
        http {
            interface lo0.0;
        }
        https {
            system-generated-certificate;
            interface lo0.0;
        }
    }


    Step 3
    Create a new zone with a logical name, like mgmt, put the loopback int in the zone and create an address book entry for the loopback interface. Also enable all host-inbound-traffic:

    [edit security zones security-zone mgmt]
    root@core-router# show
    address-book {
        address mgmt-int 1.1.1.1/32;
    }
    interfaces {
        lo0.0 {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
        }
    }


    Step 4
    (not sure if this is mandetory) set source-nat enabled for traffic initiated from the new zone:
    (This rule enables source nat from zone trust and zone mgmt from any address to any address to the interface IP address)

    [edit security nat source]
    root@core-router# show
    rule-set snat-to-inet {
        from zone [ mgmt trust ];
        to zone untrust;
        rule snat-to-inet {
            match {
                source-address 0.0.0.0/0;
                destination-address 0.0.0.0/0;
            }
            then {
                source-nat {
                    interface;
                }
            }
        }
    }

    Step 5
    Create a pool with the address of the loopback interface and the destination port of the service (in this case SSH):

    [edit security nat destination pool mgmt-22]
    root@core-router# show   
    address 1.1.1.1/32 port 22;


    Step 6
    Create a destination nat policy with destination address the public interface ip address.
    Use destination-port on which you want managment to listen (in this case 1022), use destination-nat pool we created in step 5:

    [edit security nat destination rule-set dnat-untrust rule mgmt-22]
    root@core-router# show
    match {
        source-address 0.0.0.0/0;
        destination-address x.x.x.x/32;    //x.x.x.x = public ip address!!
        destination-port 1022;
    }
    then {
        destination-nat pool mgmt-22;
    }


    Step 7

    create a policy from zone untrust to mgmt to allow the management traffic:
    I choose source any and application any for this test, but you can limit this offcourse!!!

    [edit security policies from-zone untrust to-zone mgmt]
    root@core-router# show
    policy mgmt {
        match {
            source-address any;
            destination-address mgmt-int;
            application any;
        }
        then {
            permit;
            log {
                session-init;
                session-close;
            }
        }
    }

     

     

    Now you can use port 22 to nat to a server behind the firewall (yes i tested it). Do keep in mind that you have to disable the host-inbound-services on the physical interface!!

     

    [edit security zones security-zone untrust interfaces fe-0/0/7.0]
    root@core-router# show                                                  
    host-inbound-traffic {
        system-services {
            dhcp;
            ping;
        }
    }

     

    Example config of natting port 22 to a server with ip 10.50.2.50:

     

    Step 1

    Create a nat pool for the server:

     

    [edit security nat destination pool server-22]
    root@core-router# show
    address 10.50.2.50/32 port 22;

     

    Step 2

    Create a destination-nat rule:

     

    [edit security nat destination rule-set dnat-untrust rule server-22]
    root@core-router# show
    match {
        source-address 0.0.0.0/0;
        destination-address x.x.x.x/32;
        //x.x.x.x = public ip address!!
        destination-port 22;
    }
    then {
        destination-nat pool server-22;
    }

     

    Step 3

    Create an address object:

     

    [edit security zones security-zone trust address-book]
    root@core-router# show
    address server 10.50.2.50/32;

     

    Step 4

    Create a security policy to allow traffic to the server:

    (Offcourse you can limit the traffic again to a certain source)

     

    [edit security policies from-zone untrust to-zone trust policy permit-ssh-server]
    root@core-router# show
    match {
        source-address any;
        destination-address server;
        application junos-ssh;
    }
    then {
        permit;
        log {
            session-init;
            session-close;
        }
    }


    #ip's
    #managment
    #permitted
    #change
    #Management
    #Port


  • 2.  RE: HOWTO: Management on different port and permitted ip's (ScreenOS Style management)

    Posted 08-22-2009 01:29

    It seems i might have been a bit to quick with jumping in the conclusion it should work for other services as well.

    SSH works great, but http, https and ftp are having trouble.

     

    With http/https i do get a tcp connection and a certificate presented but i get a 403 forbidden error. Even if itry without nat.

    (from trust to mgmt with destination address 1.1.1.1 to the correct port number) So it seems the jweb isnt presented via the loopback somehow.

     

    With FTP i'm not sure what the problem is, but i simply don't get an answer on my tcp syn when using a different port. Think it has to do with how the protocol behaves.



  • 3.  RE: HOWTO: Management on different port and permitted ip's (ScreenOS Style management)
    Best Answer

    Posted 08-22-2009 02:11

    Got http & https going now, ftp is still trouble... (but you might not want to enable that on your public facing interface anyway).

     

    For ssh you still have to usethe method in my initial post.

    For http/https its a bit easier:

     

    Change the port numbers for the services and enable the on the public interface (fe-0/0/7 in my case)

    root@core-router# show system services web-management
    http {
        port 10080;
        interface [ vlan.502 fe-0/0/7.0 ];
    }
    https {
        port 10443;
        system-generated-certificate;
        interface [ vlan.502 fe-0/0/7.0 ];
    }

     

    Enable http and https on the interface in the zone:

     root@core-router# show security zones security-zone untrust interfaces
    fe-0/0/7.0 {
        host-inbound-traffic {
            system-services {
                dhcp;
                ping;
                http;
                https;
            }
        }
    }

     

     

    Thats it. The services are now reachable on those ports and you can use port 80 & 443 to destination nat to a server internally.



  • 4.  RE: HOWTO: Management on different port and permitted ip's (ScreenOS Style management)

    Posted 08-31-2009 12:52

    This will work however it will break dynamic-vpn access if being used.  Does anyone know how to set dynamic-vpn to another port number.

     

    Looking to do the following:

     

    Public IP port 443 to dst-nat to OWA or Remote Web Workplace

    Public IP port 8443 possibly J-Web

    Public IP port ?? for dynamic-vpn



  • 5.  RE: HOWTO: Management on different port and permitted ip's (ScreenOS Style management)

    Posted 09-09-2009 03:50

    Hi,

     

    dynamic-vpn access is bound to "system services web-management https port", default 443.

     

    So there is now way to block access via permitted-ips if one wants to use dynamic-vpn.

     

    regards,

     

    Klaus



  • 6.  RE: HOWTO: Management on different port and permitted ip's (ScreenOS Style management)

    Posted 08-31-2009 12:46

    Hello guys,

     

    here is my fifty cent:

     

    Why not use the  stateless firewall filters for access limiting on interfaces?

     

    One can use prefix-list for source addresses, that are able to access the

    specific management-services, then write a ruleset, with one term, that allows

    all but the management-services on udp/tcp and a second term, that allows

    the host-inbound services for the prefix-list. Maybe one would like to allow access

    to services that should be accessible for everyone (specified by service).

    Deny the rest - if any.

     

    In the end, one has only to add/remove the "permitted ips" from the prefix-list.

     

     

    Here comes a config example:

     


    [edit]
    ent# show policy-options prefix-list permitted-ips
    10.1.2.21/32;
    10.10.52.2/32;





    [edit]
    ent# show firewall family inet filter conf-services
    term non-admin-services {
        from {
            protocol [ tcp udp ];
            destination-port-except [ 80 443 22 23 ];
        }
        then accept;
    }
    term admin-services {
        from {
            source-prefix-list {
                permitted-ips;
            }
            protocol [ tcp udp ];
            destination-port [ 22 23 80 443 ];
        }
        then accept;
    }
    term icmp-allow {
        from {
            protocol icmp;
            icmp-type-except redirect;
        }
        then accept;
    }
    term match-denied {
        then {
            count bad-packets;
            syslog;
            discard;
        }
    }





    ent# show interfaces ge-0/0/0 unit 0
    family inet {
        filter {
            input-list conf-services;
        }
        address 10.10.52.3/24;
    }