Hi, the latest The State of Robotics on Ubuntu blog mentions a ROS securing guideline created by CI Security. It links to https://www.cisecurity.org/benchmark/ROS/ . I’ve registered there, opened the link sent by email, but there is still no button to download the PDF. Did anyone succeed?
@peci1, you should be able to find it at https://workbench.cisecurity.org/benchmarks/5207/files. I can see the following:
PM me if you don’t manage to get it and I’ll forward it to you.
Thanks, this leads to a completely different part of the website than the link from Ubuntu blog, but I successfully downloaded the PDF
No problem, ping me if you struggle to implement any of the items.
I was first surprised and then dissapointed that you need to go through a complete process to get the tools they offer, only to find they weren’t that useful to us (or anyone aiming to secure robots).
Our team built a while ago scripts to fix most of the items for multiple robots. We’ve accumulated a much richer list of security checkpoints but ours diverges a bit and is robot-specific, instead of OS-specific.
Yeah, skimming through it, it really seems that the tip with ROS_HOSTNAME=localhost
is the only valuable takeaway from it… Other things are just in the style “disable all services you don’t need” and it seems like a copy-paste from a knowledgebase…
That’s awesome, do you think some of these tools and checkpoints could make it into the CIS benchmarks ? Could you provide links to the aforementioned scripts and checkpoints list? they sound like valuable things for the community that would benefit from more visibility.
Since we’ve diverged quite a bit, I don’t think it makes sense to add to CIS directly. Also, I’m a bit hesitant of whether the mission behind those benchmarks actually “fits well” with the ROS community and robotics, overall. Maybe it develops nicely, I’m optimistic!
I’m tempted to create a “ros-hardening” repo and start pushing there contributions but frankly, I’ll just launch the idea here and see whether someone takes the lead with it and encourages contributions.
To be honest, for now, I’ve given up quite a bit on the community-driven security work (ROS Security WG). It’s very discouraging to see valuable contributions that never get accepted or the core of the project (sros2, which you know well and I’m very thankful for) not being pushed actively by the leading firm behind the WG. IMHO bad security decisions are being made and after several rejected initiatives from our end, we’ve forked the security tools and continued developing.
For now, happy to answer questions if anyone struggles to implement a given particularly security measure.
A place for hardening guidelines and tools sounds like a great idea to me. If this doesn’t conflict with your business model, it looks like getting these tools out there (regardless of who “takes the lead on it”) would be a good way for people to use them, give feedback and contribute whatever they feel useful additions.
If people contributing to the CIS benchmark end up cherry-picking whatever fits well with the CIS philosophy, even better.
Not to diverged too much from the original topic, regardless of the exact place things are being hosted or who pushes the work forward I’d love to see such tools get more visibility and widespread use.
Although spare cycles are rare, I still happily (slowly) review any contributions to sros2 so if you ended up forking sros2 I’m interested in seeing what can be integrated back into the project.
There are a limited number of knobs to turn that are specific to ROS 1. Indeed, most of the benchmark is a curated subset of the Ubuntu benchmark. You can’t lock down ROS and ignore the OS on which it’s running. The converse is also true: no matter how secure your OS, exposing ROS 1 comms leaves essentially a wide open attack surface. That said, it’s an open and community-driven effort, if you know of more knobs, suggest edits!
It’s a community initiative-- the way to ensure it develops nicely is to join the community and contribute!
I don’t know of any contributions to SROS2 that were rejected. Always happy to review, there .
Agreed!
I think you may want to re-read that @kyrofa, “valuable contributions or sros2 ones” . Security is way (way!) beyond the tooling (and by no means this disregard the importance of sros2, just states a reality). Refer to the pending (and closed) issues of the group to name a few .
Yes, I was responding to the “or sros2 ones” bit, because that’s the thing we actually maintain. We’re really getting off topic here, but I want to point out (again) that the security WG not wanting to dedicate cycles to own and maintain your separate project does not imply that we see no value in your project. Just that we don’t want to dedicate cycles to own and maintain it. We can’t maintain and drive every project that comes our way. I’m sorry you take offense at that, but there’s really none intended .
We’re definitely off-topic @kyrofa but I’ll remark that Canonical (you) is deciding what to support and what not. Alias Robotics volunteered to put the resources (our time ) to support these projects. To drive them and to continue bringing value to the community as reasoned at https://github.com/ros-security/community/issues/6#issuecomment-678430031. You’re just discarding efforts because it simply doesn’t align with your interests! With Ubuntu’s interests.
I think nobody expects you to get involved. In a group, there are different projects, led by different sub-groups (look at how it’s happening elsewere). It’d certainly be great to get more and more people interested in looking for security flaws in ROS code, and beyond running a static analyzer and filing PRs ( ), reasoning about PoCs, priorizing tickets based on severity and/or eventually (I hope), accelerating the mitigation of the many security flaws existing in ROS.
After so many years contributing to ROS, I’m surprised see how groups like the Security WG (which by the way, Alias has been pushing since earlier you even joined) are being lobbied by a single company this way. There has never been an open discussion about our contributions to the group and proposals. And frankly, you’re coming up with rules on-the-go.
Worse, the WG is now halving now its activity, decreasing more and more! But you (yourself) get to decide what’s worth maintaining and what’s not? Come on!
Wanna make things right? Start accepting contributions, bring things up to proper group discussions and encourage contributions in other directions, not just in the one that you’re lobbying for.
I’m sorry @peci1, this has quickly become non-constructive. I hope the CIS benchmark proves helpful to you, and if you see something missing, join the community and start logging tickets, or proposing edits! We’d love to see you there .
I am going to slow this down because, quite frankly, ROSWorld is tomorrow and I am really busy. This discussion has drifted off topic and to some not so friendly areas. My preference would be for everyone to have a friendly chat over beers at the happy hour tomorrow.
Yeah, thanks. The off-topic discussion was interesting, too, but you’re right that it is offtopic.
I’ll keep it in mind and if we face some security-related issue worth sharing, I’ll try to add it.
Another OT:
Last month our sysadmin killed one of our world-open servers running gazebo-ROS simulations, because he said the server started doing thousands of unsuccessful connection attempts to an IP in America (we’re in Europe). Unfortunately, he didn’t give me time to collect any logs or investigate. It seemed like a hack, but I’ve no idea how somebody could convince the server via ROS to make lots of unsuccessful connection attempts… Maybe it wasn’t ROS at all, but who knows.
Oh yeah, rough, I’m sorry that happened to you. I agree, it’s hard to know what was going on there without the ability to investigate, but it indeed sounds fishy. Was that part of your CI infrastructure? I recommend at least keeping such things on an internal network (or behind a VPN) if you can swing it, regardless of the use of ROS.
Nope, it was an experiment we were running, and we basically did not think anyone would be interested in our ROS ports, and even if he were, the worst thing he could do would be to stop or alter the simulation, which we were kind of fine with (compared to the other option which meant properly securing the simulation server).
Anyways, we feel a really big sadness about ROS 1’s inability to work within a given range of ports. If that could be possible, they could be reserved for simulation and exposed via some firewall, while other ports could still normally face the internet without fear… I think this is ROS 1’s biggest security flaw. Have you found a good solution for that?
Hi @peci1, thanks for pointing out the missing link, I’ve forwarded it off to CIS.
There are two things to keep in mind as you look at any CIS benchmark:
Most importantly, these are geared towards the enterprise. The benchmark itself is essentially an XML doc, and CIS renders it into different formats for security automation (SCAP). As you review & adjust settings in the .pdf, your security team will review and adjust the same settings in their network scanning platform (e.g., Qualys, Rapid7, etc.; most tools import the CIS SCAP files). Net result is that systems in compliance with a CIS benchmark–particularly when compliance is maintained by a vendor–can easily roll right into an enterprise security management program.
In addition, the benchmarks are 100% community driven. Settings are not defined by CIS nor by any vendor, but by a group of system users that meet regularly to propose configurations. Recommendations come from operational experience, hacks, audit findings and knowledgeable admins hardening their enterprise.
Right now the CIS ROS benchmark is a community of one (me ) plus the CIS facilitators. We’ve been meeting every two weeks; we’ll be here for you whenever you’ve got some more ways to harden ROS or need to fork the benchmark for another distro.