Possible bug?

[xfgavin]

My admin web service is running on port 80, I disallowed accessing it via the internet.
I also put one openvpn instance running on port 80, hoping that I can connect the openvpn service in the environment that only several http/https ports access allowed and have full internet access.
However, I got the admin web service when I accessed port 80 outside of my home network.

 

[RMerlin]

OpenVPN will open port 8o on the firewall, which has the side-effect of allowing WAN access to your webui that listens to that port.

You cannot have both at the same time on the same port. Move OpenVPN to a different port, ideally 443 if you need to use a commonly open port.

 

[xfgavin]

Thanks.

Thought the webui is listening on intranet ip only.

 

[sfx2000]

You cannot have both at the same time on the same port. Move OpenVPN to a different port, ideally 443 if you need to use a commonly open port.

Actually - one might consider moving OVPN outside of 1024 - any processes below this are executed as root, with full privs...

just saying... trust your daemons?

 

[RMerlin]

Actually - one might consider moving OVPN outside of 1024 - any processes below this are executed as root, with full privs...

just saying... trust your daemons?

For people who run clients in networks that limit outbound connections to the usual 53/80/443, using port 443 is their only way in.

 

[sfx2000]

For people who run clients in networks that limit outbound connections to the usual 53/80/443, using port 443 is their only way in.

And not a very good idea...

But again, running a VPN server on one's firewall isn't a good idea either when everything runs as root, eh?

 

[RMerlin]

Thanks.

Thought the webui is listening on intranet ip only.

Before 380.59, httpd was binding to all available interfaces, so opening port 80 would expose it to the WAN.

Starting with 380.59, this includes a recent change from Asus that will specifically bind httpd to the br0 interface, which is a bridge.

 

[sfx2000]

Before 380.59, httpd was binding to all available interfaces, so opening port 80 would expose it to the WAN.

Starting with 380.59, this includes a recent change from Asus that will specifically bind httpd to the br0 interface, which is a bridge.

Which is always a bit scary when exposing intefaces to the outside world - esp. interfaces that control security for the LAN side.

The WRT's all have a problem with this - do a metasploit or nmap slow burn against an exposed HTTP/HTTPS port, you'll be amazed...

And the embedded webserver - it's going to answer, if exposed, so putting ovpn on the port, again, is a very bad idea indeed...

 

[sfx2000]

the subtle hint - if folks don't get this yet - run a VPN behind the firewall, not on it, and expose only needed ports...

The onboard VPN server is a huge security risk for everything on the trusted/LAN side..

 

[xfgavin]

the subtle hint - if folks don't get this yet - run a VPN behind the firewall, not on it, and expose only needed ports...

The onboard VPN server is a huge security risk for everything on the trusted/LAN side..

Theoretically, it can be a big security issue to run VPN service(and other services). But the reasons that I don't care that much are:
1. I believe the firmware is robust enough, at least I keep it up to date.
2. No one cares about infamous IP. It is also easy to recover when it gets hacked.
3. adding an extra server is cool. I used to do this before when I was using a dumb Motorola SBG6580. I had my openvpn server forwarded. But I changed mind when I got my asus. It also simplified my home network.

I also hate to run service on ports below 1024, but have to since the library I used to go to has only limited port range access.

 

[RMerlin]

The vast majority of VPN servers run on firewalls. There's nothing wrong security-wise with that, the firewall environment is typically better hardened than any random server you might be using to host the VPN server.

 

[sfx2000]

The vast majority of VPN servers run on firewalls. There's nothing wrong security-wise with that, the firewall environment is typically better hardened than any random server you might be using to host the VPN server.

That's how things get hacked...

Perhaps many Consumer Grade AP's offer VPN services - just also consider that the Firewall, Kernel, Shell, sshd, VPN Daemon, WebServer - they all run as admin - and there's no separation of privilege here... find an edge and peel it up and own the box - and then it, and the entire network behind it - it's pwned...

Limit the number of services running on the Router/AP itself.

NAT/SPI and Port Forwards are relatively safe...

 

[RMerlin]

That's how things get hacked...

Perhaps many Consumer Grade AP's offer VPN services - just also consider that the Firewall, Kernel, Shell, sshd, VPN Daemon, WebServer - they all run as admin - and there's no separation of privilege here... find an edge and peel it up and own the box - and then it, and the entire network behind it - it's pwned...

Limit the number of services running on the Router/AP itself.

NAT/SPI and Port Forwards are relatively safe...

We've had firewall + VPN appliances from business-minded providers forever. Cisco, Juniper, Sonicwall... Nothing unusual in having the VPN server running on the firewall appliance, and the vast majority of SMBs do so. It's probably in fact a pretty good location, as it allows you to control what LAN resources your VPN clients will gain access to, as you are sitting on the firewall.

There's a limit to how much isolation one can realistically get. Otherwise, we'd have separate servers/appliances for firewall, SPAM filtering, antivirus, VPN, PDC, Mail, file servers, backup services, and who knows what else. This is simply not realist. Nobody but a Fortune-500 could afford to have 8+ separate boxes to address their LAN services, and a dedicated team of ITs to keep all of these up and running.

There's a point after which the cost versus security curve stop making any sense. Security is something that has to stop at a certain level. You don't need retinal scanning to enter your bathroom.