Should You Use Port Forwarding?

Pro Focus LLC

Yes, today you should still be using port forwarding, but make sure to use non-standard ports on the Internet facing side.

Of course a VPN connection would work as well, and would likely be more secure. However, the cost and overhead of this style of connection is limiting.

I've never been a fan of the phone home, P2P style services. One, I don't trust the providers, and two, they aren't the most reliable services.

Reactions:

(2)

(1)

Andrew Tierney

What does non-standard ports achieve?

Reactions:

Jon Dillabaugh

Pro Focus LLC

It is security by obscurity. Essentially, one hopes that a hacker is lazy or in too much of a hurry to scan all 65k ports on a given IP and they simply just scan for well known ports. If you were looking for vulnerable Dahua products, you would scan all IPs for 37777. For Hikvision, port 8000. But, if you, as an integrator or end user chose a non-standard port, like 12875, the chances of the hacker finding your potentially vulnerable device there is much less likely. It does not prevent it from being found, but it does make it much harder to find.

Reactions:

(3)

Andrew Tierney

I disagree. As the hacker, it merely slows me down by a minute or so. If you are willing to port-forward to a video device, it's highly unlikely you have any logging or intrusion prevention, so I don't really care if I go in fast and noisy.

Reactions:

(6)

Ethan Ace

A lot of port scanners and scripts I've seen sacrifice a thorough scan for speed. So it might scan all the common ports, 1-1024, and a few others, and then it moves on. Chances are you'll find more targets by scanning common ports quickly than by scanning all ports on fewer targets.

But I agree, if you're looking at one specific target, and not looking for high numbers of vulnerable devices (a la botnet), then a thorough scan is easy and unlikely to be detected by a lot of devices.

Reactions:

(1)

Jon Dillabaugh

Pro Focus LLC

How long do you anticipate it takes to scan a given public IP for all 65k ports?

Reactions:

Brian Karas

IPVM

It really does not take that long, depending on what the scanner listens for, anywhere from several seconds to maybe a minute.

Reactions:

Ethan Ace

In reply to Brian Karas

I just NMAP'd my home router. It took 6 minutes to run a port scan of all 65k ports. Plus another 2 minutes for service detection.

By contrast, scanning 21, 22, 23, 80, 443, 554, 8000, 8080, and 37777, the most common IP camera ports used: 1.7 seconds.

Even scanning a device on the LAN, the difference is 0.01s vs about 6 seconds. When you're trying to find a high number of devices to attack, "not long" can be an eternity.

Keep in mind that if you scan those ports above, you 99% of the time know what service you're getting. If you start scanning non-standard ports, you have to do service detection, and that chews up more time.

So I still say if you're attacking a single target, sure, take all the time you want. But most people are not finding an address and deciding they want to spend the next day seeing what's there. They're trying to build the next Mirai.

Reactions:

(1)

Undisclosed #4

IPVMU Certified

When you're trying to find a high number of devices to attack, "not long" can be an eternity.

Are you familiar with zmap.io? I don't think I've ever used the term game-changing* before, but I think its appropriate here:

ZMap is an open-source network scanner that enables researchers to easily perform Internet-wide network studies. With a single machine and a well provisioned network uplink, ZMap is capable of performing a complete scan of the IPv4 address space in under 5 minutes, approaching the theoretical limit of ten gigabit Ethernet.

*except sarcastically.

Reactions:

(1)

Undisclosed #7

•Jan 10, 2017

In reply to Undisclosed #7

Are you saying Zmap is 90° of Nmap or does the Z denote all integers of the positive and negative? Where would one point such a bright beam on the internet? It also makes one think.."what's inside a packet?". How fun it would be if Zmap had a plugin for Axis IP or Hikvision SAPD tool. I could save the service techs some time before they are even dispatched! I will stick with wireshark for now, thanks for the link!

Reactions:

Undisclosed #4

•Jan 10, 2017

IPVMU Certified

Where would one point such a bright beam on the internet?

You point it at the whole internet, that's the whole point.

It doesn't work synchronously like nmap, it just sends a gazillion malformed TCP/IP handshakes out there to everyone. Then it sits back and waits to see the responses.

Reactions:

Andrew Tierney

I'm not sure I get this outlook.

If the service you are running is vulnerable to Mirai-like attacks, then it doesn't matter what port you run on - it has a default password and exposing it to the Internet on any port is a massive risk.

If you feel that the service you are running is relatively secure, then it doesn't matter what port you run it on - it should remain secure regardless of exposure.

You need to remain safe from both random (Mirai) and targetted attacks. Changing default port numbers is not the solution to this problem; firewalling and VPNs are.

Reactions:

(1)

Undisclosed #4

IPVMU Certified

If you feel that the service you are running is relatively secure, then it doesn't matter what port you run it on - it should remain secure regardless of exposure.

Sometimes you can be wrong.

Reactions:

Andrew Tierney

Precisely.

You can't assume these systems are secure. They generally aren't.

The only solution is to either stop random people connecting to it using a known-secure system (e.g. a VPN) or by stopping inbound connections entirely.

Reactions:

(3)

Jon Dillabaugh

Pro Focus LLC

That's because the only host on this network is a DVR. Using VLANs or completely separate physical LANs, the only host you will reach is my DVR/NVR/VMS server.

If you want to try a targeted attack on a single host, go ahead and take your time. If there is a vulnerability, at least I didn't make it easy for you.

Reactions:

(1)

Andrew Tierney

So, even in the event that it is a single host, I still now have the ability to delete and modify CCTV recordings, or brick the device so that I can carry out a physical attack.

If anyone ever connects to the DVR over the web interface, I now have an ideal vector to put malware on your PC. Need to install an app to view the CCTV? Or run a Java applet?

A lot of VLANs also don't isolate the router properly, allowing that to be attacked.

But fundamentally, it's not adequate protection. VPN is the only real solution.

Reactions:

(2)

Jon Dillabaugh

Pro Focus LLC

A lot of VLANs also don't isolate the router properly, allowing that to be attacked.

I would like to hear more about this attack vector please. You are basically saying that the firewall in use is less restrictive / more exploitable from the internal VLAN than from the WAN side? Are you assuming the camera recorder is on a management VLAN?

Reactions:

Andrew Tierney

Very simple - on small and mid sized networks, without a specialist configuring the network, you often end up with a VLAN isolated from the other VLANs, but still with access to the router.

Reactions:

Andrew Tierney

Around 45s-60s for a typical host with a limited number of ports open. It takes no effort from my part though, so I'll just let it run of slow timing and wait for the results to come back.

The issue is that it is no harder to scan all ports than it is some ports - it does very little to protect against a targetted attack. What it does mean is that you will see less automated attacks, but if you don't have logging or intrusion detection in place, this isn't something you'll notice.

Reactions:

(1)

Paul Galburt

Port forwarding for IP cameras and other IoT devices has long been used, but has always seemed to me a bad idea for two reasons.

Setting up port forwarding for a large number of cameras is not trivial.
Dealing with the increased security risk for multiple endpoints is difficult.

However any system that uses the public Internet must have some device with a published IP address or domain address. A better system might be having a single server at a known address and have all the cameras (end points) set to open initial connections with that server which could then redirect these connections to the "real" video server if they are found to be valid streams.

These "central" servers would be the main points of vulnerability and would need to be hardened, but that is more cost effective than hardening an unlimited number of cameras. Small systems can use a single server with no redirection.

The problem with this topology is that currently cameras are designed to be servers, not clients. I think it's time for this schema to change.

Reactions:

Undisclosed #1

In reply to Paul Galburt

Port forwarding cameras to a recording server? I've never heard of that.

As to your #1 - the number of cameras at a site has no bearing on setting up port forwarding - which is done only once - in the router - to forward outside connections that hit the public IP over to the internal IP address of the recording server.

This assumes that all the IP cameras have internal IP addresses (192.168.x.x., 10.10.x.x, etc) and not public IP addresses... which I can't imagine anyone would recommend doing.

Reactions:

(3)

Undisclosed Manufacturer #2

For home use it is OK
Commercial use ? It's like put an advert in the net : I dare you to hack me

Reactions:

(2)

Andrew Tierney

In reply to Undisclosed Manufacturer #2

I disagree with this. Home DVRs tend to be worse in terms of security, and segregation worse.

Reactions:

Undisclosed Manufacturer #2

The hidden meaning of "OK" is one on one hacking is relative lower in home level.
Mass attack is always use default setting, default admin, default password.
Change a little bit will help a lot.

Reactions:

Undisclosed Integrator #3

Can someone explain the mechanics of the other option? I understand port forwarding as it is very straightforward (haha). These "cloud" based options work how exactly? I also have seen more than a few posts, lamenting performance and reduced options/features with this approach as compared to port forwarding. Can someone elaborate on that as well? Does the video have to travel back up to a cloud server first and does it increase lag time? These are real world issues my customers will not like if/when I have to switch them over.

Reactions:

Jon Dillabaugh

In reply to Undisclosed Integrator #3

Pro Focus LLC

Basically, instead of the client initiating the connection from an outside to inside connection, you have a cloud based server that the recorder makes and inside to outside connection with that acts as a proxy for the client. This is usually easier, since most common firewalls do not restrict outbound traffic by default. But, you are at the mercy of that cloud service to be running, be secure, and not limit the bandwidth between the recorder and the client.

Reactions:

Undisclosed Integrator #3

Interesting. I have one customer that is in the real estate business that owns some mini-storage buildings at a site about 50 miles away. Their receptionist has IVMS client running on a dedicated second computer on her desk and watches the 12 or so cameras all day long via internet. Think they might be affected by a change like this?

Reactions:

John Scanlan

In reply to Undisclosed Integrator #3

IPVM • IPVMU Certified

U3 - This report on Remote Network Access for Video Surveillance should help clarify the differences.

Reactions:

Undisclosed Distributor #5

I will always advocate a well thought out port forwarding setup over P2P. P2P is sacrificing security for ease of installation. The person installing the equipment has no say in how the P2P operates, by whom it is operated, how they choose to use the information they gather, specifically including the e-mail addresses of YOUR customers which are verified during registration and use, nor is anyone provided with any guarantee of service, so it can be up or down at any moment with no consequences to anyone except the end-user.

If you take the time to plan out the installation, not only physically, but also logically for the network address and sub-netting you can do this properly. Use an NVR as a single point of connection for all IP cameras and only forward the necessary ports (after changing them from the defaults) and change the default usernames and passwords. Maybe even go so far as doing some intrusion checking with port scans and other tools to ensure security and not just run for the hills once the check is in hand. Using port forwarding in concert with a DDNS service will allow you to know what is being done and why and not just slapping something together as quickly as possible to get it done and get out.

If there's an upside to P2P other than it being "easy" I'd love to hear it.

Reactions:

(1)

Andrew Tierney

There's lots of upsides to P2P (or cloud)

I've yet to see a customer's internal network breached as a result of insecurity in an external cloud system. Yet I have breached internal networks countless times due to issues with embedded/video/IoT devices that have been port-forwarded to.

Central servers can receive frequent updates, managed by a dedicated team. This just doesn't happen with video systems.

Central servers can be secured by a dedicated team, including log monitoring, web application firewall, intrusion detection systems.

If your embedded/video/IoT is compromised, it has no intrusion detection, AV, or logging to alert anyone to the fact. You can persist for months on a DVR without anyone noticing. I can also install other tools such as nmap and use the massive disks to stage data before exfilitrating it.

Central servers can have proper SSL certificates signed by a CA. This is very rarely done on port-forwarded systems.

Reactions:

(2)

Undisclosed Distributor #5

I agree with what you are saying, but I perceive what you are describing as being a well ran, professionally managed service setup. I don't see any resemblance in this to the P2P services being offered by manufacturers such as Hik or Dahua which is what my comments were geared towards.

Reactions:

(3)

(1)

Jon Dillabaugh

Pro Focus LLC

These are my exact sentiments as well.

Reactions:

(1)

Undisclosed Manufacturer #2

•Dec 14, 2016

It feels weird when surveillance industry call themselves using "P2P" To my knowledge, 100% surveillance products are not using P2P.

Reactions:

(2)

Andrew Tierney

In reply to Undisclosed Manufacturer #2

It comes from the use of the term P2P by the manufacturers. For some of them, what it means is that the connection from device to DVR uses STUN or similar to open up a connection through the firewall.

I have looked at some devices that use genuine P2P though, just for the streaming video.

Reactions:

Undisclosed Manufacturer #2

I'm really like to know which device using P2P. Hope that I can test it later.

Reactions:

Andrew Tierney

I was largely responding to this:

If there's an upside to P2P other than it being "easy" I'd love to hear it.

Port-forwarding should die. There is no way normal people can run servers on their networks and be safe.

Reactions:

(3)

Undisclosed Distributor #5

That raises the question then of "why are 'normal' people running servers on their networks if they don't know enough to manage them properly?".

The hackers and malware distributors and others like them just love to prey on the "normal" people who know just enough to be dangerous. They plug in a few ethernet cables, maybe connect a wireless printer and all of a sudden they believe they are a networking god. When this industry, which is following along the path the IT industry took about 15 years ago, decided to dumb things down so much to cater to everybody doing it themselves, security was sacrificed in the name of simplicity and lower and lower costs. Once that cat is out of the bag there is no going back. An entire subculture of network security professionals was driven basically to extinction because everyone figured they'd just do it themselves and any that are left are continuously blamed for the faults of those that attempt the DIY route and everyone suffers the fallout from events such as the DYN DDNS attack.

I think we thinking the same way, just looking at it from different perspectives. I also think port-forwarding should go away, but don't see it happening anytime soon. I saw that VPN is recommended, but will the home owner who just wants to see his backyard while on vacation through his phone be bothered to setup the necessary equipment, let alone pay the additional fees, and install the appropriate apps/software to do this? I doubt it.

Reactions:

Ilja Theuwissen

I don't want to be insulting, but I do want to make a clear point: only idiots do port-forwarding to any system that's not managed on a daily basis. The argument of a VPN connection being to costly only proves that the study of this solution hasn't been done thoroughly.

There certainly are valid, easy, secure and self-managed VPN possibilities available on the market. The overhead this generates is negligible compared to the enormous risk you put your customer in when you use port-forwarding.

Also this advice on using "non standard ports" is invalid. Security by obscurity? Bypassed with one simple automated portscan in about 90 seconds.

Don't do it. Ever. You will be hacked.

Reactions:

(2)

Undisclosed #4

IPVMU Certified

There certainly are valid, easy, secure and self-managed VPN possibilities available on the market.

You left out cheap. That might be the rub.

Also this advice on using "non-standard ports" is invalid....Bypassed with one simple automated portscan in about 90 seconds.

A bot is like a car thief. 90 seconds is an eternity for them to spend looking for a way in and tying up a socket. Unless they're coming for you specifically, it makes more sense to move on after trying a dozen well known ports and there is another car 10 ft down the street to try.

So you will definitely get less attempts; try it, I have. It's just another stumbling block, and there isn't a down side really.

Plus, the driving databases like Censys don't pull banners on anything except 80, 443, 21, 22, 23 and a few others. So non-standard ports may keep you out of the lists, which means your only going to get hits from brute force IP incremental types, and they don't have the time for dilly dallying.

Reactions:

(1)

Andrew Tierney

This ignores the risk from targeted attack. I regularly gain access to internal networks via video systems that have been port-forwarded to. They simply are not secure enough to be exposed to the Internet.

Reactions:

(2)

Undisclosed #4

IPVMU Certified

This ignores the risk from targeted attack.

No, I didn't ignore it, I said it was vulnerable in that case.

Most attempts are not targeted.

They simply are not secure enough to be exposed to the Internet.

I didn't say they were secure enough. i just said more secure using obscure ports.

Reactions:

Andrew Tierney

Sorry, I can't see where you mentioned they were still vulnerable.

Most attempts aren't targeted. They are the ones that don't hurt you as a business. It's the ones that are targeted that matter - they are when customer, financial and other confidential information is leaked.

I'm not sure I get what you are saying - is the risk level acceptable when a DVR or similar is run on a non-standard port-forwarded port?

Reactions:

Ilja Theuwissen

You left out cheap. That might be the rub.

When i sead overhead I ment all overhead, including costs. There certainly are cheap (-100 USD / year) solutions available. Anyone interested can contact me and i'll get them on the way.

So you will definitely get less attempts; try it, I have. It's just another stumbling block, and there isn't a down side really.

The downside is that you are still using portforwarding which from a security standpoint is ignorant, I'm sorry but that is the truth :-)

Plus, the driving databases like Censys don't pull banners on anything except 80, 443, 21, 22, 23 and a few others. So non-standard ports may keep you out of the lists, which means your only going to get hits from brute force IP incremental types, and they don't have the time for dilly dallying

Ok, say your argument is valid and this is a accepted "security measure". If this catches on and becomes common practice, the only thing the hackers will have to do is adjust their scripts with a few keystrokes and they will start scanning the high ports. Sure that'll take more time and maybe less systems will get infected. So "only" 5 million in stead of 20 million. Good job guys! :-)

Please calculate the cost of these infected systems. The cost of a VPN solution is peanuts compared to this.

I might sound a bit harsh or arrogant, but that's because I really know what I'm talking about and data & network security is THE great challenge for the near future.

That's why I will keep repeating untill I die :-) : Do not use portforwarding. If you sell this and promise a secure system you are cheating your customers.

Reactions:

(1)

John Honovich

IPVM

The argument of a VPN connection being to costly only proves that the study of this solution hasn't been done thoroughly.

Ilja, glad to see your first comment!

I am surprised by the support for port forwarding, so far 75% of integrators voting are pro port forwarding.

In terms of cost, I have seen a number of Hikvision dealers recently complain / resist paying for a real DDNS service and that's just $25 - $40 a year. That in itself is disconcerting to me. So if they want free DDNS services, even though the Hik one was shown to be seriously flawed, they are going to be highly resistant for the more costly / complicated VPN approach.

Reactions:

(1)

Jon Dillabaugh

In reply to John Honovich

Pro Focus LLC

I was one of those people who resisted paying for DDNS services, considering I had been using a free DYNDNS or NO-IP account for many years for PC related reasons. Then all of a sudden, they started restricting the free services or eliminated them.

I then tried the free services by the manufacturers (namely Dahua), but found that they took much longer to propagate changes and weren't as reliable. Clients would frequently call asking why their camera systems were "down". It was simply that the DDNS services was down or not up to date.

At that point, I decided to bite the bullet and by a plan through NO-IP. What I found was that having the ability to manage all of the hosts from one easy place was much easier and saved me considerable time.

As a side bonus, their propagation time is much faster (near instant) and I have yet to have a single client call due to an outage of DDNS or slow updates.

Like you have stated, the minimal amount they charge is trivial and any business should easily be able to afford their fees. I know it was just about paying for something that had been free for so long that was painful.

Reactions:

(1)

(2)

Ilja Theuwissen

Just to be clear for everyone. A paying DDNS service does NOT provide any type of security. It's just as insecure as any portforwarding and so are all of the vendor provided dynamic ip services.

If you want to have security you need centralised authentication and encryption of your communication.

Both of which are totally absent with these "DDNS", "P2P" kinds of services.

Reactions:

(2)

Jon Dillabaugh

Pro Focus LLC

I'm not sure that's entirely true. If my DDNS services gets exploited and the hacker points my DDNS to his infected server instead of my intended target, he could infect my client host.

Having a more secure service does help.

Reactions:

(1)

Josh Hendricks

Milestone Systems

This is true, the attacker could point you to their own IP and potentially gather your credentials in a number of ways. This could be mediated by having a trusted certificate in place on the service. You should then get a warning if the certificate doesn't match. But not all applications will warn about cert issues and users are conditioned to ignore cert issues anyway.

WRT the non-standard port discussion, security by obscurity is almost worse than no security at all because it's a false sense of security. But if I HAD to port forward a service on a corporate network I would surely use a non-standard port to reduce the number of attacks I had to protect against. I would also implement some form of intrusion detection/prevention software, and ideally be able to black list IP's after multiple failed connection attempts. There are also gateway devices like Barracuda which cloud source blacklisted IP's rather effectively (I've had to get IPs removed from Barracuda blacklists among other similar services).

There are ways to avoid port forwarding, and the more security conscious companies will avoid it at all costs. But sometimes it is a delicate balance between cost, security, and usability. There are ways to mitigate the risks, but usually only larger IT organisations are willing to implement them.

Reactions:

John Honovich

IPVM

A paying DDNS service does NOT provide any type of security. It's just as insecure as any portforwarding and so are all of the vendor provided dynamic ip services.

Well, Hikvision's does not use HTTPS, so that's even lower. But I do agree with your fundamental point, whether you pay or not for DDNS, the issue is still that the IP/port is open to the public and that is a risk.

Reactions:

Andrew Tierney

Actually, I think dynamic DNS degrades security.

Firstly, it lets me enumerate hosts which are likely vulnerable:

http://cybergibbons.com/security-2/why-dynamic-dns-is-a-bad-idea-for-the-internet-of-things/

Secondly, many of these services are ruined:
http://cybergibbons.com/security-2/mintdns-dynamic-dns-software-multiple-vulnerabilities/

Reactions:

Undisclosed Integrator #6

Question for all the people who say we should NOT port forward.

How else can we get the video out so the client can use remote viewing?

Its either use P2P or forward the ports manually.

Reactions:

John Honovich

IPVM

How else can we get the video out so the client can use remote viewing?

Its either use P2P or forward the ports manually.

VPN.

Reactions:

Undisclosed Integrator #6

In reply to John Honovich

wow! doesn't the expense prohibit that? can you recommend a router for that? thanks.

Reactions:

Michael Miller

Lots of routers options for VPN access including VPN access from your mobile phones.

Reactions:

(1)

Jon Dillabaugh

Pro Focus LLC

There are literally hundreds of inexpensive options here. Any router that can run DD-WRT, Tomato, or PFsense can run OpenVPN.

But that isn't the difficult part. These types of inexpensive (read CPU poor) devices don't scale well when you have multiple simultaneous clients pulling video streams.

Add in the complexity of client configuration and it becomes more than just choosing a router capable of VPN.

One last note, just like any other set of credentials or managed access, VPN creds can also be stolen and used to access your networks.

Bottom line, there is no absolute here. There are layers of risk everywhere. Choosing your best efforts based on potential vs cost will be an individual effort. Layers of security are best. None alone are enough.

Reactions:

Andrew Tierney

What situation are there multiple clients pulling video streams, but not the budget to secure the system?

If there is actually the need to regularly view footage remotely, then secure remote access should be in the budget.

Reactions:

(1)

Carter Maslan

Camio

#6 I'm CEO of Camio, and Camio Box (https://www.camio.com/box/) is a secure alternative:

no port-forwarding, even when connecting to live streams
no account username/password credentials stored on the device or used to access the device
content uploads use 128-bit encryption and perfect forward secrecy
account access protected by 2-factor authentication if using Google/Facebook login

Reactions:

(1)

Jon Dillabaugh

In reply to Carter Maslan

Pro Focus LLC

Carter, that sounds like a great product, but you never mentioned it's affordability. Could you mention rough MSRP ballpark for the device and any subsequent licenses needed, if any.

Reactions:

Carter Maslan

Camio

The Box itself is $129 MSRP (typically sold around $99 - Amazon is $96 right now). You can also run its software free on existing servers as a Virtual Machine (https://www.camio.com/box/vm/).

Only the live streaming is free. The 30-day storage, search & alerts are $9.90/cam/month. But per your feedback on wanting simple callbacks based on important motion events like car/person, we will likely add an even lower cost plan that has no cloud video storage and only serves as secure gateway for alerts, callbacks and secure viewing.

Reactions:

(2)

Jon Dillabaugh

In reply to Carter Maslan

Pro Focus LLC

Outstanding.

Reactions:

Sean Nelson

Nelly's Security

The following is based on my opinion of small business and resi installs (64 cameras or less):

Everyone is pro port-forwarding because that is what everyone has been so used to doing over these past few years. However its time to consider changing the way we think.

I have noticed that port forwarding still provides "faster" performance and relies less on 3rd party server hikcups. But as the P2P servers continue to get better and handle more bandwidth and become more reliable, I think port forwarding will be a thing in the past. We will be saying "remember when we had to do port forwarding"

While there are advantages of doing port forwarding over P2P. I think P2P has greater advantages:

- Its simply easier to do. An end user can do it without any trouble. Therefore Techs can do it just fine as well.
- No need to worry about funky ISP's where port forwarding doesnt work (Satellite)
- Less reliance on router configurations. No more calls such as "We got a new router, now we cant see our cameras" or "we had to reset our router, now our cameras dont work"

Ultimately it comes down to less call backs and less install time. I still think P2P needs some work but I think it will get there. I have instructed my tech staff to switch to doing P2P (instead of port forwarding) with our customers for the next few months to see how many tech issues we get with it compared to our traditional port forwarding (thats what we have been doing up to now). Will their be issues? Im sure their will but I predict alot less than port forwarding.

Reactions:

(1)

Andrew Tierney

In reply to Sean Nelson

That's a massive plus point. It needs no configuration, so the vendor can develop a system that is secure by default.

Reactions:

Undisclosed #4

IPVMU Certified

In reply to Sean Nelson

I have noticed that port forwarding still provides "faster" performance and relies less on 3rd party server hikcups.

What P2P service do you use, the vendors?

Does live video go thru their servers or just addressing information to setup a reverse proxy?

Reactions:

Sean Nelson

Nelly's Security

We carry Hikvision so we use theirs. As far as I know, P2P service cant be used as a 3rd party service like DDNS. All of the devices I have seen from various manufacturers have their own P2P server which you are required to use.

I think its just a proxy but I dont know why its sometimes slower than port forwarding. For example, you can use IVMS4200 with the P2P servers, and response times for pulling up configuration settings are much slower than port forwarding. Also the video seems to freeze up and lag more when using P2P on certain times, on other times its fine though so not sure if it has to do with server loads at certain times. But it appears that reliability has definetely gotten better over time. There was a time in which it was so unreliable that we didnt even consider it. Now we are actually going to implement it in full.

Reactions:

(1)

Brent Cowing

In reply to Sean Nelson

It may be helpful to describe how P2P and proxys work, as this may help to clarify why you experience different performance at different times. This is my understanding of the technology as of a few years ago, when we implemented it at a VMS I used to work for.

P2P, or Peer To Peer, includes a cloud service that maintains a constant connection with a device, like a camera (the device behind the firewall has to initiate the connection), and when a client connects to the cloud service that wants to view a video stream, the cloud service makes the introduction, essentially telling the client to go talk directly the the camera or the NVR (TCP Hole Puchhing is a common technique). If the connection is successful, then this is true P2P. Lots of different things can stop this from working successfully, including extra security on firewalls (depending on the service used, more than the standard 80 and 443 outbound ports are needed) and things like double NAT (think 2 firewalls before the camera or NVR can get out to the internet).

If a true P2P connection can't be established, the cloud service will usually 'fall back' to what amounts to a proxy, whereby video is sent up to the cloud service, which then forwards it on to the client.

Thus, you may experience different quality of P2P connections that are related to how successful each P2P session is. I'll caveat this all by saying i don't know the details of how HIK or others implement their P2P services or even if they are true P2P services, but that's the P2P world as I understand it. Hope that helps.

Reactions:

(1)

(2)

Brent Cowing

Agreed, port forwarding shouldn't be used.

Something else that hasn't been brought up is segmentation. Security works best when implemented in layers. One should avoid setting up a camera network on the same layer 2 network as a workplace data network. Being able to access the camera network from your data network is okay, but the camera network should be blocked from being able to access your data network. Fortunately, doing so is getting easier as more inexpensive network hardware is available with open source firewall software that makes multi-lan and remote access / site to site VPN configurations relatively easy.

A point was made about inexpensive firewall options that are CPU poor, but I've personally used pfSense on relatively 'CPU poor' hardware with no issues and plenty of headroom to spare and the hardware was less than $300 (just search amazon for 'pfsense').

This conversation also lends itself to intrusion detection. IDS packages are available for pfSense (i.e. Snort), although implementation of IDS is fairly complicated to get right. There's a lot of balancing the blocking of potential intrusions with blocking legitimate traffic.

Lastly, for DDNS, I've used DuckDNS without issue for over a year now. Free and very easy to use.

my $.02

Reactions:

(3)

Andrew Tierney

VPNs are rarely CPU bound, even low-end routers can deal with VPNs at line speed.

Reactions:

Undisclosed #4

IPVMU Certified

Andrew, Ilja, I believe you are overestimating the danger to port forwarding done correctly. Instead of argue in the abstract, lets take a concrete example.

This site https://184.179.106.56:31313 uses port forwarding. It costs nothing to set up. This camera is on its own VLAN. Non-standard port. The router is nothing special and the firewall forwards only port 31313 to the camera's https service. The firewall blocks outgoing connection from its internal IP. Router and camera have latest firmware.

From a practical point of view, what is the vulnerability here?

Ilja, you say

Also this advice on using "non standard ports" is invalid. Security by obscurity? Bypassed with one simple automated portscan in about 90 seconds.

Don't do it. Ever. You will be hacked.

How long do you think I will have to wait (on average)?

*I hereby grant any IPVM member the right to probe/attack 184.179.106.56:31313** as a service to me. Please be my pen testers...

**I am using a self-signed certificate, so you will get one of those heinous messages telling you to turn back for your own good, but don't be alarmed. To avoid this you either need a CA cert (which supposedly you can get for free now), or have a copy of the cert on the client, like I recommend.

Reactions:

Brian Rhodes

IPVMU Certified

*I hereby grant any IPVM member the right to probe/attack 184.179.106.56:31313** as a service to me. Please be my pen testers...

Nice try, Mr./Mrs. Electrified Snip Loop

Reactions:

Undisclosed #4

IPVMU Certified

In reply to Brian Rhodes

Good point, I've de-energized it.

Btw, kids stole the gardening shears and refused to even snip, no respect ;)

Reactions:

Jon Dillabaugh

Pro Focus LLC

Reactions:

Andrew Tierney

Firstly, no one who does this professionally will do any testing without a contract and signed authorisation form in place.

Secondly, it misses the point. There have been numerous authentication bypasses, backdoor accounts, and other vulnerabilities found in DVRs and cameras. New ones are found each day.

A DVR with a remote shell:
https://www.pentestpartners.com/blog/pwning-cctv-cameras/

An IP camera which can be rooted via the web interface:
https://www.pentestpartners.com/blog/samsungs-smart-camera-a-tale-of-iot-network-security/

35 cameras with a pre-auth buffer overflow:

https://gist.github.com/Wack0/a3435cafa5eb372b190f971190a506b8

If your camera was rooted, how would you know?

Reactions:

(1)

Undisclosed #4

IPVMU Certified

Secondly, it misses the point. There have been numerous authentication bypasses, backdoor accounts, and other vulnerabilities found in DVRs and cameras. New ones are found each day.

And what point is that? That security device manufacturers are incapable of writing bullet-proof code but VPN software engineers always do?

So lets quantify this, the risk is that a zero-day vulnerability will be discovered in my Hik camera before a patch is released?

Even so how do they know that get my camera is vulnerable since its running on port 31313, which in my routers log has never been SYN in the last 3 years, despite thousands of well-known port probes?

Ok, but let's say anyway they happen to have brute forced portscanned me the week before and now return to plunder.

Then what? They get in to the camera on the isolated VLAN, so they are going to figure out where I live from my IP and the camera views and come rob me by bricking the camera in case I'm watching the live feed?

This is the risk? What else?

If your VPN was rooted how would you know?

Reactions:

Ilja Theuwissen

And what point is that? That security device manufacturers are incapable of writing bullet-proof code but VPN software engineers always do?

I think it's fair to say that VPN software engineers have a better focus on data/network security then most security device manufacturers, which in many (not all, but many) cases are happy if the firmware just enables the primary function of the device.

The fact that many device firmwares are hardly ever updated after release combined with the flagrant security blunders that oftenly are discovered in these firmwares proves this.

Another point is that a centrally managed security-focused application undoubtedly will have a far better chance of preventing, discovering and resolving datasecurity problems then a wide spread network of randomly (= as good as non-) managed devices with bad firmwares.

This approach best practice when it comes to data security in all IT-related fields. It has become best practice because there are millions of examples that prove it's the way to go.

Then what? They get in to the camera on the isolated VLAN, so they are going to figure out where I live from my IP and the camera views and come rob me by bricking the camera in case I'm watching the live feed?

You are absolutely right when you say that the likeliness of getting hacked at this point in time is very low. However, in my previous post I already mentioned that these automated hacking methods are constantly evolving, so every day this likeliness increases. Again, just get some factual information about this and the only services and devices that have been used as DDOS machines in the past, and you'll see that this is a fact.

Apart from that, as your customer i'd be shocked if you told me someone having access to the stream of the camera is "the worst that can happen".To me it seems that you have enough technical knowledge to set up a real secure solution but the attitude that comes with it is totally wrong.

Also i think it's fair to say that the bulk of integrators do not have this network knowledge and that the solution you provide here with managed switches, VLAN's and routers is much more complicated then a straight forward separate network with a firewall and VPN access.

So this solution is much more complicated, often also more expensive (depending on the situation) and not as effective....

Reactions:

(1)

Andrew Tierney

That security device manufacturers are incapable of writing bullet-proof code but VPN software engineers always do?

Historically, yes, it has been the case that it is very rare that a VPN endpoint can be rooted compared to a DVR or camera.

So lets quantify this, the risk is that a zero-day vulnerability will be discovered in my Hik camera before a patch is released?

High. In fact, I can't recall a camera or DVR manufacturer patching a serious vulnerability because of internal testing. Would be happy to be shown an example where they have though.

Even so how do they know that get my camera is vulnerable since its running on port 31313, which in my routers log has never been SYN in the last 3 years, despite thousands of well-known port probes?

Strongly suspect this is a logging issue, as none of the 50+ honeypots I have run have not been fully portscanned in the last 8 months.

Then what? They get in to the camera on the isolated VLAN, so they are going to figure out where I live from my IP and the camera views and come rob me by bricking the camera in case I'm watching the live feed?

1. They brick it because it's fun. A vast proportion of attacks against IoT gear serve no purpose, it's just amusing.

2. They infect it with malware so anything that connects could be compromised

3. They watch the footage

4. The crappy consumer router you have has a vulnerability that means that VLAN is worthless...

5. It hasn't been configured right and you get bitten.

If your VPN was rooted how would you know?

Not one of those is a remotely exploitable vulnerability that results in RCE. The first two have no exploit code (and patches were notified to owners by email) and the last requires someone edits the config file.

And how would I know it isn't rooted? The HIDS would likely alert me immediately, and the NIDS and SIEM I run would tell me fairly quickly as well.

But then the VPN is on an isolated VLAN... so now we are back to your argument.

Reactions:

Undisclosed #4

IPVMU Certified

Not one of those is a remotely exploitable vulnerability that results in RCE.

So what does "allows remote attackers to execute arbitrary code" mean to you?

The first two have no exploit code...

You mean because there is no kiddie-sploit package? You know they always keep the good ones to themselves. Contact ISS, If you are interested.

Reactions:

Andrew Tierney

cvedetails.com often overstates impact and their CVSS scores are significantly higher than most people would place issues.

If you go direct to ISS, you'll see how the wording is different:
http://www.iss.net/security_center/reference/vulntemp/ISAKMP_Certificate_Request_Overflow.htm

Check Point VPN-1 and Check Point VPN clients (SecuRemote/SecureClient) could allow an attacker to gain unauthorized access. An attacker may be able to compromise a VPN-1 server and client system running SecuRemote/SecureClient, and may be able to compromise the Check Point FireWall-1 server.

There are hundreds of vulnerabilities like this. A buffer overflow has been identified, but frequently these are not practically exploitable. Sometimes there is a DoS proof-of-concept.

Earlier you seemed to infer that port-forwarding was secure because your Hikvision camera couldn't be hacked. Put that seriously out-of-date Checkpoint firewall on the Internet with an IPSEC VPN exposed, and it won't be hacked either. Does that mean that it is a good idea to do it? No.

Reactions:

Undisclosed #4

IPVMU Certified

If your camera was rooted, how would you know?

Simple. If I see that Twitter and Netflix are down, I'll know ;)

Reactions:

Ilja Theuwissen

How long do you think I will have to wait (on average)?

What i mean is, when you apply this strategy to bring all your devices online for your customers, you will be hacked for sure.

I presume an integrator rolls out at least 100 devices each year. And he uses various devices, different brands of cameras, NVR's, routers,...

An integrator who says he's truly managing this for all these devices (monitoring firmware releases and upgrading when necessary, adjusting configuration when security breaches have been found,...) has very nice service contracts and a well built tech ops dept or is lying :-)

And yes, getting hacked can take years, even in this situation, but it only has to happen once to be disastrous and the odds are not in your favor with the approach you are taking.

Reactions:

Undisclosed #4

IPVMU Certified

Also i think it's fair to say that the bulk of integrators do not have this network knowledge and that the solution you provide here with managed switches, VLAN's and routers is much more complicated then a straight forward separate network with a firewall and VPN access.

No, I think that it's unfair. The 'bulk' of integrators, at least the ones on this site, certainly know about VLANs and managed switches. And this is as about as simple as it gets in VLANing. Also, regardless of VPN or not the cameras should be seperated from the rest of the network. IMHO, there would be more learning curve with VPNs as there are multiple protocols and software elements involved.

So this solution is much more complicated, often also more expensive (depending on the situation) and not as effective....

Not to be insulting, but it's not more complicated. Its less equipment, less software, less recurring fees, less dependencies.

Now, P2P is a different story altogether, that is easy, though it has its own concerns.

I presume an integrator rolls out at least 100 devices each year. And he uses various devices, different brands of cameras, NVR's, routers,...

You are presuming I'm an integrator? I am not.

An integrator who says he's truly managing this for all these devices (monitoring firmware releases and upgrading when necessary, adjusting configuration when security breaches have been found,...) has very nice service contracts and a well built tech ops dept or is lying :-)

Yes, good integrators do these things. Whether there is a VPN or not.

And yes, getting hacked can take years...even in this situation...

Thanks for clarifying. When you originally said "You will be hacked", I didn't realize you meant "After several years at 100 devices per year"

but it only has to happen once to be disastrous and the odds are not in your favor with the approach you are taking.

What do mean the odds are not in my favor? Even if I get hacked, the odds of it being 'disastrous', (whatever the hell that means), are pretty low. Perhaps you can point to some disastrous real-world examples of zero-day exploits via port-forwarding of cameras. No hypotheticals please.

Reactions:

Ilja Theuwissen

Hey,

Thanks for the reply.

I'm speaking from the experience with integrators and advising towards integrators. You don't seem to be one so that explains the different point of view.

I do remain convinced of my statements about complexity and the fact that the setup you proposed is more complicated whilst being less safe, and I do have experience to do so, but let's agree to disagree on that matter.

Yes, good integrators do these things. Whether there is a VPN or not.

Then i'm afraid the vast majority of integrators (and I'm not only talking about the ones on this website) are bad integrators from your perspective.

What do mean the odds are not in my favor? Even if I get hacked, the odds of it being 'disastrous', (whatever the hell that means), are pretty low. Perhaps you can point to some disastrous real-world examples of zero-day exploits via port-forwarding of cameras. No hypotheticals please.

Reactions:

Undisclosed #4

IPVMU Certified

I'm speaking from the experience with integrators and advising towards integrators.

Maybe you should stop advising integrators, since your advice is bad. For instance:

Also this advice on using "non standard ports" is invalid. Security by obscurity? Bypassed with one simple automated portscan in about 90 seconds.
Don't do it. Ever...

Invalid? Don't ever do it. Ever?

Considering the fact that some integrators will continue to use port forwarding (which you know from your experience), why would advise them to not use obscure port#s, ever?

Even if they plan to migrate every one of them to VPN's, this is a step they should do TODAY! It absolutely will reduce by 99.99% the number of attempts to their system.

Reactions:

(1)

Undisclosed #4

IPVMU Certified

please whoever disagreed: make an argument for why someone using port forwarding should NOT use obscure ports#s.

Reactions:

Brent Cowing

Hi #4, I disagreed with your previous statement on the point that simply changing port forwarding to non-standard ports will reduce the number of attempts on their system by 99.99%. I think that's an exaggeration (but i'm certainly open to you proving me wrong).

However, I AGREE with you that if integrators do continue to simply use port forwarding (lets face it - many many will), then at the VERY LEAST, they should use non-standard ports.

Security by obscurity is, in my opinion, no longer a viable option. Getting your network 'pwned' isn't the only concern. Many of the ne'er do wells on the internet aren't interested in viewing your video or even roaming around your network, they're interested in having control of whatever your device is for the purpose of far more scary things, like launching internet crippling DDOS attacks, or adding your compute and bandwidth resources to their armies of botnets that go out and scan for more devices to take over. DDOS attacks cost legitimate businesses millions if not billions to defend against and botnets are becoming so easy to assemble that relatively incompetent teens are DDOSing the game servers of their enemies without a consideration for the collateral damage. Other botnet operators are making hundreds of thousands, if not millions of dollars off of their DDOS for hire services or by selling the use of their botnets to others who gain illegitimate access to networks so they can deploy crypto ransomware and hold hospitals (for example) and others' data hostage until they pay up.

So, in my opinion, the best way to address this situation is to implement the most secure network practices that you know how. We know that NVRs and cameras are now notorious for how poorly they've been secured and how infrequently they are updated to address security vulnerabilities. So given this, I think security by obscurity is not the best way for integrators to implement security systems for their customers.

Reactions:

(1)

Jon Dillabaugh

Pro Focus LLC

You are talking out of both sides of your mouth now. You claim that these l33t h4x0rs are coming to drop Mirai on my device, but they will do a full port scan on every 3.5 BILLION public IPs to find vulnerable devices...?

I highly, HIGHLY doubt it. The will scan 37777 or 8000 or any other number of well known ports with well known creds.

The targeted attacks that have been mentioned above are a viable threat for a full port scan. I will grant that. But you, as a hacker, first have to find out the public IP of the target in mind. That isn't a simple task, unless you are already on that given network.

And none of this takes into account the many, MANY various attack vectors that are far easier and successful. A tainted email is far easier and much more effective way in.

Reactions:

Brent Cowing

Hi Jon,

Why do you doubt that a botnet would scan every port of every available public IP? Botnets now have millions of devices at their disposal (and they are gaining more every day). Each of them is set up to portscan other devices for open ports and vulnerabilities so they can bring more devices into the botnet. I agree, if you use non-standard ports, your chances are low, but why take the risk when you can relatively easily and cheaply set up VPN hardware that is regularly updated to specifically address new vulnerabilities?

Reactions:

Jon Dillabaugh

Pro Focus LLC

Because I don't always have control of the networks where these systems are being installed. I can't always require that the client replace their existing router and firewall.

In general, we try to get a connection in front of any existing network or router. We prefer to install our own router/firewall in parallel with the existing router, if the ISP allows this.

But, sometimes this isn't possible. Some clients don't have the budget to allow this. Some clients don't have anything other than a few WiFi devices other than the camera system and adding this level of security is somewhat pointless.

All of that said, I do learn and evolve my position as time goes along. I haven't always feared standard ports. I haven't always shifted to non-standard ports. That evolution very well may lead me to VPNs or P2P down the road. But today, I am OK with non-standard ports on isolated/segmented security networks. All of the devices we install have auto lockout in the case of failed attempts. This setup will likely stop 99.9% of attacks. That's a great mitigation of risk in my opinion.

Reactions:

Brent Cowing

Fair enough!

Reactions:

Andrew Tierney

This really disturbs me. You don't have control of their network BUT YOU ARE WILLLING TO PUT THEIR ENTIRE NETWORK AT RISK FOR REMOTE CCTV ACCESS.

Reactions:

Jon Dillabaugh

Pro Focus LLC

The "entire network" consists of a NVR and a router.

Reactions:

Andrew Tierney

So if it's not connected to a client or the Internet, why bother with a router?

Reactions:

Andrew Tierney

I don't understand why Mirai is the only threat you are accounting for. I also don't get why you are ignoring targeted attacks. You can become a target by running insecure services. A full port-scan of your IP, a vulnerable camera, and now you are the person that is being attacked. It's a fool's game saying there are easier vectors, therefore this one isn't important.

Reactions:

(1)

Undisclosed #4

IPVMU Certified

I disagreed with your previous statement on the point that simply changing port forwarding to non-standard ports will reduce the number of attempts on their system by 99.99%. I think that's an exaggeration (but i'm certainly open to you proving me wrong).

Its admittedly a guess, but it's based on two things:

Shodan and Censys et al , which many rely on to drive their campaign do not (at this time) gather info on random ports.
My own logs, which until yesterday at least, contained over 3,000 DOS/SYN/RST probes over about 100 different ports, the vast majority being 80, 443, 21, 22, 23, 31777 etc. Less than 20 being unknown numbers.

Also, regardless of how quick it is to scan 65,000 ports, it will still be 65,000 times quicker (or require 65,000 less resources) to scan for one. So if your a hacker who wants the most hits, the odds are way better to move on to a different IP and port.

Of course, someone could scan all your ports, but then there must still be a way in. And they have to recognize the host and have the correct exploit ready to gain entry, which despite all the recent cve's, is certainly not a given.

As opposed to when they're looking for 31777; they know what to do if its open and have tailored an attack towards a Dahua device. When its 31313 though, it could be a printer or a toaster or washing machine.

But just a guess for sure. Would be interested in other people's logs, after taking into account any portscanning one might have done on their own system.

Reactions:

Andrew Tierney

> It absolutely will reduce by 99.99% the number of attempts to their system. But you don't have any empirical evidence to back this up.

Reactions:

Undisclosed #4

IPVMU Certified

Well, lets be fair, I cited my own log.

What you say we put up a honeypot to accumulate attempts?

Before I do though, do you agree that would be a good measure of how effective obscure ports are?

Reactions:

Andrew Tierney

I have over 50 honeypots, so have a fair amount of data.

If you only see scans over 120 ports, either your logging isn't working or there is something blocking ports before your router.

Reactions:

Undisclosed #4

IPVMU Certified

Question, what ports are open on these pots of yours?

Reactions:

Andrew Tierney

It's variable. A few have every single port open listening for HTTP and HTTPS.

Reactions:

Undisclosed #4

IPVMU Certified

If the pots have any well-known ports open, Andrew, then you are much more likely to get scanned on all the unassigned ones. Don't you agree?

Once your in shodan or Censys you are going to get hit.

But what I'm talking about is only having the one obscure port open, ever.

Do you have any unsweetened honeypots like that?

Reactions:

Ethan Ace

For those who have said VPN hardware can be "cheaply" set up, I'm curious what "cheap" means in this case. $50? $100? $400?

Keep in mind a lot of the devices which are used by botnets are self installed and sub-$500. A $100 firewall can easily be 20-30% of the cost of camera equipment on small systems which are most often the target here, and it requires expertise to install.

Reactions:

Michael Miller

Routerboard pricing starts at $39.95

UBNT routers start around $90

Both can do VPN access.

Reactions:

(2)

(1)

Brent Cowing

In reply to Michael Miller

pfSense is free, and can be installed on many different types of old hardware you may have lying around. And it includes capabilities typically only found in enterprise class stuff like country block lists and free Intrusion Detection Systems.

Reactions:

(1)

Ethan Ace

I'm not a Routerboard or Ubiquiti expert, but I've looked at UBNT's routers enough to know that setting up a VPN is a command line affair if you want to do it without a RADIUS server. Even if you know how to do it (most don't), it's still a non-trivial amount of work in addition to the cost.

pfSense is interesting, also, but again, the installers and target market for these systems have no clue how to operate it.

I'm not saying that the industry shouldn't evolve and that these things are a bad idea. I just don't think it's realistic to expect that every install is going to get them.

I don't know for sure what the solution is, but clearly there are things short of expecting every install to get a VPN that can be done right now, and I'd rather see something instead of nothing.

Reactions:

Andrew Tierney

Why should it requiring command line prevent it from being done?

If your job is to install IP video systems, you need to do it safely. You wouldn't run mains cable runs with figure-8 speaker cable, why shortcut infosec?

Reactions:

(1)

Undisclosed #4

IPVMU Certified

Why should it requiring command line prevent it from being done?

Andrew, read Ethan's post again; he is not objecting to doing it right, (c'mon Ethan could run figure-8's around your typical installer), just that it can be done cheaply.

Reactions:

Andrew Tierney

It's being suggested it's too hard for installers to do now and that they need to evolve.

This has been a known risk for at least 10 years. How long does it take to evolve?

Reactions:

Ethan Ace

I'm not saying it should, I'm saying it does.

Any time we get down the rabbit hole in these cybersecurity discussions, we get into the weeds on how things should done and ignore who is purchasing, installing, and using many, probably most, of these most vulnerable systems.

There's little IT experience in that list. There's a vast skills/knowledge gap between "change to port 10101" and "just use the CLI to do all your VPN setup."

Reactions:

Kyle Folger

IPVMU Certified

I had to setup a site to site VPN on the Ubiquiti ERL recently. Since I hadn't done it on that equipment before, I used this guide. I may have used another site for reference as well. It would be slightly different for client/server. With that being said, it would be much easier as a GUI option and isn't as easy as setting up SSL VPN on a Sonicwall. The nice thing is that once it's setup from CLI, it can be monitored via the GUI and firewall rules can be written from the GUI so all is not lost.

Reactions:

Ilja Theuwissen

Very good point Ethan, and that's exactly what i meant when i mentioned this is too complex for the "average" security integrator.

There are companies that offer these solutions as a plug and play device + service. It adds security, easy management and monitoring and even gives you a possibility for extra revenue.

Reactions:

Undisclosed #4

IPVMU Certified

...that's exactly what I meant when I mentioned this is too complex for the "average" security integrator.

When did you say that about VPNs? You said it about my setup, but the VPN setup you characterize as "straight forward"

...the solution you provide here with managed switches, VLAN's and routers is much more complicated then a straight forward separate network with a firewall and VPN access.

Reactions:

Ilja Theuwissen

Hey #4

From a logical view you can't possibly argue that a VLAN setup is easier then a VPN setup.

From a config standpoint it all stands or falls depending on your level of experience and the chosen hardware. Both can be easy, both can be the most gigantic pain in the *** :)

The fact is a VPN setup CAN be plug and play. I've yet to see the first plug and play VLAN setup.

Reactions:

Undisclosed #7

•Jan 10, 2017

Complex?? I have a complex. I'm late for dinner. Tacos anyone?

Reactions:

Kyle Folger

IPVMU Certified

I have pfSense running at a restaurant where the owner didn't want to spend a lot and he had been fine running on a cheap Linksys router, but I was tired of supporting it so I used an old Dell Dimension he had and put an extra Intel NIC card in and aside from replacing a hard drive, it has been flawless. It's running the latest version without issue. I understand and he fully understand what we did and understood the risk of used hardware. However, I believe it's been up and running for at least three years. I've also used the latest pfSense hardware that is sold by them and it's worked well.

It's worth noting that pfSense offers commercial support now and they assisted in hardware selection to make sure I had the right unit for the amount of network clients.

Reactions:

Jon Dillabaugh

In reply to Michael Miller

Pro Focus LLC

You are still dealing with a device with possible vulnerabilities.

https://www.symantec.com/connect/blogs/thousands-ubiquiti-airos-routers-hit-worm-attacks

http://www.cvedetails.com/product/23641/Mikrotik-Routeros.html?vendor_id=12508

Reactions:

(1)

Brent Cowing

True, but at least firewall device manufacturers are constantly working to keep their devices as safe as possible with new firmware releases (as opposed to NVR / camera manufacturers which don't have a strong pedigree in network security). The Ubiquiti vulnerability you referenced was targeted at outdated firmware.

Reactions:

Jon Dillabaugh

Pro Focus LLC

And the Dahua / Mirai firmware vulnerability is old code as well. Anything after 2015 is patched. So you are still relying on end users or integrators to go back and patch some device on a regular basis, be it a router or DVR/NVR.

You are making the assumption that all router mfgs outpace security mfgs in updates. While on a case by case basis that may be true, but as a blanket statement, I'm sure I could prove it wrong.

Reactions:

Brent Cowing

Regular patches are a given. Yes, i'm saying that router manufacturers outpace security manufacturers in updates. I'm also saying they're way more competent when it comes to network exploits, both from the perspective of keeping pace with patching vulnerabilities , as well as from the perspective of software implementation and design that is built to prevent vulnerability to exploits in the first place.

I'm sure that I also can find some cases of router manufacturers that are much more terrible than security manufacturers when it comes to updates, but I also wouldn't use their devices.

This has been an awesome conversation Jon, thanks for your thoughts and insights!

Reactions:

(2)

Andrew Tierney

Consumer and SOHO routers are, on the whole, awful. But they tend to have limited CPU power, limited RAM and limited persistent storage. The same cannot be said of a DVR.

Reactions:

Andrew Tierney

This is totally false. We've bought three entirely new DVRs with entirely up-to-date firmwares and they have all been vulnerable.

Reactions:

Undisclosed #4

IPVMU Certified

This is totally false. We've bought three entirely new DVRs with entirely up-to-date firmwares and they have all been vulnerable.

Now there's some info that could really help a fellow integrator before they do likewise.

Care to share the mfr. and firmware revision?

Reactions:

Andrew Tierney

They'll be publically disclosed 90 days after first contact with the vendor, in accordance with our disclosure policy.

It's trivial to check though, and all installers should have checked their existing devices and ones they plan to install.

Reactions:

Kyle Folger

IPVMU Certified

Plus, you had to also have the HTTP/HTTPS interface open to the Internet. I got bit by the work which knocked internet out. I had forgotten to deactivate remote management which at that time the firmware was set to enable management on the WAN side by default. Ubiquiti, to my knowledge, was quick to release a fix but it is unfortunate as it caused a lot of service calls for some.

Reactions:

Andrew Tierney

No device is entirely secure though. Again, I don't understand this viewpoint at all.

Reactions:

(1)

Ilja Theuwissen

true, but in a setup with a VPN concentrator you only have the risk in one place, which is very easy and cost-effective to maintain and takes away the risk from your customer.

Reactions:

Carter Maslan

http://www.bitag.org/report-internet-of-things-security-privacy-recommendations.php

Camio

This is a nice overview report on some of the best practices discussed in this thread too:

Reactions:

(1)

Jon Dillabaugh

Pro Focus LLC

Doesn't a VPN router require an open port in the firewall? Wouldn't a port forward from a non-standard port to a secure (encrypted) device port be equally as secure? Why not?

Reactions:

Undisclosed #4

IPVMU Certified

Sure it would be.

But I believe that Andrew et al would argue that the device (dvr etc) is less likely to be secure than the VPN.

And I agree they have a point, I'm just not sure how big a point it is.

Reactions:

(1)

Ilja Theuwissen

Sure it would be.

yes, but you don't need any portforwarding on the client's network, which is the one and only way of offering them zero-risk security.

Reactions:

Ilja Theuwissen

Doesn't a VPN router require an open port in the firewall?

No it does not. When using a setup with a VPN "concentrator" this is not necessary, you won't even have to do any changes on the network of your customer to have a perfectly secure setup. Your customer can even change providers without a problem.

Glad to help anyone interested in this.

Reactions:

Undisclosed #4

IPVMU Certified

No it does not [require an open port in the firewall]

Doesn't your concentrator use ports, like 1723, 500 etc?

Even if the router automatically adds the rule to allow the port in the firewall, its still an open port, no?

Reactions:

Andrew Tierney

Port-forwarding isn't inherently a problem if the service behind it is adequately secure and monitored.

IP video equipment isn't either of these things, so your question sits in a purely fictional world.

Reactions:

Ilja Theuwissen

it's not necessarily a problem indeed, but it is always an extra risk.

You take away this risk when you don't do portforwarding.

Reactions:

Don Kennedy

While Port Forwarding has risks, using a VPN to solve those risks which intern, allows access to every device on your local network, is even more risky. Because of this I would use Port Forwarding over a VPN with total access to all devices in your local network, hands down.

Don

Reactions:

(1)

Jon Dillabaugh

Pro Focus LLC

In reply to Don Kennedy

Don, I've said the same thing! I agree that a NVR/DVR/IP camera would be a much more limited host than a powerful PC intruding on the VPN. However, that said, the VPN is generally going to be much harder to hack, assuming that the attacker doesn't already have complete access.

Reactions:

Undisclosed #4

IPVMU Certified

In reply to Don Kennedy

Using a VPN to solve those risks which intern, allows access to every device on your local network, is even more risky.

Don, VPN's have firewalls as well. Host and port access can be similarly managed.

Reactions:

(1)

Josh Hendricks

Milestone Systems

Correct, and VPN's are designed to be secure while IoT devices are largely not designed with security as the primary focus. An IP-enabled camera, access control, intrusion detection, etc device is more likely to be compromised than a respectable VPN application/appliance.

Also, either way you go, if the device or VPN is compromised, you should assume the attacker has equivalent access to the network. I don't think you're much safer if it's "just" a compromised camera. If someone wanted in through such a decice, they could easily install/establish an OpenSSL VPN connection to said network through the device.

Reactions:

Josh Hendricks

In reply to Josh Hendricks

Milestone Systems

To be fair, I don't mean to call out just hardware here either. VMS, PSIM, analytics, and other software are in the same boat. Compared to a VPN application/appliance, any other software/appliance is less secure.

If "cloud" is not an option and you have the option to use VPN, that will always be the most secure choice.

As U4 mentioned, you can put access control in place on the VPN network to limit access to specific addresses and/or ports, so if it's compromised, it's not an all or nothing thing.

Reactions:

(1)

Jon Dillabaugh

In reply to Josh Hendricks

Pro Focus LLC

As U4 mentioned, you can put access control in place on the VPN network to limit access to specific addresses and/or ports, so if it's compromised, it's not an all or nothing thing.

Again, those same restrictions on the VPN VLAN can be placed on any NAT'd/port forwarded VLAN. That level of security is the same reguardless.

Reactions:

Undisclosed #4

IPVMU Certified

That level of security is the same reguardless.

So that (Access Control/Firewall) level is the same, and the VPN is harder to hack as you say, therefore the VPN is more secure overall, right?

Reactions:

(1)

Jon Dillabaugh

Pro Focus LLC

Yes, that is exactly what I said above.

Reactions:

Ilja Theuwissen

In reply to Don Kennedy

That's not right at all Don. Portforwarding exposes your device to the entire internet, whilst a VPN exposes it to a controlled environment. Firewalling can be added to secure it even more and all communications are encrypted, which is also a great plus.

Reactions:

Jon Dillabaugh

Pro Focus LLC

Ilja, that is not entirely correct. When using a VPN, you also have ports open for the VPN services, assuming your VPN server is behind the firewall. If the VPN server is in front of the firewall, worse yet, it is exposed entirely.

On the other hand, when port forwarding to a single host, let's assume a DVR, you can restrict access to that device from the public side. That device could use encryption as well. Also, your firewall could greatly restrict access from the DVR to the rest of your physical network. It should be on an isolated VLAN or separate physical LAN.

You do this by dropping any unneeded traffic from the security VLAN. You could even allow only established traffic from leaving the security VLAN, with the exception of NTP alone. That way, the only traffic outbound of the security VLAN is NTP. All other packets will be dropped at the firewall. This isolates that single host. And since you have restricted its ability to send outbound traffic via firewall rules, it can't be used as a bot, phone home to China, or any other scary scenario that anyone can think up.

On the inbound traffic side, you can greatly restrict that as well. You can whitelist IPs, use strong passwords, forward only essential ports using non standard ports, etc.

This way, the attack surface is a highly restrictive, single host that has been neutered, vs a VPN server that has access to possibly your entire network.

The decision also should factor how easy each surface is to hack. If a VPN was bullet proof, I would just call that good enough. But, it's not. They have flaws too. Not as many or nearly as often, but one exposure to your entire network is scary as hell.

Reactions:

Ilja Theuwissen

•Mar 14, 2017