Imagine a group of researchers planning to speak at a conference regarding a previously undiscovered vulnerability present in most homes that would allow a thief to rob your home of its valuables with complete ease. You would probably be interested in hearing what they had to say so you could take the necessary precautions to protect your home.
Now imagine when they presented their findings, they went on to state that it was incredibly easy to do, so long as you left your front door open and also provided them with the security code for any alarm systems. You would probably find this implausible and simply the proliferation of fear, uncertainty, and doubt.
That’s precisely what happened last week at the well-respected Black Hat security conference in Las Vegas when researchers from the Israel Institute of Technology and Advanced Defense Systems, Ltd. presented their findings of a serious vulnerability present in OSPF. So serious in fact, the researchers stated the only way to properly mitigate the threat, short of fixing the protocol, is to switch to another routing protocol such as RIP or IS-IS. Continue reading “Black Hat OSPF Vulnerabilities: Much Ado About Nothing”
In our previous article, we looked at using apply-groups to alter all the security policies uniformly on an SRX device such that they would all have an implicit logging statement. And while this is fine for all existing policies, it doesn’t log traffic which doesn’t match any explicitly defined security policy.
The reason for this is due to the fact that in Junos, traffic which doesn’t match an explicitly defined security policy matches against the default-deny policy. However, given the fact that the default-deny policy is implicitly defined, apply-group configurations are of little benefit as apply-groups can only be inherited by those elements which have been explicitly defined. Continue reading “Juniper SRX Tips :: Altering Default-Deny Behavior”
Often there are instances where we want to affect all security policies configured on an SRX device. For example, let’s say that we have thousands of policies configured on our firewall, and we want to enable logging for every single policy. Obviously this would take some time if we were to do this manually on each and every individual policy, so an easier way is desired.
Continue reading “Juniper SRX Tips :: Uniform Security Policy Modification”
Today we’ll start with a series of articles covering tips and techniques that might be utilized by JNCIE candidates, whether pursuing the JNCIE-SP, JNCIE-ENT, or even the JNCIE-SEC. The tips and techniques I will be covering might prove to be useful during a lab attempt but could also be used in real-world scenarios to save time and minimize configuration burden in addition to eliminating mistakes that might otherwise be made. I want everyone to understand that what I am about to write is simply a technique. I am not divulging any materials or topics which are covered under NDA.
Continue reading “JNCIE Tips from the Field :: Summarization Made Easy”
I am happy to announce that Juniper has just released a new Day One Guide entitled “Junos Tips, Techniques, and Templates 2011“. For this particular Day One Guide, Juniper Networks Books and J-Net joined forces and requested the best and brightest Junos tips and techniques from the Junos user community. In fact, the book was created after a thorough selection process which included reviewing over 300 submitted tips by over 100 individuals on the J-Net community boards at forums.juniper.net.
Continue reading “Day One Guide: Junos Tips, Techniques, and Templates 2011”
I’ve always been at odds with the recommendation in RFC 3177 towards allocating /48 IPv6 prefixes to end-sites. To me this seemed rather short-sighted, akin to saying that 640K of memory should be enough for anybody. It’s essentially equivalent to giving out /12s in the IPv4 world which in this day and age might seem completely ridiculous, but let us not forget that in the early days of IPv4 it wasn’t uncommon to get a /16 or even a /8 in some cases.
Granted, I know there are quite a few more usable bits in IPv6 than there are in IPv4, but allocating huge swaths of address space simply because it’s there and we haven’t thought of all the myriad ways it could be used in the future just seems outright wasteful. Continue reading “IETF Provides New Guidance on IPv6 End-Site Addressing”
Today, I received a very disturbing email on NANOG which was forwarded from a recipient on the Global Environment Watch (GEW) mailing list. If this is true, we all need to take steps to make an orderly and smooth transition to IPv6 as quickly as possible, lest we suffer from the harmful effects described in this email.
From: Stephen H. Inden
To: Global Environment Watch (GEW) mailing list
Date: Fri, 1 Apr 2011 00:19:08 +0200
Subject: IPv4 Address Exhaustion Effects on the Earth
At a ceremony held on February 3, 2011 the Internet Assigned Numbers Authority (IANA) allocated the remaining last five /8s of IPv4 address space to the Regional Internet Registries (RIRs). With this action, the free pool of available IPv4 addresses was completely depleted. Continue reading “IPv4 Address Exhaustion Causing Harmful Effects on the Earth”