Re: arpwatch on OpenBSD vm misinterpreting data?
Paul Hanson wrote: > > 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? > > The newly advertised IP used the same mac as the default gateway. > > > Something like this might be seen if e.g. a new IP address was added on the > > default gateway router. > > This would be the most "comforting" rationale though I would expect my > hosting provider to be more forthcoming about an infrastructure change. and precisely what does this have to do with OpenBSD?
Re: arpwatch on OpenBSD vm misinterpreting data?
> 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? The newly advertised IP used the same mac as the default gateway. > Something like this might be seen if e.g. a new IP address was added on the > default gateway router. This would be the most "comforting" rationale though I would expect my hosting provider to be more forthcoming about an infrastructure change. Additionally, traffic was observed via TCP80 and TCP443 testing the configuration of HTTP and TLS protocols. Leading me to believe the IP was not benign. > 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. Agreed that tcpdump would be useful though I would expect arpwatch to be just as reliable. I have no doubt my hosting provider has certain protections in place. I've been a customer for a number of months with this being the first alert. Thanks, Paul
Re: arpwatch on OpenBSD vm misinterpreting data?
On 2019-09-09, Paul Hanson 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 AddressNetif ExpireFlags > 2.2.2.100:00:00:00:00:01vio0 9m30s > web22:22:22:22:22:22vio0 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.
arpwatch on OpenBSD vm misinterpreting data?
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 AddressNetif ExpireFlags 2.2.2.100:00:00:00:00:01vio0 9m30s web22:22:22:22:22:22vio0 permanent l I proceeded to look at pf (host firewall) logs. While I don't log drops there were a number of requests to tcp80 and tcp443. Parsing relayd logs showed none of the requests passed protocol security filtering. Beyond this, I have no way to determine if this arp spoofing was successful. Thus I reached out to my hosting provider with this information and their response was: "We have protections in place to defend against such things and therefore this style of attack can not be performed on our network. The data you are seeing here is a bit misleading. Thank you for your report." I've only been a customer for a few months and during that time there have been no alerts generated by arpwatch. However I don't understand how the data is misleading. This is because arpwatch runs in an environment I manage and is found to be quite useful. Thus I requested more context as to why the data is misleading and their response was: "It is misinterpreting data. This attack is not possible on our network and arpwatch is not relevant to our platform or how it operates." Support is clearly adamant that their hosting environment is impervious. However none of this makes any sense to me. The host is a basic install with no custom or one-off configurations. 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? Thanks, Paul
