On 2020-02-01 04:56, Samuel Sieb wrote:
On 1/31/20 12:35 PM, Ed Greshko wrote:
> On 2020-02-01 04:31, Samuel Sieb wrote:
>> Your original post was completely clear. However, something is happening on your
network that you aren't aware of. The fact that you are getting connections from an
external IP address means that somehow there is a path from the external internet to this
computer. It's possible that another computer on your network could somehow be
routing incoming packets to the computer, but the outgoing ones have to be following the
default route to the default gateway. An interesting split routing. tcpdump (or
wireshark) will give you the mac address and if it doesn't match your gateway, you
will have to track down which computer has that mac.
>
> And in that regard the "arp" command may be useful. That is if one is
aware of what IP addresses on
> the LAN belong to what devices.
I thought about that, but it's only useful for mapping back from the MAC address and
that would only work if the computers are talking directly using local addresses. Only
the attacking computer would have an arp entry for the target computer. If the target
does not normally have any communication with the attacker, it won't have an entry for
it. If he has access to the gateway computer, then that would more likely have an arp
entry for the attacker.
Well since arp is only on the LAN and since LAN communication is arp based the tcpdump
packets will
have the MAC address of the device on the local network from which the ssh packets were
routed through.
Normally, that would be the MAC of the gateway/firewall (assuming they are the same). But
at least one
would know the previous hop.
One more thing I just thought of, depending on the network structure, the incoming
packets could also be coming through the default gateway which would be even more
difficult to track down. But without the MAC address, it's all just speculation.
And if the incoming packets have the MAC address of the default gw and the default gw is
also the firewall
then that would indicate the firewall is not doing what the OP thinks it is doing.
--
The key to getting good answers is to ask good questions.