Please explain this "spoofing" alert

Avast Business Pro on-premises console. See the attachment for full details (this didn’t occur on my machine so I don’t have the pop-up that appeared there, not that they typically are of any use anyway).

I’ve never seen this type of alert before. It comes, apparently, from the Avast firewall “shield” and it seems to describe some kind of communication from or to a local network IP address: 10.30.12.2. No devices on the network have that IP address, whether static or leased. If I ping that address I get replies back from the IP address that is leased to my workstation with “Destination host unreachable”.

I don’t know what this means at all or whether I need to be worried about it. Can anyone explain this? Thanks.

Read here what probably could have taken place as ARP Spoofing is involved and it is not a FP;
https://en.wikipedia.org/wiki/ARP_spoofing

0

If an attacker (or other) spoofs their IP address, as far as TCP/IP is concerned then, if performed correctly, the request looks like a genuine request from the spoofed IP and the spoofed IP will recieve the response from the server, not the attacker/sender. You will not be able to trace it unless you hold some sway over the network i.e the machines that routed the request.

I think what the answer above means by “packets with a “external” source address should be seen as incoming packets” is that any inbound requests that do not belong to the IP block(s) the the ISP owns are treated as external.


Quote from securitystackexchange. Credits go there,

Solutions -

There are several approaches to preventing ARP Poisoning attacks:

Static ARP Tables
It’s possible to statically map all the MAC addresses in a network to their rightful IP addresses. This is highly effective in preventing ARP Poisoning attacks but adds a tremendous administrative burden. Any change to the network will require manual updates of the ARP tables across all hosts, making static ARP tables unfeasible for most larger organizations. Still, in situations where security is crucial, carving out a separate network segment where static ARP tables are used can help to protect critical information.

Switch Security
Most managed Ethernet switches sport features designed to mitigate ARP Poisoning attacks. Typically known as Dynamic ARP Inspection (DAI), these features evaluate the validity of each ARP message and drop packets that appear suspicious or malicious. DAI can also typically be configured to limit the rate at which ARP messages can pass through the switch, effectively preventing DoS attacks.

DAI and similar features were once exclusive to high-end networking gear, but are now common on almost all business-grade switches, including those found in smaller businesses. It’s generally considered a best practice to enable DAI on all ports except those connected to other switches. The feature does not introduce a significant performance impact but may need to be enabled in conjunction with other features like DHCP Snooping.

Enabling Port Security on a switch can also help mitigate ARP Cache Poisoning attacks. Port Security can be configured to allow only a single MAC address on a switch port, depriving an attacker the chance to maliciously assume multiple network identities.

Physical Security
Properly controlling physical access to your place of business can help mitigate ARP Poisoning attacks. ARP messages are not routed beyond the boundaries of the local network, so would-be attackers must be in physical proximity to the victim network or already have control of a machine on the network. Note that in the case of wireless networks, proximity doesn’t necessarily mean the attacker needs direct physical access; a signal extends to a street or parking lot may be sufficient. Whether wired or wireless, the use of technology like 802.1x can ensure that only trusted and/or managed devices can connect to the network.

Network Isolation
As stated previously, ARP messages don’t travel beyond the local subnet. This means that a well-segmented network may be less susceptible to ARP cache poisoning overall, as an attack in one subnet cannot impact devices in another. Concentrating important resources in a dedicated network segment where enhanced security is present can greatly diminish the potential impact of an ARP Poisoning attack.

Encryption
While encryption won’t actually prevent an ARP attack from occurring, it can mitigate the potential damage. A popular use of MiTM attacks was to capture login credentials that were once commonly transmitted in plain text. With the widespread use of SSL/TLS encryption on the web, this type of attack has become more difficult. The threat actor can still intercept the traffic, but can’t do anything with it in its encrypted form.

from a varonis blog/data security - credits for the txt go there

polonus

So it turns out the user was not connected to our network at the time of that event; they were on somebody else’s (hopefully) guest wireless network. But in your opinion that would still be a legitimate case of something unauthorized on that network attempting to spoof a legitimate device?

The network belonged to a school district. Could it actually have been a legitimate, school-installed monitoring device on that network?

Thanks.

i don’t know if this is the correct thread to post in, forgive me, i’m a newb. i recently have been getting email notifications re: a company called WebRoot, or so they say. they tell me my order has been taken & my acct will be debited by aprox $500. usd. i have no such acct., and email asks for customers to call a certain number to take care of the matter. it’s obviously false, & i blocked & deleted, but later i will hear from them again, under a different name/new heading. is it possible by info was ‘stolen’ while having Avast protection? thx much, any info helpful