Community discussions

MikroTik App
 
andcz
just joined
Topic Author
Posts: 5
Joined: Tue Mar 20, 2018 10:36 am

RB750Gr3 (RBhEX) and a proper setup for DVR/NVR isolation

Tue Mar 20, 2018 10:58 am

Hello all,

at my home, I'm connected to a W-ISP via theirs WiFi as a client. This represents WAN for me, and as such it is connected to RBhEX WAN input,
while the rest of the RBhEX eth. ports are connected to a local LAN devices (computers, wifi AP, and such stuf, with the obvious NAT and Firewall setup).


The "issue" which I would like the experienced people in here to help me out with, is:
how to connect the linux-based DVR (NVR) box which is "made in china", and which is obviously absolutely not to be trusted (could be hacked due to a poor design, or already might contain a malicious firmware or hidden linux applications that would probe my network or send video data to someone else, and such).

I do have a friend doing a maintenance on Huawei kits for mobile operators, and what he showed me is terrifying (the devices stream all the data to china, continously, and the worst part is that all the O&M has to go through Huawei HQ, so if you want to change a configuration, you have to call them, and they do it remotely from china, brrr....).
I'm quite sure that basically any other device (as the DVR is) would eventually do the same, just run the wireshark and watch.


So back to the topic:

I'm looking at the NVR4108-8P-4KS2 box (see the PDF, first link found on google: http://www.cctvcentersl.es/upload/Catal ... P-4KS2.pdf and on many other places through inet).
The beautiful thing about this box is, that it contains its own, physically separate PoE switch, for all the IP cameras connection - so I do not have to connect the cameras through any outside switch.
Beside the cyber security risk, such a DVR box is quite a great solution for a reasonable price (in fact, should Mikrotik build their own, I will buy it right away much rather than something from a chinese company).

Now, to the question itself:
How to properly isolate the DVR from the internal network (house LAN) and from the Internet (WAN), while allowing for the remote access (using a mobile application to view the DVR output).

I'd like to have that one RBhEX ethernet port connected to the DVR box - to be extra firewalled (limited), while the rest of the RBhEX ports will stay generic and with a default (yet secure) set of firewall rules. Is this even possible with the RBhEX hardware, and if yes, then how.

Or in general, does anyone have any further tips on how to set the whole thing up, and how to properly secure it, would be more than welcome.
I would suppose that many people are connecting such chinese boxes, and are not actually worried about the "trojan horse" these boxes do represent.
So any proper guidance would be more than welcome, for sure on my side it will.

Also, are there any greylist/backlist lists of IP addresses, which are somewhat "official" and could be somehow downloaded to RBhEX, so it will block the outgoing LAN traffic (e.g. blocking any internal on-LAN device to open a UDP/TCP connection to WAN, if the target IP is blacklisted). Also, does RBhEX firewall block things such as "ping tunnel" or non-udp/non-tcp malicious traffic (LAN to WAN)?

thank you,
a.
 
andcz
just joined
Topic Author
Posts: 5
Joined: Tue Mar 20, 2018 10:36 am

Re: RB750Gr3 (RBhEX) and a proper setup for DVR/NVR isolation

Mon Mar 26, 2018 3:50 pm

No ideas, anyone ?

How to set up the network, hardware and firewall to do the job ?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11266
Joined: Mon Dec 04, 2017 9:19 pm

Re: RB750Gr3 (RBhEX) and a proper setup for DVR/NVR isolation

Mon Mar 26, 2018 11:38 pm

No ideas, anyone ?

How to set up the network, hardware and firewall to do the job ?
Basically you have to create three networks on your hEX - WAN, LAN, and Hainan (which is a Chinese island).

A "network" here means a dedicated local IP subnet and, in case of LAN, also a bridge. I assume you'll dedicate just a single Ethernet port to the WAN connection and a single Ethernet port to the connection to the DVR so there is no need to create a bridge for these subnets.

You can use
/interface list
to translate the interface names (like
ether1
) to symbolic names (like
WAN
), or you can use the interface names directly. If you have a single interface per each network, there is probably no point in using interface lists, so substitute e.g.
ether1
for
WAN
,
ether5
for
Hainan
, and
bridge-lan
for
LAN
in the text below.

Now your firewall rules would deal with each of the three networks separately. So you would permit icmp to flow freely, but permit new connections to the hEX's own addresses using any other protocol than icmp to be initiated only from LAN, and permit any connections already established, using the following rules:
/ip firewall filter add action=accept chain=input protocol=icmp
/ip firewall filter add action=accept chain=input connection-state=established,related
/ip firewall filter add action=accept chain=input connection-state=new in-interface=LAN
/ip firewall filter add action=drop chain=input
For traffic traversing the hEX, you would use similar rules in
chain=forward
to permit devices in LAN to establish connections to both internet and to Hainan, but devices in Hainan would only be allowed to initiate connections to public addresses on a list (if at all):
/ip firewall filter add action=accept chain=forward protocol=icmp
/ip firewall filter add action=fasttrack-connection chain=forward connection-state=established,related
/ip firewall filter add action=accept chain=forward connection-state=established,related
/ip firewall filter add action=accept chain=forward connection-state=new in-interface=LAN
/ip firewall filter add action=accept chain=forward connection-state=new in-interface=Hainan out-interface=WAN dst-address-list=dvr-whitelist
/ip firewall filter add action=drop chain=forward
The NAT rules are common for LAN and Hainan (what goes out via WAN must be src-nat'ed to its address); if you want to use some kind of VPN, it should be treated the same way as LAN in terms that VPN clients can initiate connections to devices in Hainan but not vice versa.
 
andcz
just joined
Topic Author
Posts: 5
Joined: Tue Mar 20, 2018 10:36 am

Re: RB750Gr3 (RBhEX) and a proper setup for DVR/NVR isolation

Tue Mar 27, 2018 9:24 am

Awesome, thank you.

Will give it a try and post results.

Yes, each ethernet port will be dedicated to a single target (wan, lan, dvr).

Just to check - all the etherX ports are switched in HW, so - will the switch chip isolate each port ?
e.g. is it enough to just set up the firewall rules, to obtain a "physical" port separation, even though all ethernet ports are wired to the same ethernet switch chip ?
I do assume yes, but just want to check.

One thing I'm yet to investigate is to capture the minimal subset of the required connectivity (protocols), required for the DVR to work just properly.
I do want an access to DVR from both LAN and WAN, but also to limit the IP ranges (address-list), protocols and all the other stuff.
I assume I will run packet capture / torch and - I will see (and post the results here, maybe it will help someone else).

-

Again, looking at the proposed firewall configuration, it looks awesome and exactly what I've been looking for. Thumbs up !
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11266
Joined: Mon Dec 04, 2017 9:19 pm

Re: RB750Gr3 (RBhEX) and a proper setup for DVR/NVR isolation

Tue Mar 27, 2018 9:57 am

Just to check - all the etherX ports are switched in HW, so - will the switch chip isolate each port ?
e.g. is it enough to just set up the firewall rules, to obtain a "physical" port separation, even though all ethernet ports are wired to the same ethernet switch chip ?
I do assume yes, but just want to check.
It depends on the switch configuration. Unless you configure the switch chip manually otherwise, each Ethernet interface which is not set to be a member port of a bridge is isolated from all the others, i.e. the switch chip only forwards packets between that Ethernet port and the CPU port, notifying the CPU at which port the packet has been received. One group of ports can be set for direct mutual forwarding by the switch chip itself; in software 6.41+, this is the first bridge with more than one member port, in software up to 6.41, this is a single "master port" to which the other ports of the group are linked as slaves. All other bridges are implemented in software on the CPU.

Things become more complex when it comes to VLANs, but I guess that's not your case.