Shrouded in a unique CLI with its own Order of Operations the much-loved or loathe firewall rules a majority of networks with an iron fist. The adulation of this bastion of permission (or the chagrin of expensive DC heater) all comes down to a point of view. The firewall provides many features in the modern network that provide security, integrity, and a strong anchor point. I have been surrounded by firewalls for a while now and have started to appreciate the nuances on the platforms.
The more I become exposed to them the more they reveal their secrets. The masters of packet manipulation, strong screen controls, and advanced security features take only hours to learn but years to master. Such technologies like Object groups, ACLs, VPN, IPS, Anti-virus, Web-redirect, and NAT, NAT, oh and NAT can trip up the most immersed engineer.
These posts aim take some time to appreciate the firewall. There will come a time when the definition will find the software network (see what I did there) and firewalls will become less required. As SDN and NFV spreads with clarity, the firewalls traditional role will evolve. For now, as I have come across, there are many thousands of physical and traditional firewall installs. There are many poor and misunderstood olive and blue coloured boxes lying around and pushing packets. This blog series, a first by networkinferno.net, will cover off the following topics:
- Business requirements influence all designs and technology solutions. One key part of a solution that meets business requirements will generally be a firewall. What is an integral part is understanding the role it will play in your network.
- Interpreting requirements is a balance of understanding the requirements and managing expectations. If a customers requirements is to meet compliance you need to find out more. HIPPA, SOX, PCI, or internal compliance? That may include tenant isolation, VPNs, with IDS functionality, one of these technologies or none. A good engineer can design a network. A great engineer can design a network meeting all constraints.
- Understanding and establishing firewall types is as important as anything discussed. Knowing the tools in your box, the different types of tools at your disposal, and being intimately familiar with them is important. Physical transparent might be required in one solution where hypervisor solution might be required.
- Managing a solution from a single box to a thousand boxes is no mean feat. There are many tools at your disposal for firewall management from CLI, vendor application, to third-party monitoring solutions.
- Documentation. The bane of many engineers existing and something that will make the next engineer to work on this device rue your name if you’ve not done it. Covering what to document, how much to document, defining a naming convention, and methods of storing information are covered off.
- Device life cycle strategies are important. There are very few businesses who deem it appropriate to spend without planning. Discussions that need to be had should be along the lines of maintenance routines, rule updates and audits, and the eventual hardware (or software) refresh.
- Will firewalls decline in rise of the software defined flow? The discussion of the future of the firewall beyond the next generation is always interesting and there are many perspectives on this.
This series aims to provide the reader with a set framework on approaching a firewall deployment. The first two posts , 01 – Business requirements and part 02 – Interpreting Specifications have a generic flavour which can be applied to all project works. The rest of the series takes a look at working with a firewall focus. The information provided in this series will allow someone to approach the considerations of a firewall upgrade, touch on some of the drivers, and consider the impacts of the install. With an end to end life cycle of approaching a business problem right through to incorporating a business life cycle program I hope to touch on the key facets of a firewalls journey from cradle to grave.
This is my first public attempt at a cohesive series. I am more happy for feedback. In fact, I would appreciate this. My series is designed to be a reference piece for many people and I am only a humble engineer. The whole is a better than the sum of its parts and I do not know everything. I don’t even come close. If you feel I have erred, or have a different insight, please email me or reach out in the comments.