Re: why do I see failed login attempts to vm on non-forwarded ports?

Dale Scott wrote:
> IIUC, the attacker attempts an ssh login on port 3022 on the host
> system, which is handled by the virtualbox NAT and sent to vm client
> port 22 from host port e.g. 51252. Do I understand this correctly?

That sounds to be correct given the information you provided so far.
Port 22 on your host is going to your host.  Port 3022 is going to
your guest through the routing table.

> Why does the host use so many different ports?

Every TCP/IP connection has four important parts that allows data
packets to be routed from place to place.  This is like a postal
envelope with a destination address and a return address.

    source address
    source port
    destination address
    destination port

A connection from your local system to a remote system will of course
use the remote system's destination address and destination port.
The reason there is obvious.  It has to get to there.

But data packets need to return too!  Just like we say in mountain
climbing, It does not count unless it is a round trip.  If the data
packet does not have a way back then it does not make a connection.

In order to come back it the remote end needs to know the local
system's address and port for the return trip.  The source address
will be the address for the return from the remote system.  For most
people that means a NAT network address translation at the router.  So
from your example a local 10.0.2.2 address outbound might get
translated to a 93.184.216.34 public IPv4 address at the NAT router
and that will be the source address seen at the remote server.  On the
return trip the NAT router will translate the address back to
10.0.2.2 on your LAN system.

And then there is the source port...  The destionation port will be
some well known port.  Either port 22 for ssh or port 80 for http or
port 443 for https or whatever.  But what will be used for the local
source port?

The network kernel will assign a dynamically assigned port number to
the connection for the local machine.  It will be in the dynamic port
range.  Think of this like you would think of any process ID PID
number.  It gets assigned dynamically.  It's attached to the file
descriptor.  When the file descriptor is closed the number is
unassigned and available for eventual reuse.  While the connection is
active the source port is maintained.

One of your examples showed this.

    Invalid user admin from 10.0.2.2 port 36002

That's probably the address of the NAT router.  Unfortunately in this
case the actual IP address was lost in translation (sorry but I could
not resist the humor) and would be seen only in the router table.
This is actually not typical of NAT.  I don't want to say your system
is misconfigured but it feels to be an odd configuration to me that it
would NAT the source address.  More typically the global address would
be preserved.  But this is from one of your example lines so I am
using it.  Here is from one of my systems.  Someone at a cloud
provider is probing my system.

    Invalid user mysql from 104.131.40.97 port 34532

So using this case the four parts of the data packet would be this.

    source address -- 104.131.40.97
    source port -- 34532 randomly assigned on remote system
    destination address -- 93.184.216.34
    destination port -- 22 ssh

And then my system when it responds will turn those around and send
the return packets back using the reverse.

    source address -- 93.184.216.34
    source port -- 22
    destination address -- 104.131.40.97
    destination port -- 34532

That's for ONE connection using TCP/IP for one process.  A system will
have many processes.  Each process might have many connections.
Packets out.  Packets in.  The dynamically assigned port (the
pseudo-pid number of the connection) will be different for every
connection.  That is the free variable since the other three parts are
fixed.

Hope this helps!
Bob