Setting a stealth rule



  • On other firewalls ive worked on, the stealth rule is near the top of the ruleset and simply says that any traffic to the firewall from anywhere should be dropped and logged. With Juniper’s zone based firewalling, i cant see how to apply this logic in a single rule. Say my firewall services 3 zones. I need a rule saying that anything from zone A to zone A interfaces on the firewall should be dropped; anything from zone B to A on the firewall should be dropped; anything for B to C; etc, etc. A total of 6 rules.  If i had 4 zones i’d need 24 stealth rules!

    I must be missing something. Please help.



  • @oldo:

    @jmcgrady:

    My local security people demand that the first rule(s) of any firewall be to administer the firewall and handle connections to/from it. The next rule must explicitly drop and log all traffic destined for any firewall interface. This rule must preceed every other rule. Unfortunately they wont accept an implicit drop or a cleanup rule at the end. I was hoping to avoid having to create individual rules to/from each zone.

    Well, I don’t think the security people at your office is aware of how the Netscreen/SSG is designed. If you or your security staff need details on how a Nescreen/SSG firewall works there is a good explanation in the C&E, Volume 2, ScreenOS Architecture.

    As mentioned earlier it is a zone-based firewall that Denys’ by default. Traffic destined to the firewall it self end up in the log by default, or can be activated as greg1c illustrated in his post.

    I’d also like to point out that you should use permitted IP’s as well, complementing the interfaces that have management services enabled.

    Oldo ain’t wrong, if the security people demand that they don’t understand ScreenOS at all, as you don’t set out the rulebase in “the Check Point way” as they are presumably used to.

    Using managability options on the interfaces and logging self traffic, along with defining permitted IPs, will effectively give you exactly the same results anyway!!



  • @jmcgrady:

    My local security people demand that the first rule(s) of any firewall be to administer the firewall and handle connections to/from it. The next rule must explicitly drop and log all traffic destined for any firewall interface. This rule must preceed every other rule. Unfortunately they wont accept an implicit drop or a cleanup rule at the end. I was hoping to avoid having to create individual rules to/from each zone.

    Well, I don’t think the security people at your office is aware of how the Netscreen/SSG is designed. If you or your security staff need details on how a Nescreen/SSG firewall works there is a good explanation in the C&E, Volume 2, ScreenOS Architecture.

    As mentioned earlier it is a zone-based firewall that Denys’ by default. Traffic destined to the firewall it self end up in the log by default, or can be activated as greg1c illustrated in his post.

    I’d also like to point out that you should use permitted IP’s as well, complementing the interfaces that have management services enabled.



  • You can set up what interface you want to use to connect to the firewall, we typically admin our firewalls from one zone and turn off administration from all other zones. There is a log for packets destined to the firewall interfaces, you turn that on by the following command. So unless you allow explicitly to manage the firewall via telnet, web, ssh, ssl, or snmp, all traffic is denied and logged in the firewall

    “set firewall log-self”

    To view the log is “get log self”

    So if you wanted to administer the firewall from the untrust zone (interface ethernet 4 for example) and ethernet 1, 2, and 3 you do not want to mange from you would configure this.

    unset interface ethernet1 ip manageable
    unset interface ethernet2 ip manageable
    unset interface ethernet3 ip manageable

    set interface ethernet4 ip manageable
    set interface ethernet4 manage ping
    set interface ethernet4 manage ssh
    set interface ethernet4 manage snmp
    set interface ethernet4 manage ssl
    set interface ethernet4 manage web

    I hope that helps!

    Greg



  • My local security people demand that the first rule(s) of any firewall be to administer the firewall and handle connections to/from it. The next rule must explicitly drop and log all traffic destined for any firewall interface. This rule must preceed every other rule. Unfortunately they wont accept an implicit drop or a cleanup rule at the end. I was hoping to avoid having to create individual rules to/from each zone.



  • The implicit policy for a Netscreen firewall is DENY, so if you would like to log the traffic that is being denied you need to create 1 policy in each zone as the last policy (policies are executed from top to bottom).  The policy can be as simple as ANY to ANY DENY and Log that policy. It is a good troubleshooting technique, but I really do not see what other purpose it would serve to Log traffic that is denied.  If you have a destination ANY policy in front of the Deny policy there is no point!

    Greg


  • Global Moderator

    I think you have a checkpoint background right?

    Things work slightly different on juniper. Interfaces are stealth by default. Only when you allow a service speficly you will see that service. Traffic from a subnet to a interface in this net doesn’t pass a policy, so you don’t need a stealthrule. Also no allowing policy is needed. Only when you have a packet arriving on a interface and the destination is an other interface you may need a policy allowing the packet to pass.

    This is necesary when:

    A) the destination interface is in another zone then the interface the packet is arriving on.

    B) Thet destination interface is in the same zone as the arriving interface and intra zone block is enabled for this zone. This blocking is enabled on all zones by default except the trust zone. So if you have two interfaces in untrust (a and b) and a service on b, while traffic arives at a you need someting like: set policy from untrust to untrust <src ip=""><interface 32="" ip="" b=""><service>permit</service></interface></src>


 

29
Online

38.4k
Users

12.7k
Topics

44.5k
Posts