Lately I made the change from deep technical consultant to a more high-level architect like kind of consultant. I now do my work on the turning point between business and technique. One of my first jobs is to make my customer ready for an audit to use the dutch official authentication method, which is called DigID.
There are several requirements, which have to be fulfilled before the customer can make use of the DigID authentication method. One of these requirements is that all the internet facing systems are placed in a DMZ. I tried to explain the importance of a well functioning DMZ. For us as network specialists this fact is obvious, but a lot of people don’t understand the meaning and working of a DMZ. This blog is about the essentials of which a DMZ has to consist.
First we need to understand what we are trying to achieve with a DMZ
• Separation and identification of network areas
• Separation and isolation of internet facing systems
• Separation of routing and security policies
After understanding the achievements, there is another point of interest. Are you gonna build your DMZ with dedicated switches, firewall’s and ESX hosts (physical) or do u use a separate vlan (virtual). There is no clear answer; fact is that bigger organizations build physical DMZ’s more often than smaller ones. Besides the technical aspect, there is off course a financial aspect. Resulting out of the physical/virtual debate comes the debate whether to use two physical firewalls or one physical firewall with several logical interfaces. Equally to the physical/virtual debate there is not just one answer.
For me personally one physical firewall with several logical interfaces with tight configured ACL’s is as good as two physical firewalls. One could dispute this with the argument that if a hacker gains access to one firewall he gains access to the whole network. Personally I don’t think this isn’t a valid argument, because when two physical firewalls are used they are often from the same vendor and use the same firmware with the same bugs and exploits. So if the hacker’s trick works on one firewall, it will often also work on the second one.
Some images to make the above a little more concrete.
Simple Network Monitoring Protocol (SNMP) has been widely deployed as an important network management tool for decades, is a key component of scalable network device management, and is configurable in nearly all network infrastructure devices sold today. As with any management protocol, if not configured securely, it can be leveraged as an opening for attackers to gain access to the network and begin reconnaissance of network infrastructure. In the worst case, if read-write community strings are weak or not properly protected, attackers could directly manipulate device configurations.
Cisco has recently seen a spike in brute-force attempts to access networking devices configured for SNMP using the standard ports (UDP ports 161 and 162). Attacks we’ve observed have been going after well known SNMP community strings and are focused on network edge devices. We have been working with our Technical Assistance Center (TAC) to assist customers in mitigating any problems caused by the brute-force attempts.
While there’s nothing new about brute-force attacks against network devices, in light of these recent findings, customers may want to revisit their SNMP configurations and ensure they follow security best practices, including using strong passwords and community strings and using ACLs to restrict access to trusted network management endpoints.
Cisco has published a number of best practices documents for securing the management plane, including SNMP configuration:
The city in the forest—Atlanta, Georgia—extended a double dose of Southern charm to Cisco in April by awarding two prestigious information security industry awards at the 2nd Annual CSO40 Awards. The awards program recognizes projects and initiatives demonstrating innovative use of security in delivering outstanding business value.
Top honors went to the teams representing Cisco’s Enterprise ACL Management (EACLM) and Unified Security Metrics (USM) projects. Team members included: EACLM – Mark Sullivan, Network Engineer and Oisin MacAlasdair, Technical Staff and Security Prime for networking; USM – Gerwin Tijink, Information Security (InfoSec) Architect, Hessel Heerebout, USM Program Manager, and Ranjan Jain, IT Architect and Security Prime.
As the famous saying goes, “Good things come to those who wait”. Delayed gratification – person’s ability to forgo a smaller reward now for a larger reward in the future – has been linked to better life outcomes as demonstrated by the often cited Stanford Marshmallow experiment and others. In most cases though, it requires a degree of self-control not easily achievable in today’s fast paced, ever-changing world with new mobile devices, protocols and technologies.
If you are one of the Cisco Wireless customers currently deploying Release 7.0 MD and waiting for the next Cisco Wireless Software Maintenance Deployment Release, the wait is over!
Release 22.214.171.124 has achieved Maintenance Deployment (MD) status.
Release 126.96.36.199 is the recommended MD release for all non-802.11ac deployments. For 802.11ac deployments, Release 188.8.131.52 (Release 7.6 Maintenance release 1) is the recommended release.
Cisco’s been doing virtualization in various forms on the network side for quite a long time. One incredibly powerful feature that I think is still amazingly under utilized is the Cisco VSS or Virtual Switching System.
The ability to make two 6500’s look like a single switch so that you can have your cake and eat it too. Its the epitome of giving us the redundancy and availability we need while simultaneously allowing us to use the extra capacity that could normally sit unused. Easier management and configuration make this a no-brainer that more network managers should consider as ‘required’ in their design. Check out our ‘Fundamentals of VSS‘ to get yourself started.