ANSWERED Incoming connections from unknown/untrusted IPs

[tamikyle 4]

Today my firewall blocked an incoming NTP (port 123) connection from 134.147.203.115. A quick reverse DNS lookup reveals its current domain name to be scanresearch1.syssec.ruhr-uni-bochum.de, so presumably someone at RUB is doing some kind of experiment involving scanning internet users.

 

My question is: how would this sort of thing find my PC? If my public IP address is shared with all those on my chosen VPN server, then why me? How me? Are they just trying all the ports on the AirVPN server, hoping that one of them is translated to a valid NTP connection?

[Staff 9972]

Hello!

 

It can't come from the VPN server because incoming packets are not forwarded to clients, except those directed to the remotely forwarded port (to the proper client VPN IP address). By default no inbound port is forwarded to a client.

 

Kind regards

[serenacat 83]

Curiosity - sniff, peer, poke.

Tried http://scanresearch1.syssec.ruhr-uni-bochum.de

and it has something to tell you.

But baffled and bemused.

[tamikyle 4]

Hello!

 

It can't come from the VPN server because incoming packets are not forwarded to clients, except those directed to the remotely forwarded port (to the proper client VPN IP address). By default no inbound port is forwarded to a client.

 

Kind regards

 

Yes, I understand how port forwarding works, and how the servers don't (or at least ought to not) forward random incoming connections (after all, which client would/should they forward a random incoming connection to?). But what about "welcome" incoming connections? Incoming connections are a part of the internet, and many services (e.g. bittorrent, ping, ntp) expect incoming connections. When a client makes an outgoing connection using a certain port, it gets translated into a different port on the VPN server (this is often called NAT or "masquerading").

 

I meant to ask if the (only possible) way the RUB server found the port on the AirVPN server which was being translated to my client IP, port 123 (NTP), was by brute-force trying all the ports; or could it be that outgoing connections from the servers are being observed elsewhere, then those ports specifically scanned?

[Staff 9972]

many services (e.g. bittorrent, ping, ntp) expect incoming connections.

 

Hello!

 

Sorry, but that's simply not true. Also note that ping (ICMP) is not even at the transport layer (it's at the Internet layer). And please do not confuse incoming packets reaching one of your system ephemeral inbound ports as a consequence of an already opened socket etc., with incoming connections to a listening service (if any).

 

Anyway you can have TCP incoming connections with remote port forwarding (you can also have UDP packets forwarded, so the system is not limited to incoming connections over TCP). By default, an Air VPN client has no forwarded ports, so it can not receive any incoming connection, and it can not receive forwarded UDP packets.

 

I meant to ask if the (only possible) way the RUB server found the port on the AirVPN server which was being translated to my client IP, port 123 (NTP), was by brute-force trying all the ports; or could it be that outgoing connections from the servers are being observed elsewhere, then those ports specifically scanned?

 

It's physically impossible, if you have not forwarded remotely any port. You can remap any remotely forwarded port to any local port. If you receive unsolicited packets from the Internet and you have not forwarded any port in your account panel, such packets have reached your ISP-assigned IP address and have nothing to do with the VPN server. Do not forward ports in your router or keep Network Lock enabled to prevent that.

 

Kind regards

[serenacat 83]

Going to http://www.ntp.org

there is this notice

"NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. ..."

"ntp-4.2.8p10 was released on 21 March 2017.
It addresses 6 medum- and 5 low-severity security issues, 4 informational security topics, 15 bugfixes, and contains other improvements over 4.2.8p9."

so things are happening, and the activity from scanresearch1.syssec.ruhr-uni-bochum.de seems justified.

 

Edit: Remove nonsense thoughts

[itguy2017 25]

Networking 101 here folks.

 

All inbound ports are blocked, by default, unless you've opened those ports or have them forwarded.Simple.

 

In the real world of corporate/enterprise security there is a default 'Deny/Deny/All' policy on ALL firewalls. This policy blocks all inbound port traffic. You must explicitly allow inbound ports via policies before the explicit deny or everything will be prohibited.

[tamikyle 4]

And please do not confuse incoming packets reaching one of your system ephemeral inbound ports as a consequence of an already opened socket etc., with incoming connections to a listening service (if any).

 

...

 

It's physically impossible, if you have not forwarded remotely any port. ...keep Network Lock enabled to prevent that.

Hey! Thanks for the quick response. I don't feel like you've entirely answered my question, though.

 

Yes, I'm conflating incoming packets reaching an ("ephemeral") already-open socket with incoming connections to a listening service. Sorry for any confusion there. I have no ports forwarded, and my network lock was enabled at the time, so I'm trying to make sense of how this could have happened, given this setup and my limited knowledge of how networking works.   My question about networking is: if my computer has made a call out to some (trusted) NTP server, and the socket is still open, could another computer (which somehow guessed the ephemeral port number on the AirVPN server) also send packets to that port, successfully using the same socket? As I understand it, there's no "same IP address policy" on sockets, is there?

 

Edit: and if this isn't possible, does anybody have any other ideas of how it could have happened?

[Staff 9972]

My question about networking is: if my computer has made a call out to some (trusted) NTP server, and the socket is still open, could another computer (which somehow guessed the ephemeral port number on the AirVPN server) also send packets to that port, successfully using the same socket?

 

This scenario resembles an attempted packet injection by some MITM analyzing traffic outside the VPN server (when it is not encrypted by OpenVPN). Again what you describe is impossible. OpenVPN has a packet authentication system which would have rejected the forged, injected packet.

 

 

Edit: and if this isn't possible, does anybody have any other ideas of how it could have happened?

 

The most plausible explanation, if Network Lock was really enabled and firewall rules were not modified, is that it never happened and you misinterpreted something.

 

If we discard this last explanation then the fact that your system is compromised must be taken into serious consideration.

 

Kind regards

[tamikyle 4]

The most plausible explanation, if Network Lock was really enabled and firewall rules were not modified, is that it never happened and you misinterpreted something.

 

If we discard this last explanation then the fact that your system is compromised must be taken into serious consideration.

Thanks for indulging my curiosity. I think the most likely scenario is that Network Lock was in fact off, even if I thought I had it turned on. I do switch it on and off often enough; it's quite conceivable that I had it off without noticing.

[tamikyle 4]

So, an update on this one: (sorry to zombie the thread)

 

Turns out my other firewall is hooked in "first". This is easily testable: with the network lock engaged, but without a VPN connection, and my firewall set to prompt me about any connection, I can try to surf to any website. My firewall will prompt me about it; if I allow the connection, it will still not go through. The network lock is still blocking the connection, even after my regular firewall allows it.

 

Mystery solved!