SRX

Hi All,

 

Perhaps someone can help clarify how this new junos-host zone works.  To my understanding it can be used to to filter access to the box allow us to create statefull security policies instead of using the firewall filter applied to lo0.

 

My question is picture a firewall with 100 zones.  I only want ip 192.168.100.0/24 to be able to SSH.  Using an lo0 interface I can write this rather quickly with 2 or 3 terms.

 

Using the junos-host zone would I have to write 100 policies specifically denying access from each zone to the junos-host zone?  If I create just one for example

 

from zone MGMT to zone junos-host

   match source address 192.168.100.0/24

   match application SSH

   then permit

 

would that trigger everything else to be blocked or do i have to have 99 policies denying all other zones from hitting SSH.

 

Thanks!

Hi,

 

If we want to apply security services (for example IPsec VPN ,schedulers,firewall authentication etc which are available with security policies (then permit ? ))  to the self-traffic (could be either inbound or outbound)  , then we can use junos-host security zone .  Without junos-host security zone, self-traffic can not go through these services. 

 

For example enabling management access for a specified timings only ..which can now be easily achieved with a security policy using junos-host zone and scheduler applied on this policy .

 

If your objective is to restrict some traffic , it is always efficient to do it using firewall filters itself, as you correctly mentioned.

 

In your example, just writing one policy will not do . we have to write one policy from each from-zone to junos-host zone for that specific ssh traffic .  

 

The following thread may help you ...

http://forums.juniper.net/t5/SRX-Services-Gateway/Are-both-inbound-and-outbound-policies-necessary-for-the-junos/td-p/140307

Thanks for the reply.

 

I guess the main question here would be the following:

 

In JUNOS there is an implicit deny from any zone to any other zone.  The junos-host zone seems to be the opposite, having an implicit allow ( I assume this because if I just have a host inbound service of SSH then I dont have to also explicily include a rule from trust to junos-host allowing SSH).

 

If this is the case then does creating a specific Allow then force an implicit deny.

 

Hopefully this makes sense.

Yes, creating a specific allow from-zone x to-zone junos-host will block all other traffic in that context( like any other security policy).

If we dont have any security policy with to-zone as junos-host, then its implicit allow provided corresponding system services and host-inbound-traffic settings are there.

My testing with 11.4 shows that, after evaluating policies in “from-zone x to-zone junos-host” there is NO implicit deny applied and traffic is evaluated as “self-traffic-policy” i.e. will be accepted or denied based on zone config (host-allowed-traffic).

 

Transit traffic -> policies in “from-zone x to-zone y” -> global policies -> default-policy (deny-all if not configured differently)

Traffic to SRX -> policies in “from-zone x to-zone junos-host” (if configured) -> policy resulting from zone config (host-allowed-traffic) -> implicit deny

 

Example:

(in all cases SSH is allowed in the zone configuration (host-allowed-traffic)

 

Case 1 (old-style): no policies for junos-host configured.

Result: ssh permitted.

 

Case 2: policy for junos-host configured allowing traffic from one given IP.

Result: SSH is permitted from ANY address.

 

Case 3: policy for junos-host configured allowing traffic from one given IP. Another policy SSH below the former one denying all SSH.

Result: SSH permited from one configured address and denied from any other.

 

If it was otherwise we would have to configure policies for all other host traffic (ike, ping etc.) if we configured any explicit policy in junos-host context...

 

Regards,

Pawel Mazurkiewicz

JNCIS-SEC

 

 

Did you try SSH from a different zone other then the one that was defined in the x to junos-host

Yes, I did.

It works - my zone config (host-inbound-traffic) allows it from the zone I tried from (as expected).

 

So this would be bad in my opinion.

 

Example.

 

I have 10 zones 1 through 10.  I only want SSH to be allowed from Zone 3 to the SRX on a specific IP.   I then create a policy from zone 3 to zone junos-self to allow SSH from the specific IP and deny  all others.

 

This means I now i have write a policy to deny SSH from zones 1,2,4,5,6,7,8,9,10 to the junos-host zone.  Now picture you have 500 zones.  You have to write 500 policies just to have 1 allow policy.

 

Doing it with the lo0 filter can accomplish this in 2 term statements.

 

Correct me if my conclusion is wrong here.

 

Thanks,

> This means I now i have write a policy to deny SSH from zones 1,2,4,5,6,7,8,9,10 to the junos-host zone.  Now picture you have 500 zones.

 

I think that there is no need to write multiple deny policies here - just do not include ssh in host-inbound-traffic configuration for zones 1,2,4,5,6,7,8,9,10 and it will be dropped. (old way 😉 ) I think that policy/junos-host just works on top of existing functionality - it will not allow anything what was not allowed based on zones host-inbound-traffic and lo0 filters. It has a capability to direct traffic to idp for example, log it (RT_FLOW) etc. before passing it down to the "old" mechanisms, but it seems (!) not to break them.

 

> Doing it with the lo0 filter can accomplish this in 2 term statements.

 

Filters are great - I will not say a bad word about them.;) Lately I used junos-host policy though in a following scenario: I wanted to give one zone full access to ssh (regardless of source address) while restricting traffic coming from the other zones ( by source IP's). Doing that with jonos-host/policy is just much more elegant then multiple interface filters or "from interface" in lo0 filters...

 

Regards,

Pawel Mazurkiewicz

---

@ttl_expired wrote:

So this would be bad in my opinion.

 

Example.

 

I have 10 zones 1 through 10.  I only want SSH to be allowed from Zone 3 to the SRX on a specific IP.   I then create a policy from zone 3 to zone junos-self to allow SSH from the specific IP and deny  all others.

 

This means I now i have write a policy to deny SSH from zones 1,2,4,5,6,7,8,9,10 to the junos-host zone.  Now picture you have 500 zones.  You have to write 500 policies just to have 1 allow policy.

 

Doing it with the lo0 filter can accomplish this in 2 term statements.

 

Correct me if my conclusion is wrong here.

 

Thanks,

---

 

You could have the following if that really worried you

 

set groups junos-host_deny security policies from-zone <*> to-zone junos-host policy deny-all match source-address any
set groups junos-host_deny security policies from-zone <*> to-zone junos-host policy deny-all match destination-address any
set groups junos-host_deny security policies from-zone <*> to-zone junos-host policy deny-all match application any
set groups junos-host_deny security policies from-zone <*> to-zone junos-host policy deny-all then deny

set apply-groups junos-host_deny

 Now every security zone to junos-host will have a deny policy at the bottom of it to stop all traffic, automatically applied. You will then have to configure specific permit policies on top of allowing it in your zone config before it works 🙂

 

You could also group every interface there is into 1 zone & control from.

 

Source from JunOS_Fan: http://forums.juniper.net/t5/SRX-Services-Gateway/Are-both-inbound-and-outbound-policies-necessary-for-the-junos/td-p/140307

zones {
        security-zone test {
            interfaces {
                all {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
            }
        }
    }

policies {
        from-zone test to-zone junos-host {
            policy selfpolicy {
                match {
                    source-address any;
                    destination-address any;
                    application [ junos-ssh junos-http ];
                }
                then {
                    deny;
                }
            }
        }
        default-policy {
            permit-all;
        }
    }

I'm finding the "junos-host" zone to be a little confusing.  Try to stay with me.  In my instance, I configured a policy to allow SSH from zone "untrust" to zone "junos-host".  The policy worked as expected.  I then figured I could create a policy from zone "test123" to zone "junos-host" to allow SSH to my loopback IP (which is in the "trust" zone).  When looking through the logs, this traffic (coming from the "test123" zone) was matched to my policy from zone "test123" to zone "trust" rather than to zone "junos-host".  So to me, it seems that the SRX is being a little inconsistent as to which traffic it sends to the "junos-host" zone. 

 

I can't configure an SSH policy from zone "test123" to zone "trust" specific to my loopback because any other policy I put in place to allow SSH through this path (say to destination-address any) would negate my policy specific to my loopback IP and allow the session.

 

Anybody else finding the junos-host zone a little flakey?  I would like to point out that I have two virtual routers defined.  For now, I'm going to stick with the input filter on the lo.0 interface.  However, I found that I had to explicitly configure policies from "junos-host" for other self-generated traffic, including IKE and DNS, regardless.  I wonder what would have happened if I was upgrading from another Junos version?  Would my local DNS resolution and IKE sessions have been blocked because of the introduction of the junos-host zone?

 

 

 

 

 

Wanted to add some information to what was provided here from some of my findings:

 

>> It works - my zone config (host-inbound-traffic) allows it from the zone I tried from (as expected).

 

Not only do you have to have the host-inbound-traffic but also a policy to allow the traffic.

 

Example:

Need policy from zone1 (incoming ssh) -> zone2 (where lo0 resides) as well as a policy from zone2 -> junos-host
**remember also need appropriate host-inbound-traffic on zone2; not needed on zone1 (see below)**

>>   > This means I now i have write a policy to deny SSH from zones 1,2,4,5,6,7,8,9,10 to the junos-host zone. Now picture you have 500 zones.

 

>>   I think that there is no need to write multiple deny policies here - just do not include ssh in host-inbound-traffic configuration for zones 1,2,4,5,6,7,8,9,10 and it will be dropped.

Incorrect as in these scenarios the ssh traffic is transitting the zones not going to these zones.  But still easily remedied with the appropriate policy rules either from 'zone1 to zone2' or from 'zone2 to junos-host'

 

I also tested this within logical-systems incase anyone was wondering about that scenario

Hi ttl_expired

 

Just an idea.

To avoid creating multiple policies across every possible context, you can create a global policy. Global policies provide you with the flexibility to perform actions on traffic without the restrictions of zone specifications.

 

Cheers