Cisco VIRL is going one step closer to provide their services on the cloud, as this will open new opportunities for many of us, especially for those who want to test some complex scenarios and they don’t have powerful hardware to run . Now VIRL is available on Packet’s bare metal cloud platform, which certainly helps end-users, as they need to pay for what they used , the deployment time will be reduced.
In order to run VILR on cloud one need to register for a Packet account and have a valid VIRL license key. The set up procedure will be provided by VIRL team and they claim it’s a quite easy deployment.
Hurry up as VIRL license node limit will be doubled for free, when I use my VIRL key on Packet its will be increased from 20 to 40.
Register for free and receive $25 usage credit today on Packet: https://www.packet.net/promo/virl/
In the below example, a single DNS query packet is trying to query the domain www.yasirirfan.com. This packet contains all the information needed by a Palo Alto Network Firewalls to identify an app, by inspecting the below UDP packet it can determine
Is the packet genuine and trying to use DNS as an application to do a query?
We could see both source IP , destination IP address along with destination port no and application is identified by a Palo Alto Networks firewall, once the application is identified , the traffic is processed by security policy. By using this approach Palo Alto networks Firewalls are quite affective is stopping evasive applications
The good thing about Palo Alto Networks Firewall is, mostly it needs only one UDP packet to identify an application which are UDP based.
Yesterday I received an email from Cisco Security Advisories about the critical vulnerability related IKE version 1 and IKE version 2 code of ASA Software which could empower an unauthenticated remote attacker to reload or even execute a code remotely on a affected ASA firewall.
Those who are terminating their VPN tunnels by using either IKEv1 or IKEv2 for any of the following VPN tunnels
- LAN-to-LAN IPsec VPN
- Remote access VPN using the IPsec VPN client
- Layer 2 Tunneling Protocol (L2TP)-over-IPsec VPN connections
- IKEv2 AnyConnect
They should immediately check if their ASAs are affected. If so then they should upgrade the ASA, as there is not other fix from Cisco
The vulnerability is due to a buffer overflow in the affected code area. An attacker could exploit this vulnerability by sending crafted UDP packets to the affected system. An exploit could allow the attacker to execute arbitrary code and obtain full control of the system or to cause a reload of the affected system
Following versions of IOS are affected , one should upgrade immediately to the recommended IOS version
|Cisco ASA Major Release||First Fixed Release|
|7.21||Affected; migrate to 9.1(7) or later|
|8.21||Affected; migrate to 9.1(7) or later|
|8.31||Affected; migrate to 9.1(7) or later|
|8.61||Affected; migrate to 9.1(7) or later|
Further details can be found at the below url
When it comes to treating an Application every vendor has a way of treating an App, most of the traditional firewalls treats Applications mostly on port numbers. For example traditional Firewalls treats DNS as port 53 application. And a rule is configured in traditional firewall to allow port 53 for DNS traffic . Suppose an evasive application like BitTorrent attempts to use port 53 for P2P file sharing. The traditional firewall cannot stop an evasive application unless an external IPS appliance is involved.
How ever Palo Alto Networks Next Generation Firewalls treats an Application in different way. First of all Palo Alto defines application as
” a specific program or feature that can be detected, monitored and blocked if required”
This approach of Palo Alto towards an application is what making them outstanding and hence they are the leaders when it comes to Next Generation Firewalls. Till date they are the leaders even in Gartner Magic Quadrant.
By adopting multiple tactics to classify an application, When configured to only allow DNS as an application, Palo Alto Networks Next Generation Firewalls are in position them to block all kind of traffic on port 53 except DNS.
Palo Alto Networks Next Generation Firewalls have complete visibility of the complete traffic flow and pattern, hence they are very affective as a Next Generation Firewall.
The era of technology is evolving and trends are moving towards a connected world, be it humans , machines, automobiles or household appliances, people are making efforts to connect them. So did the word “Internet of Things” (IoT) emerged. I could see Cisco is quite serious on this direction and are making a great progress.
With the intent of acquiring a startup company Jasper Technologies,Inc., based in Santa Clara which delivers cloud-based IoT service platforms, Cisco is further enhancing its stake in IoT segment. It’s the commitment , delivery and acquisitions what made Cisco stronger in many technology domains. I believe this acquisition of Cisco will make them pioneers in the IoT segment.
“I am excited about the opportunity for Cisco and Jasper to accelerate how customers recognize the value of the Internet of Things,” said Chuck Robbins, Cisco Chief Executive Officer. “Together, we can enable service providers, enterprises and the broader ecosystem to connect, automate, manage, and analyze billions of connected things, across any network, creating new revenue streams and opportunities.”
“IoT has become a business imperative across the globe. Enterprises in every industry need integrated solutions that give them complete visibility and control over their connected services, while also being simple to implement, manage and scale,” said Jahangir Mohammed, Jasper Chief Executive Officer. “By coming together, Jasper and Cisco will help mobile operators and enterprises accelerate their IoT success.”
Cisco is planning to close this acquisition by third fiscal quarter of 2016, and the current CEO of Jasper Technologies CEO Jahangir Mohammed will run the new IoT Software Business unit .
Oracle recently announced their decision to stop its Java browser plug-in, well this is a great move from Oracle. Their next Java Development Kit “JDK 9” will be shipped without a browser plug-in.
These days most of the browsers stopped supporting Oracle Java plug-in for oblivious reasons like vulnerabilities and threats found. I wish companies like Cisco, Blue Coat stop using Java browser plug-ins for their products, especially for ASDM , ACS and Blue Coat Proxy SG.
Often those who are into Network Operations have to install many versions of Java to manage many security appliances. I am quite hopeful this new announcement form Oracle will redefine the GUI management of Network Security Appliances.
Like all other firewalls , Palo Alto Networks Firewall supports Address objects. These Address Objects are basically named objects which can be configured on a Palo Alto Networks Firewall . The address object can include an IPv4 or IPv6 address or the FQDN. The address can be configured based on an
- Single IP address
- IP Range
An Address object can be reused as source or destination address across all the security policy rules. Palo Alto Networks Firewalls comes with very handy features of tags, these little simple features makes life easier of a Firewall Administrator as he/she can easily distinguish the tag object by adding colour to the tag.
In order to add a an Address Object one need to
Step 1 – Select Objects > Addresses, and click Add
Step 2- Enter a Name and a Description for the address object.
Step 3- Select Type —IP Netmask, IP range or FQDN
You can also select a Tag this is optional . Click Ok to save the Address object. One can apply address objects to the security Policies as shown below
Object Group is not a new feature but it comes handy for day to day Firewall Administration.
In my previous post we studied the topology and saw how Type 3, Type 4 and Type LSA routes are installed in non 0 Area. Now lets configure Area 5 as a Totally Stubby Area and see what impact it will have
In order to configure Totally Stubby Area one should use the following Cisco IOS Command in an ABR under OSPF process
router ospf 1
area x stub no-summary
And on the non ABR router of Totally Stubby Area as the following Cisco IOS commands
router ospf 1
area x stub
In our case we need to configure Area 5 as Totally stubby area by using the below Cisco IOS command in Routers R2 which happens to be ABR
And in R3 Router
Now we have successfully configured Area 5 as Totally Stubby Area, we could see R2 is learning R4 loopback networks 10.0.1.0, 10.0.2.0, 10.0.3.0 & 10.0.4.0 as Type 5 LSA ( OPPF external type 2 routes) and R1-R4 link networks 192.168.14.0 as Type 3 LSA ( Inter area routes) and R2 will inject remove these routes and inject them with a default route to R3.
R3 can now only see a default route and if we check the OSPF Data base there are no more Inter-Area specific routes,
Also we cannot see the R4 loopback interface 10.0.1.0 network in the routing table , how ever its there in CEF table
And we ping the loopback 1 interface IP 10.0.1.1 of R4
Well Totally Stubby Area is great feature which helps in reducing the OSPF Database size and also it reduces the CPU utilization of a router.
In this series of posts lets configure OSPF Totally Stubby Area, but before proceeding further lets summarise the below topology
- Two OSPF Areas Area 0 and Area 5
- R1, R2 and R4 are part of Area 0 and OSPF is configured on the directly connected links on each router ( R1 – R2 link , R1-R4 link)
- R4 has four loop back interfaces loopback 1 (10.0.1.1) , loopback 2 (10.0.2.2) ,loopback 3 (10.0.3.3) and loopback 4 (10.0.4.4) ,these loopback interfaces networks are redistributed into OSPF
- R2-R3 are part of Area 5, R2 happened to be a ABR
- OSPF Area 5 is configured on the interfaces connected between R2-R3.
Currently Area 5 is a normal area and its not been configured as a totally stubby area, R2 installs the R4 loopback interface networks as Type 5 LSA and forward the same to Area 5
We can see from the below snap shot R2 received R4 loopback networks as Type 5 LSAs and the routes are installed as Type 2 External OSPF routes, also we could see the interface connecting R1-R4 are also advertised as Type 3 LSA
R3 sees R4 loopback interfaces network as Type 5 LSA and R1-R4 , R1-R2 links network 192.168.14.0/29 , 192.168.12.0/29 as Type 3 LSAs
In next post lets see by what impact Area 5 will have especially after configuring it as OSPF Totally Stubby Area.
OSPF Totally Stubby Area basically filters out an information of a OSPF database purely based on the LSA types. An ABR in a Totally Stubby Area prevents LSA type 3, Type4 and Type 5 to be flooded in to a Totally Stub Area. It replaces all these types of LSA with a default route. Basically the Totally Stubby Area carries out the concept of Stub area in addition to removing type 3 LSA.
From the above scenario the ABR R2 will simply strips of Type 5, Type3 and Type 4 LSA and just forward a default route to R3. In order to configure a Totally Stubby Area one need to use Cisco IOS command ” area x stub no-summary” on the ABR Router and Cisco IOS Command ” area x stub” under OSPF process in Totally Stubby routers, where X happens to be the Area number . Now you might be wondering why the IOS commands are different in an ABR and other routers which are part of Totally Stubby Area, well the IOS command no-summary tells the ABR not to inject TYPE 3 LSA which represent the Inter-Area routes. I upcoming post lets see how to configure Totally Stubby Area.