Skip to main content

Best Practice Network Design

This is a template for a best practice network design. This is a deviation from the traditional dual skin firewall plus DMZ design. My opinion is that this one is more practical and secure (never understood or saw the benefit of dual skin?) This is my first doodle of it on Powerpoint, the initial one was a drawing on a napkin.
  • All unused ports must be disabled!!!
  • Routers should be used to bin generic classes of undesired traffic before it hits any firewall. Routers should be intelligently and securely configured. They are another security skin and should be leveraged!
  • The company uses Private IPs on the internal and DMZ networks. The external router bins Private IP addresses while the internal core bins any connections that have an Internet IP as the originating address. The external router also bins any unknown protocols not provisioned in the DMZs.
  • All three parties are handled with IPSEC to the remote location and terminated in a DMZ.
  • A choke VLAN exist which enforces an inspection point for IDS and IPS systems.
  • The servers in the data center are protected by a separate firewall. All business unit servers are in separate VLANs, i.e. HR servers cannot connect to Finance servers without an explicit rule in the data center firewall. This firewall has no NAT, only a rule base.
  • External connections are facilitated via reverse proxies hosted in a DMZ.
  • Email is relayed via a bridge head in a DMZ. Use is made of mail scrubbing services like Mimecast or Messagelabs.
  • DNS is forwarded to OpenDNS.
  • Workstations are separated into functional business unit based VLANs. The core bins any incoming SMB/CIFS shares to the workstation VLANs. This stops any worms and Trojans in its tracks and prevents information leakage.
  • On the inside networks all route distribution is authenticated, especially routes between the firewalls and the core.
  • A separate network management VLAN should exist, accessed off the core and protected by ACLs. This VLAN should not be accessed via a firewall to prevent non-access situation.
  • The management VLAN should contain jump servers which are the designated point to access all network device and firewall consoles.
  • Don't publish intranet on port 80 but rather use port 8080 to 8090. This will assist with controlling web traffic.
  • Use the url filtering abilities of the firewall backed up by OpenDNS categories. Don't use proxies.

    Here is a more complex systems design with multiple firewalls:


Popular posts from this blog

Why Madge Networks, the token-ring company, went titsup

There I was shooting the breeze with an old mate. The conversation turned to why Madge Networks which I wrote about here went titsup. My analysis is that Madge Networks had a solution and decided to go out and find a problem. They deferred to more incorrect strategic technology choices. The truth of the matter is that when something goes titsup, its not because of one reason only, but a myriad of them all contributing to the negative consequence. There are the immediate or visual ones, which are underpinned by intermediate ones and finally after digging right down, there are the root causes. There is never a singular root cause for anything but I'll present my opinion and encourage everyone else to chip in. All of them together are more likely the reason the company went titsup. As far as technology brainfarts go there is no better example than Kodak . They invented the digital camera that killed them. However, they were so focused on milking people in their leg

Flawed "ITIL aligned"​ Incident Management

Many "ITIL aligned" service desk tools have flawed incident management. The reason is that incidents are logged with a time association and some related fields to type in some gobbledygook. The expanded incident life cycle is not enforced and as a result trending and problem management is not possible. Here is a fictitious log of an incident at PFS, a financial services company, which uses CGTSD, an “ITIL-aligned” service desk tool. Here is the log of an incident record from this system: Monday, 12 August: 09:03am (Bob, the service desk guy): Alice (customer in retail banking) phoned in. Logged an issue. Unable to assist over the phone (there goes our FCR), will escalate to second line. 09:04am (Bob, the service desk guy): Escalate the incident to Charles in second line support. 09:05am (Charles, technical support): Open incident. 09:05am (Charles, technical support): Delayed incident by 1 day. Tuesday, 13 August: 10:11am (Charles, technical support): Phoned Alice.

Updated: Articles by Ron Bartels published on iot for all

  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all .  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all . Improving Data Center Reliability With IoT Reliability and availability are essential to data centers. IoT can enable better issue tracking and data collection, leading to greater stability. Doing the Work Right in Data Centers With Checklists Data centers are complex. Modern economies rely upon their continuous operation. IoT solutions paired with this data center checklist can help! IoT Optimi