On 2020-02-01 06:16, Samuel Sieb wrote:
On 1/31/20 1:52 PM, Ed Greshko wrote:
> On 2020-02-01 04:56, Samuel Sieb wrote:
>> 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.
I'm not sure what you're saying. Yes, the packets will have the MAC address of
the sending device. But the local arp table will most likely not have an entry for that
MAC address. So you will have to try to track down the device only by the MAC and not by
IP. The DHCP server would be a good place to look for that.
An ARP lookup is only done on sending, not receiving. Since the incoming IP address is
not local, there will be no ARP request made for the reply because it will be sending it
to the default gateway. (There might be an ARP request for the gateway if the entry is
stale.)
I see what you're saying. Thanks for pointing it out.
I suppose I'm use to smaller LAN segments where all systems are regularly
communicating.
But, it would not hurt to check to see if that MAC address did happen to show up in arp
table. If it were the
same as the firewall/gateway (again assuming they are one and the same) then one would
have to check
the firewall to see why it isn't doing what it is assumed to be doing.
--
The key to getting good answers is to ask good questions.