Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serveo: Expose Local Servers to the Internet

serveo.net

Post reply on HN
Print view View original

111–120 of 122 posts

Re: Serveo: Expose Local Servers to the Internet

#111

Post by toast0 »

smittywerben wrote: post #31
jarcane wrote: post #22

Earlier quoted context omitted.

I honestly think the fault here is not technical, it's ISPs. Between the RIAA/MPAA breathing down their necks about piracy, and the realization they could make a mint charging inflated "business rates" than letting you do what you wanted with your own damn internet connection, shit got locked up tight so fast no one even noticed. It's not NAT that's why my ISP is blocking half the protocols on the Internet. Why every…

> Why I'd need to us a fucking VPN tunnel just to get SSH to my home computer. My most recent disappointment was trying to mount an Azure SMB 3.0 network drive over port 445. It would function just like a network drive at work or school right? No more poorly made userland daemons i.e. Dropbox. Or any additional software, VPN, proxy, or admin rights for that matter. Just click “add network drive” button in explorer an…

SMB ports being blocked is unfortunate, but it was probably the only reasonable response to all the worms and stuff that were going around on those ports.

Re: Serveo: Expose Local Servers to the Internet

#112

Post by zAy0LfpBZLC8mAC »

hunter2_ wrote: post #88
zAy0LfpBZLC8mAC wrote: post #79

Earlier quoted context omitted.

That just isn't the case, though. A router without NAT and without a firewall (or a combined NAT/firewall thingy with default allow and no further rules) will route packets addressed to "private addresses" just fine. An IP router does not distinguish between "private addresses" and "non-private addresses": As long as there is a route for a prefix in the routing table, the router will route packets addressed to that p…

So your example depends on the incoming packet already being addressed to a device behind the home router, which in a home network is in a private range. Thus, your example depends on the ISP's network delivering a packet to the customer despite that packet having an IP address that doesn't match the IP address the customer leased. Do you agree, and if so, do you know that this has ever happened in a residential sett…

> Do you agree, and if so, do you know that this has ever happened in a residential setting?

I agree, apart from the claim that the home network is necessarily in a private range. For one, it's not technically necessary, you can use NAT with globally unique and globally routable addresses on the "internal" side. Obviously, people rarely do that with IPv4, but those people who promote the idea that NAT is somehow a security mechanism also use that claim to promote the idea that either IPv6 is bad because it doesn't use NAT, or that you possibly should use NAT with IPv6 ... which is where these misconceptions lead to some pretty crazy results.

> Or do you mean an adversary who is or who compromises the ISP, possibly by tapping into the coax/fiber/etc in the last mile or by pwning the related nodes?

Well, those are obviously attack vectors, and certainly not ones you should ignore, given how often there are all kinds of vulnerabilities being found in network equipment, including but not limited to the regular hard-coded passwords in Cisco equipment.

But, yes, there absolutely have even been publicly known cases of where this kind of access would have been possible, from ISPs that forgot to disable RIP on the customer-facing side of their routers, thus propagating some customer's RFC1918 routes into their access network (obviously kindof a configuration fuckup on that customer's side as well) to other ISPs that put multiple customers into a common ethernet segment/VLAN, so you could talk to your neighbour's router's WAN interface if you were a customer of the same ISP.

In any case, if you are responsible for the security of your network, your security boundary most definitely should be in your router, not somewhere in the ISP's network, where nothing of that sort is even legally guaranteed.

Re: Serveo: Expose Local Servers to the Internet

#113

Post by zAy0LfpBZLC8mAC »

shock wrote: post #99
hunter2_ wrote: post #94

Earlier quoted context omitted.

Why would the ISP's network deliver a packet to the customer despite that packet having an IP address that doesn't match the IP address the customer leased? Does this require an adversary who is or who compromises the ISP, possibly by tapping into the coax/fiber/etc in the last mile or by pwning the related nodes?

> Why would the ISP's network deliver a packet to the customer despite that packet having an IP address that doesn't match the IP address the customer leased? It wouldn't under normal circumstances, but could in the case of a misconfiguration or a malicious actor. > Does this require an adversary who is or who compromises the ISP, possibly by tapping into the coax/fiber/etc in the last mile or by pwning the related n…

Well, it is unlikely in practice because home access routers usually come with a stateful firewall. The important point is that that doesn't change when you remove the NAT. And that is important because people come to all kinds of nonsensical ideas about how IPv6 is dangerous or what you should do to make it less dangerous because you typically don't have NAT with IPv6.

Like, that you should use ULA and NAT with IPv6 so you don't lose the great security benefits of NAT. That is a completely logical conclusion if you believe that NAT provides security benefits. But it's just wrong.

And, yes, TR-069 is also a potential attack vector that you probably also should prevent in any halfway serious business context. Giving your ISP('s infrastructure) access to your internal network probably is not a good idea, no matter what the mechanism is.

Re: Serveo: Expose Local Servers to the Internet

#114

Post by zAy0LfpBZLC8mAC »

tjoff wrote: post #83
zAy0LfpBZLC8mAC wrote: post #80

Earlier quoted context omitted.

> There is no need nor benefit to have a per-device unique address advertised to the world. Yes, there is! But possibly more importantly: There is no benefit to assigning devices ambiguous addresses. It's as sensible as having all rooms in your business have "1" as their room number because you somehow have convinced yourself that that prevents people from entering your building.

What need or benefit? I have no idea what you are trying to convey, I do not think you understood the concept. I'm not talking about security.

The benefit of not having addresses collide. I mean, that's the whole point of assigning globally unique addresses?

When you connect some previously unconnected networks (a merger, or simply access for some sort of cooperation, or for maintenance access, or whatever), it's a nightmare with RFC1918 when address ranges overlap, which they invariably do. If you use globally unique addresses, you can be sure that there will be no problem.

When you debug something, you don't have to figure out what maps to what where in the network. When two machines talk to each other, the packets are labeled with the IP addresses of those two machines and the ports they are using, no matter where in the network you investigate. No matter who writes a log file about some operation happening in the network, all of those log entries are labeled with the same, uniquely identifying addresses.

And on the other side, there is still exactly zero benefit to using ambiguous adresses.

Re: Serveo: Expose Local Servers to the Internet

#115

Post by tjoff »

notwedtm wrote: post #102
tjoff wrote: post #83

Earlier quoted context omitted.

What need or benefit? I have no idea what you are trying to convey, I do not think you understood the concept. I'm not talking about security.

There are plenty of benefits and/or use-cases for having each internet connected device have it's own unique address. If not just for nonrepudiation, the elimination of NAT hardware and complexities is a plus as well. If you're not talking about security, maybe you should be?

How big of an security issue is the NAT hardware and complexity? And is it not absolutely dwarfed by ipv6 hardware+configure complexity? (not to mention maturity).

Re: Serveo: Expose Local Servers to the Internet

#116

Post by dmix »

TrueDuality wrote: post #25
dmix wrote: post #18

Earlier quoted context omitted.

Germany (44%) and Belgium (53%) are killing it! The biggest surprise is India matching the US, must be that Indian mobile company that people mentioned here the other day? I'd love to see similar graphs for TLS. Edit: Google shows it only for Chromium sampling but it's nearly 90% in most countries which is almost double what it was before the Snowden leaks: https://transparencyreport.google.com/https/overview

Honestly I think the adoption of TLS has more to do with free certificates from LetsEncrypt and CloudFlare than the Snowden leaks. As much as I'd like to think people were concerned about the privacy of their communications... I don't think most of the masses actually care about security or avoid conveniences based on threats to their privacy...

Regardless of why that’s still 40-50% less of the raw internet traffic intel agencies can get warrantlessly from ISP network tapping rooms and undersea cables splices.

Not to mention their lost access to private Google (and probably Yahoo, Microsoft, etc) networks and a myriad of other security improvements across countless software platforms.

Still a long way to go.

Re: Serveo: Expose Local Servers to the Internet

#117

Post by zAy0LfpBZLC8mAC »

guilhas wrote: post #93
rohan1024 wrote: post #8

NAT has crippled the Internet. We are permanently dependent on public facing servers to route packets from one device to the other. This service is absolutely not needed in a non-NAT world. And I strongly believe we have lost a lot by being completely dependent on client-server model of Internet. I've written more about it here https://www.ankshilp.in/post/the_broken_promise_of_internet/

Besides the number of ips what are the advantages? ipv6 vs ipv4 Which one is better for privacy? Which one is better for security? Which one is better for speed? Which is easier to configure? Which is better for end user? Which is better for advanced user / net admin? Which is better for companies?

> Besides the number of ips what are the advantages?

That is the primary advantage ... or rather all the consequences of having globally unique addresses for everything available with minimal administrative overhead.

> ipv6 vs ipv4 Which one is better for privacy?

Rarely makes a difference (web tracking happens via cookies anyway), and IPv6 has a huge potential of enabling less centralized protocols.

> Which one is better for security?

IPv6, because one flat address space without translators is easier to reason about and doesn't need so many workarounds to make connections work.

> Which one is better for speed?

According to what large content companies publish, IPv6 is usually quite a bit faster (lower latency), rarely slightly slower.

> Which is easier to configure?

IPv6

> Which is better for end user?

Directly? Doesn't really matter. Indirectly? IPv6.

> Which is better for advanced user / net admin?

IPv6 hands down.

> Which is better for companies?

IPv6, unless you have to deal with legacy software that doesn't want to speak IPv6.

Re: Serveo: Expose Local Servers to the Internet

#118

Post by solotronics »

rohan1024 wrote: post #8

NAT has crippled the Internet. We are permanently dependent on public facing servers to route packets from one device to the other. This service is absolutely not needed in a non-NAT world. And I strongly believe we have lost a lot by being completely dependent on client-server model of Internet. I've written more about it here https://www.ankshilp.in/post/the_broken_promise_of_internet/

As a network engineer I believe IPv6 is the answer.

Re: Serveo: Expose Local Servers to the Internet

#119

Post by ubercow13 »

zAy0LfpBZLC8mAC wrote: post #109
ubercow13 wrote: post #82

Earlier quoted context omitted.

Why would it be forwarded? Do you mean that it forwards it to itself, the NAT device addressed by the actual public IP? Wikipedia seems to disagree [0] "if the destination port number of the incoming packet is not found in the translation table, the packet is dropped or rejected because the PAT device doesn't know where to send it." I am sure a NAT could be configured any number of ways, though, and could probably do…

> Why would it be forwarded? Because the device is a router, and that is what routers do. > Do you mean that it forwards it to itself, the NAT device addressed by the actual public IP? No, it forwards it to whatever destination address is in the destination address field of the IP headers, because that is what IP routers do. If it is addressed to one of the NAT device's own addresses, of course, the routing decision…

Wouldn't the router only have a route for 192.168.0.x or whatever to go to the private interface? Why would a packet still addressed to the public IP get routed to the private network interface?

>NAT has nothing to do with whether inbound connections are possible

So how would you address a device on the private network from outside?

edit: I read your other response. Fair enough, if your ISP is sending you privately addressed packets they could get through.

Re: Serveo: Expose Local Servers to the Internet

#120

Post by iampims »

ris wrote: post #85
iampims wrote: post #12

I’m a big fan of Cloudflare Tunnels: https://www.cloudflare.com/products/argo-tunnel/ https://ngrok.com is also a very good alternative.

> https://ngrok.com is also a very good alternative. But with non-standard and proprietary client software.

True. I believe version 1 of ngrok was open-sourced, or at least source available.
Post reply on HN