Securing a drone? Tricky iptables problem

Hardware Hub Networking
1

So I got a 3DR Solo drone for Christmas, and the thing communicates over IP. It’s got a little IMX6 Linux computer in both the transmitter and the drone, and they handle sending video and commands back and forth.

Because of the way things work, you have to join the controller’s wifi network on a phone or a PC to use Ardupilot Mission Planner or other apps that communicate with the drone. But you can tell the controller to join your home wifi, making the controller an AP, a client, and a router simultaneously. This is awesome cause it means the devices on the drone network have internet access, but it’s a little dangerous since it means in theory anyone with the right routes and access to my home wifi has full control over the drone.

Since the transmitter is being a router between the drone network (10.1.1.0/24) and my home network, I figure that’s the best place to implement some security. It’s Linux, so I have iptables, but AFAIK I can’t use stateful rules because it’s missing that module.

Anyone have any suggestions on security measures? The transmitter will only auto-connect to my home wifi, which has a pfSense router, so maybe we could do some tricks there. I’d like to have a one-way sort of thing, where the drone network has internet access, but upstream networks cannot initiate new connections with the drone or the transmitter. But I’m not sure that’s possible without the stateful module for iptables.

Please advise.

2

Thats what firewalls do. Inbound traffic will be dropped if you don’t have a rule allowing the connection. Default function of pfsense.

3

Can you filter with static IPs or by MAC address?

4

I know, but it’s not that simple since I am trying to control the traffic this router forwards rather than the traffic bound for the router. It’s also not doing NAT, which makes this a little trickier.

5

I can filter with static IPs, and I considered just not allowing any traffic bound for my main home subnet, but I wasn’t sure if that would do what I wanted. Now that you mention it, that may be the best way to go.

6

Meaning you want to block LAN traffic as well?

Maybe a seperate WAP on a different subnet or vlan then.

Is the controller open source? Maybe trying to access ssh or find UART port could be beneficial. Don’t know anything about drones, just making suggestions.

7

Pics will make this thread a 10/10. Slightly interested now.

8

I seem to recall a DEFCON talk about this. I’m pretty sure it was this one. The presenter figured out how to compromise a bunch of different drones via IP due to total lack of security, and later did some stuff with GPS signals. If memory serves he had some ideas of how to secure the systems…

1 Like
9

Everything on it is OSS. The controller runs Linux and has iptables on it, just missing the states module. I can SSH into an IMX6 Linux computer on both the drone and the controller.

I’ll post pics and more info when I get home tonight

10

Pics and More Information

Here is an architectural overview of the drone, from 3DR (the folks that made it).

system-diagram.png2550x2616

The drone and the controller both run 3DR’s customized version of Yocto Linux (don’t know much about embedded Linux stuff so sorry if I am butchering terms) and communicate over IP. The controller acts as an AP as well as a DHCP server, and the drone is the client (with a static DHCP reservation).

Traditionally, to use the app to view the video feed, or to adjust other parameters on the drone, you have to connect to the isolated wifi network between the controller and the drone (10.1.1.0/24). That’s a little inconvenient because it’s got no internet, so if you’re doing developer type stuff where you need Google you have to keep swapping networks unless you have a computer with two Wifi cards.

So the wifi card in the controller is capable of being both an AP and a client at the same time, making the Linux machine in the controller a simple router. This is really handy because it means you have internet while using the drone, but strikes me as dangerous from a security perspective. By default, when you set up this router feature, it doesn’t do NAT, it just routes. If it did NAT, it could be leveraged like a one-way valve, but since it just forwards traffic between the drone network and the main wifi network, it seems to be rather dangerous to me. The Solo and the controller both have a default root password, and while I could change that, it wouldn’t fix everything. The UDP port that talks to the Solo’s Pixhawk flight controller (using MAVLink protocol) has no authentication or security to my knowledge. So basically anyone with access to the drone at an IP level has a decent chance of being able to take control.

I want to use the controller (since it’s being a router anyway) to keep the drone network off limits to outside resources, while still allowing access to the internet from within the drone network. Since it’s Linux, it has iptables on it,so my initial thought was to use the stateful module and just deny any NEW connections into the drone network. That should effectively make the one-way check valve I’m going for. But I can’t do that (unless someone here is a ninja) because it seems it’s missing the module that adds the stateful features to iptables. Whenever I try that, it tells me there isn’t a chain with that name.

So I guess what I’m asking is…how do I secure this thing with a fairly primitive iptables install? Or is the only safe option to make another, separate wifi network (I have UBNT APs, so that is an option, but kind of an ugly one) and keep the drone on that, and then use pfSense to keep it safe? I could do that, but I’d rather have security at the last hop between the drone network and the proverbial wild west, if possible.

Pics

There’s not a whole lot of this security thing you can see in pics. On the outside it looks like a stock 3DR Solo, although it is running Open Solo instead of the outdated factory firmware. (For those that aren’t aware, the gist is 3DR made the drone, then made some bad business decisions and ended up going under, but when they went under they open sourced all the code, so it is still being maintained by members of the ArduPilot community).

MtAJhbC.jpg1176x882

M9Wcs2O.jpg1176x882

m6Trz7Z.jpg1176x882

And here is a rough diagram of the logical network behind all this:

Solo_Network_Diagram

11

Update:

Can confirm limiting access to the drone at an IP level is basically a necessity. Anyone with access to the UDP port that the MAVLink protocol listens on can use MAVProxy to connect and gain full control of the drone. You can start/stop motors, take off, land, go to GPS coordinates, send RC stick commands, the whole nine yards.

So basically…this thing needs to be totally isolated from anything even remotely questionable, and I guess I’m going to have to do that with pfSense since the controller will not support a stateful firewall. Still curious if anyone has any better ideas. Maybe @wendell or @DeusQain can chime in on this?

12

You should still be able to block unwanted connections with a stateless firewall

13

But I can’t block only connections coming from an outside subnet into the drone subnet, right? Because that would require the router/firewall to differentiate between a connection to an internet host initiated by the drone (I want to allow that) and a connection to the drone initiated by some internet host (I want to reject that). Maybe I’m wrong though.

Also, hadn’t thought about it before, but since the drone itself has iptables as well, I think I could just block all INPUT connections with source addresses not in the drone subnet. Guess I should’ve considered that sooner lol

14

That’s the one.

But if you needed to do it on the controller then essentially it would be the same thing, on the interface that connects to your wifi network you just have a rule rejecting incoming traffic to the drone. I don’t really know my way around iptables so I can’t tell you the speciffic command, but you don’t need it to be stateful to do that.

15

@K4KFH
Setting it up is relatively easy. As long as you have access to the device. How are you (planning on) accessing the linux install on the remote? does it have SSH?

16

Yup. Linux installs on both the remote and the drone itself have SSH (and Bash shell)

17

If the remote acts as the router, it should already have rules set up to permit traffic to pass both ways. Then you are correct in denying INPUT traffic, I would however suggest leaving yourself port 22 open for remote management. That is if you can’t join it’s internal network.

Also, let Bryan Lunduke know it runs linux.

18

Alright. That seems to solve all my problems except any DDOS concerns. Highly unlikely it would actually happen of course, I’m mostly just curious if it’s possible to protect against. Any way I could totally block traffic at an IP level from getting to the drone using the remote? Or am I correct thinking that would require a stateful firewall?

19

Why would you be concerned with DDOS of the drone? do you often have people on your network that would do such a thing?

20

No, I’m not really concerned about it, just curious to see if there is a way you could use the controller like a gatekeeper and stop all traffic before it even gets to the drone. Don’t need it, just curious if it can be done without huge amounts of work like recompiling the kernel or something.

Maybe the best way would be to make the controller do PAT?