Here are two things I've been thinking about recently: The first is a way to increase network security, and the second is a way to ease administration. However, I'm not at all sure they're good ideas, and I'm looking for input from the Fuel Community. After reading this blog post, there will be a chance for you to start a discussion with me and share your comments, questions, and ideas. Let’s come up with the pros and cons of each idea, expand the ideas and start discussions on your own ideas.

Idea 1: Private VLANS

I'm a network guy, not a coder, so my knowledge of malware is basic. I have the idea that once a machine is infected, one way for the malware to spread is for it to listen in on network conversations and learn MAC addresses. The malware can then send udp/tcp packets to these MACs to try to start conversations on vulnerable ports¹. Could we add security at the network layer to eliminate the possibility of these conversations? 

I think we could, by using isolated, private VLANs — or pVLANs. 

I know of Cisco’s private VLANs, but I'm sure they're available on other switching platforms, too. There are two types of pVLAN: community and isolated. In a community pVLAN, each of the access-ports can talk to the other access-ports. In an isolated pVLAN, which is what I’m suggesting, the access-ports can only talk with “promiscuous” access-ports, not to each other. 

Unless you're sharing files on your hard drive or a locally attached printer, I can’t think of any situations that demand workstation-to-workstation communication, so why not have them connect to switch-ports in an isolated pVLAN? 

In a standard layer 2 (L2) access switch, supporting access ports in several VLANs, with trunks to layer 3 (L3) distribution switches, all of the workstations would be connected to normal, isolated ports; the ports supporting the VLAN trunks to the L3 distribution switches would be promiscuous. The promiscuous ports are needed for the workstations to reach their default gateway, an SVI (VLAN interface) on the core switch. 

Discussion Point:

Wouldn’t this also allow workstations in a pVLAN on one access switch to talk with workstations in the same pVLAN on another switch? It’s not just a trunk to the SVI, but also to the other L2 switches. 

In theory it is: Let’s say VLAN 100 is supported on two access switches, switch_1 and switch_2, connected by a pair of L3 routing switches, and malware is running on a workstation connected to switch_1. 

The malware will not be able to communicate with other workstations connected to switch_1, as it’s a pVLAN. But what about those connected to switch_2? If it knows the MAC of a workstation on switch_2, it will send a frame to that MAC, which will be received by the promiscuous port on switch_1. This port will then forward the frame to the L3 switches, which will forward it to the promiscuous port/s on switch_2, and hence on to the second workstation. But how would the malware ever learn of the MACs of other workstations? 

When a workstation on switch_2 first responds to a host on another network, it will need to ARP for its default gateway, i.e. a MAC broadcast to the entire pVLAN. Only the promiscuous port/s on switch_2 will hear it, but they will forward it to the promiscuous port/s on switch_1, which will forward it to all the other ports in the pVLAN. Hence, it will be heard by all the workstations, including the malware on switch_1. 

Would this work? Would it be worth the hassle? Can we get around the switch_1, switch_2 issue described above? Do I have the right idea of how malware propagates? Can malware propagate through L3 routing as easily as it can through L2 switching? 

I've talked about this with a few people, some of whom have thought it would work, but none of them have been willing to try it in production. 

Let me know your thoughts, questions, or if anyone has tried it in production. 

Idea 2: Let Security Profiles Secure Outbound Internet Access

The goal of this idea is to make the ruleset securing outbound Internet access from normal user workstations smaller and easier to manage. I want to stress it should only apply to normal user workstations, not servers, or workstations in the finance department or C level — just the countless number of laptops and desktops used by most employees in organizations of all sizes. 

It used to be that Internet access was controlled by the IP 4-tuple: source IP, source port, destination IP and destination port. More often than not, source port was never used, and source IP was either the major networks of an organization. Taking this at its simplest measure would give firewall rules like: 

permit tcp any site1 eq 80

permit tcp any site1 eq 443

permit tcp any site2 eq 80

permit tcp any site2 eq 443

permit tcp any site3 eq 80

permit tcp any site3 eq 80

permit tcp any site4 eq 80

etc., etc., etc.

This would be made both simpler and more complicated, by the use of address groups and service groups, e.g. add_grp_ web_sites, srv_grp_ web_ports. As an administrator, what do you do when you have 30 web servers in the add_grp_ web_sites², six ports in the srv_prp_ web-services and you get a request³ to allow an additional service to 10 of the servers in the group, or to add a server, but only allowed access to four of the ports? (I know, I know, we would all create new address groups and new service groups to limit access to only that which was approved.) 

After I'd been using Palo Alto Networks’ Next-Generation Firewall (PAN NGFW), I started to think about letting my common workstations access the web using any application that was assessed as risk 1 or 2; any application that was assessed as risk 3, but was in common use; and any application that was in the application group "Permitted high risk applications." This application group is something I would have to build myself by monitoring the network traffic and seeing what the organization used, but it wouldn't be too difficult. These rules would be subject to security profiles, i.e. anti-virus, anti-malware, anti-spyware, url-filtering and wildfire. The initial idea looked promising — but then I realized that the two most common applications, web-browsing and SSL (i.e. http and https), are both risk 5, as are many of the other applications in common use and many of the specialist applications that my client at the time used. I'm sure this is a common scenario. 

My next idea was to have a few deny rules at the start of my security policies:

• Block blacklisted destination IPs
• Block blacklisted applications
• Block blacklisted ports
• Allow everything else, still subject to security profiles

After all, this is what NGFWs like those from Palo Alto Networks are meant to be good at, isn't it? 

Blacklisted destination IPs could be built from dynamic block lists and tailored to your company — perhaps IPs outside of the U.S. or Europe. I know these aren't absolutes, but it's a suggestion to start the discussion. 

Blacklisted applications would probably include VPNs, point-to-point applications, such as BitTorrent, and database applications, like Oracle, that definitely shouldn’t be connecting to Internet servers. I’m pretty sure application filters could be put to good use here. 

As for blacklisted ports, sometimes you need to rely on the basics.

Like I mentioned at the start of this article, I’m looking for some input from the Fuel community. I’ve started a discussion thread for these ideas and I look forward to hearing your thoughts.

¹ Note: I know the desktop team should have stopped machines listening on such ports, and endpoint security, like Traps, should be installed to stop bad things happening, too – but that’s not always a reality. 

² Remember these are external web-servers that your employees are allowed to access

³ A request authorized by the CRB