Internet access blocking

SOLVED
EricWenger
Here to help

Internet access blocking

If I have a device that I know is vulnerable—e.g., Win XP—that I cannot yet take out of service. Is it reasonable for me to assign it a policy that blocks internet access? Is it better to put it on an isolated VLAN?  Or do I need to create a physical air gap?

 

Does the policy built into Meraki actually prevent inbound traffic for the device from the Internet? Or does it simply deny the device outbound access to the Internet?

 

Thanks.

1 ACCEPTED SOLUTION

Disabling the port which the machine connects to is sufficient enough. This obviously stopping any form of possible network connectivity.

Eliot F | Simplifying IT with Cloud Solutions
Found this helpful? Give me some Kudos! (click on the little up-arrow below)

View solution in original post

16 REPLIES 16
BlakeRichardson
Kind of a big deal
Kind of a big deal

In what way is the device vulnerable? 

 

By default inbound traffic from WAN to LAN is blocked and LAN to WAN is open. If you simply want to block this device getting internet access you need to add in a rule to deny traffic from that machine to the WAN.

 

 

 

It’s running XP. That’s the vuln. The question is whether it makes more sense to use the built in policy for the client called “blocked” or to write a new group policy that applies some sort of firewall rule or VLAN isolation. And if the latter, what should that group policy say.
MilesMeraki
Head in the Cloud

What's the purpose of the XP client? I'd isolate it via an Isolated VLAN and then block the client to the internet via a Meraki blocking policy, this would block outbound communication.

 

The biggest question I still have though is why is it running XP and why can it not be upgraded?

Eliot F | Simplifying IT with Cloud Solutions
Found this helpful? Give me some Kudos! (click on the little up-arrow below)

Long story. But there are some pieces of medical diagnostic equipment that are essentially bundled with a computer. You can’t upgrade the computer without moving to a new set of drivers that don’t exist for newer operating systems. So, the whole bundle has to be swapped out—that’s tens of thousands of dollars. For now, I just want to prevent that machine from talking to the Internet and from receiving Internet traffic.

Does the machine need Internet Access to work - if not, air gap it.

 

If it does need Internet access for a limited function and because it is an embedded device put it into its own separate network (VLAN) and lock it right down.

 

I run into this issue with factories.  They often have very expensive machines with a very old embedded OS.  There is no way the OS can be upgraded.  If the OS got damaged it would stop the machine and be very expensive.

There is no other option but to either air gap it, or isolate those kinds of devices from everything else with a firewall (like an MX).

I could air-gap it. I have done that in the past. Frankly, for maintenance purposes, I want it to show up in the Meraki interface. 

 

There are actually several machines in that room that all run through the switch port. And none of them need internet accces, except when I want to perform some sort of maintenance without going on site. 

 

What is the best way (short of an air gap) to lock down that port—i.e., block traffic to or from devices behind that port via a policy or VLAN?

 

Thanks.

-Eric

@EricWenger I've used two approaches in the past.

 

1.Use a jump host.  A jump host is a Windows/Linux based machine that has two NICs.  One NIC plugs into the "outside" segment which you can get to via VPN (via the MX in this case), and the inside goes to the machinery.  You then VPN in, RDP/SSH to the jump host, and then RDP/SSH from there to the final machine.  This approach means that no piece of machinery has Internet access, yet you can still get to it for maintenance.  It also means nothing on the outside has direct access to it.

For my more sensitive clients - this jump host is actually left powered off, guaranteeing no access.  The jump host is then powered on when remote access is requested and permission is given, and then I usually configure it to shutdown automatically after 60 minutes so it "buttons itself up" automatically without relying on a human.  "Secure by default".

 

2. Create a group policy.  Create a rule to override firewall policies and create a layer 3 firewall rule to deny all traffic by default.  Apply that policy to a VLAN interface, and put all the machines into that VLAN.  Then add a layer 3 rule that permits only the management traffic to get onto that VLAN (this could be the IP address pool used by the VPN, or it could be an internal workstation segment, etc).  You could take it one step further, and leave the physical port shutdown except when access is needed, or I guess you could even get someone to physically plug it in/unplug it if you want to take it a step further.

So, I made a VLAN that has a firewall rule with deny default and then assigned machines in that segment to that VLAN. Then, for good measure, I turned the port to "disabled" in the settings for the switch. Sound reasonable @PhilipDAth?

Eric

 

The Iranians thought they were safe but STUXNET got them.Robot Embarassed

 

The reality is, replacement of the equipment that incorporates the PC running XP needs to be planned for, and sooner rather than later.

If you can't interface the equipment to the Master Patient Index, in a safe manner, it is always going to be a problem and issues will arise as data has to be transcribed into other systems and notes rather than seamlessly transferred. The more equipment is integrated, the more problematic the unincorporated equipment becomes.

 

Hopefully for you, this equipment is relevant to procedures with a high RPVU, which will both make its replacement more affordable and provide allies with influence.

 

If you want a real nightmare, check out how the dysfunctional British NHS was held to ransom by hackers who encrypted data on insecure devices and demanded payment in bitcoin to release the encryption keys.

 

 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel

I understand the risk. I’m working to upgrade. Looking for practical advice to mitigate risk in the interim.  

At least one large company I worked at dictated that NO unsupported devices could be connected to their network. Why permit known vulnerabilities?

 

It is a CFATS special!

THIS is why security is so important in the process/manufacturing/automation domains. Weak devices require strong protection, preferably, isolation

Karl
Here to help

I would have put the XP device on a isolated VLAN and then used the FW to block any between the isolated VLAN and all other VLAN/INTERNET. Then only do specific permits on hosts/networks that is required to access the system and that the system access.

 

Can I simply turn set the port on the switch that this device connects with to “disabled?” Everything that this device needs to talk with is actually in the same room with it—e.g., printer. Then that room feeds into a single port on an MS switch . So, if I turn that port off, isn’t that as effective as writing firewall rules and setting up VLANs?

 

(I know it’s not as good as an upgrade or as an air-gap).

Disabling the port which the machine connects to is sufficient enough. This obviously stopping any form of possible network connectivity.

Eliot F | Simplifying IT with Cloud Solutions
Found this helpful? Give me some Kudos! (click on the little up-arrow below)


@MilesMeraki wrote:

Disabling the port which the machine connects to is sufficient enough. This obviously stopping any form of possible network connectivity.


I'd go further; I would unplug it and record the hours and costs of physically visiting the equipment's location in order to do whatever "maintenance" is required. This cost information potentially gives you an additional lever to support the case for bringing forward the equipment's replacement.

 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels