On 2019-09-09, Paul Hanson <phb...@outlook.com> wrote: > TLDR; - Arpwatch new station alert showed arp spoofing attempt. Cloud > hosting provider is adamant that arpwatch is misinterpreting data. > > OpenBSD 6.5 vm running in a cloud hosting provider: > > WEB# uname -a > OpenBSD WEB 6.5 GENERIC.MP#3 amd64 > > Arpwatch installed: > > WEB# pkg_info arpwatch | grep Information > Information for inst:arpwatch-2.1a15p19 > > Received arpwatch notification: > > WEB# grep arpwatch /var/log/daemon > Aug 29 10:43:57 WEB arpwatch: new station 2.2.3.12 00:00:00:00:00:01 > > Checked arp table and found the mac address matched that of the default > gateway. > > WEB# arp -a > Host Ethernet Address Netif Expire Flags > 2.2.2.1 00:00:00:00:00:01 vio0 9m30s > web 22:22:22:22:22:22 vio0 permanent l
That arpwatch notice just shows that there was a packet from an IP address that hadn't been seen before. What makes you think it's a spoofing attempt? Something like this might be seen if e.g. a new IP address was added on the default gateway router. > Later watching arp traffic showed typical conversations between the > host and default gateway. No other arp traffic was observed. > > WEB# tcpdump -lnettt -i vio0 arp > > I'm interested to hear feedback from misc@ as I didn't get a response > from the arpwatch list. Is there a log or config I should check? > Perhaps another utility to consider? Is my cloud hosting provider > misinterpreting data? Do you suppose they had unplanned & unannounced > maintenance? Anything else? A tcpdump from the same time that the arpwatch notice was triggered might give a clearer picture. Without knowing more about the network config I couldn't say for sure, but it's quite possible that the hosting provider does protect against arp shenanigans.
