Wisdom of putting a Raspberry Pi on a production network

backtracker

Just as it says, would any of you do it? This implementation would use a VLAN to separate it out from the business related resources, so maybe not exactly how I presented the title, but I figured it sounded more dramatic. Is a VLAN segmentation on a Cisco Meraki infrastructure going to be sufficient to separate this type of device?

Open to any advice, flames or pointers you may have!

yoba222

If I found a Raspberry pi on the network the first thing I'd try would be to login with the default user/pass As far as being wise or unwise, I mean people put much worse things on the production network, like Windows XP . . .

UnixGuy

a fanboy tried to put a Raspberry PI and wanted to configure it as a honey net on the network....




I said No. 

paul78

I don't particularly have an issue with it. It's really just like anything else that you may place on a network. It depends what you are using it for - and if you have good security practices and like patching, monitoring, etc. it's usually fine.

Mooseboost

It is no different than putting any other device on the network. I have worked in and consulted for environments that use them for various things (script runners/controllers/dispalys/etc) and the threat they introduce can be minimal if you harden them properly. The first question I would ask you is: Why a pi? Is it a cost-driven decision, fanboy attraction, or form factor? What alternatives are available? If you can make the justification for it and are wiling to take the time to do it right, then there isn't a problem with having them. Just throwing them on the network out of box can be a problem though.  

UnixGuy

you guys hit the nail on the head...it's like any other machine.. .IF it's gonna be managed/patched/monitored...etc. 

Most places have issues with managing and patching normal Windows machines...I didn't think they'd be successful manually managing Raspberry Pi.....

Also...why? I never got a good enough reason to be honest. 

EANx

My org has firm standards regarding the specific hardware allowed on the network. I don't have a problem with a Pi (in theory) but am a fan of documentation and process to avoid surprises.

ecuison

My colleague had to deal with this.  I don't recall the result, but I was pushing for a separate vlan with whitelisted access to the port level/service level.  Thats how I would treat it since it was requested outside of IT.  

I'm not shocked that organizations want to use these micoboards for some weird implementation.  When I worked for this GIS company years back, at the time, the developers wanted to buy the Xbox Kinect to develop GIS applications to integrate it's use.  I really think the developers wanted to dance off playing Dance Central on the Xbox 360, but they got them. 

backtracker

I appreciate the responses...interesting the consensus isn't completely against it.

The devices were gifted to the organization and will be used to display video/images to a TV. Costs are a huge factor so they utilize what they have to a large degree. The politics are strong here, stronger than logic or reason. Unfortunately there is no real plan to harden the device other than disabling its wireless interface and sandboxing it on a VLAN not able to reach internal company resources. What else would you guys suggest? I like the idea of creating a white list of IP's that can connect to it. No one on the team has any meaningful Linux skills, hence my major hesitation with it- worse it will largely be in the hands of users in an unsupervised environment with no direct on site IT presence. Patching and device management will not be happening, again something I did my best to impress upon organizational management. I'm doing my best to document the potential liabilities and plans to separate it from the network. The documentation has historically been weak at this org. and the thought of creating these types of "one offs" seemingly create a support nightmare along with potential new attack vectors on a network with an otherwise weak security posture.

paul78

I appreciate the responses...interesting the consensus isn't completely against it.

The devices were gifted to the organization and will be used to display video/images to a TV. Costs are a huge factor so they utilize what they have to a large degree. The politics are strong here, stronger than logic or reason. Unfortunately there is no real plan to harden the device other than disabling its wireless interface and sandboxing it on a VLAN not able to reach internal company resources. What else would you guys suggest? I like the idea of creating a white list of IP's that can connect to it. No one on the team has any meaningful Linux skills, hence my major hesitation with it- worse it will largely be in the hands of users in an unsupervised environment with no direct on site IT presence. Patching and device management will not be happening, again something I did my best to impress upon organizational management. I'm doing my best to document the potential liabilities and plans to separate it from the network. The documentation has historically been weak at this org. and the thought of creating these types of "one offs" seemingly create a support nightmare along with potential new attack vectors on a network with an otherwise weak security posture.

Your use case isn't particularly unique. Most companies that I encounter have something that does this. I'm just kinda surprised that a Raspberry Pi device is more cost effective than a Chromecast or FireTV Stick.

A separate vlan makes sense!

Hey - at least you are consider the security impact. I've seen worst for this use case.

Tekn0logy

UnixGuy said:

Also...why? I never got a good enough reason to be honest. 

Prod networks SHOULD have a honeypot to see if somebody is snooping around trying to log into things they don't have any business touching. Another good thing for a Pi is Bro IDS. The beauty of the Pi is its almost non-existent footprint. However, using these to provide user content is probably a really bad idea.

DZA_

My old organizations had probably a dozen Raspberry Pi's if not more for the sole purpose of using them as machines running dashboard software that would be displayed against the TVs around the office. Physically they were secured in server rack. As much of the folks here proposed, as long as the machines are properly hardened security policies, physically secured then it's all game to use them in the company. Mind you that you get the proper approvals before anything else. 

backtracker

I appreciate all the input! I'm glad to hear there are others that use the devices in similar ways. In regards to the Chromecast suggestion- several of the sites do in fact use those, this is the first to use something outside of that.


I see the positives and negatives of it, and did my best to present this information to the key decision makers. In the end, they decided to give in to the powerful "C" level execs that want them at their sites. I guess we will find out first hand over time if these present long term security implications. 


Still going to check into some of the further suggestions like building a white list and checking into physical security. Thanks again for the advice! 

UnixGuy

Tekn0logy said:

UnixGuy said:

Also...why? I never got a good enough reason to be honest. 

Prod networks SHOULD have a honeypot to see if somebody is snooping around trying to log into things they don't have any business touching. Another good thing for a Pi is Bro IDS. The beauty of the Pi is its almost non-existent footprint. However, using these to provide user content is probably a really bad idea.

Sure, but why use Pi for a honeypot, why not normal servers??

Why would they use Bro IDS when they have an actual vendor supported IPS/IDS ?

JDMurray

A Pi is a valid IP host, is easily identifiable by its MAC address (Raspberry Pi Foundation OUI = B827EB), and can be managed just like any other IP host. Just make sure that your asset and configuration management systems support Pi hardware and whatever host OS(es) it is running.

Mooseboost

For their use case, you are doing what I would typically recommend. Create a media VLAN that is segmented from the internal network and put those devices on it. I would recommend changing default credentials unless you want locals messing around with them. 

backtracker

Mooseboost said:

For their use case, you are doing what I would typically recommend. Create a media VLAN that is segmented from the internal network and put those devices on it. I would recommend changing default credentials unless you want locals messing around with them. 

That is exactly the VLAN schema we are using essentially, no routing to internal resources at all. Good advice on the local credentials, I'll have to see if we can work this into the hardening suggestions- they are actually not the defaults, but not currently managed by IT either. Appreciate the continued responses, great food for thought....