All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Your network ACLs are wrong and here is why
As you may know, we (skhron) are sending abuse complaints for port scan. And to prevent any false-positive accusations, we consider only validated TCP connections (by 3WHS) and wait for certain amount of events depending on a observed behaviour, because anyone can make a typo when entering IP address.
Today we got reply to one of such automated abuse complaint:
Hello , port 445 is Blocked from our network .This scan is not from our ip address .we have blocked port 445 on x.x.x.0/24
However, we have asked them how their restriction is implemented:
Can I ask if your filters were enforced like both of those rules:
1. src ip x.x.x.0/24 && dst tcp port 445,
2. dst ip x.x.x.0/24 && src tcp port 445?
And were told:
Hello there. I think you are correct it was not added for dst. We have done so now please may I ask to see if it still hitting you guys. Also is it possible to give me the attack ip or is it random ips
Why would I need both rules? Isn't first one sufficient?
Having both rules will prevent attack similar to one described in this publication. Short story long, it cooperates attackers' device within restricted network and another attackers' device, which is capable of source IP spoofing, and is outside of restricted network.
Comments
ELI5 does an average VPS/dedi customer with forwarding enabled need to worry about spoofed source packets getting past the provider’s router?
If I got you correctly, you could not distinguish single packet is it spoofed or not when received from global Internet. You can only figure out if its' source IP address is bogus (0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and so on) or is from your own network.
For more information please refer to the image below or their website
You may wonder however - how TCP prevents IP spoofing?
Unlike UDP, it requires to synchronize sequence and acknowledgment numbers to establish connection (three-way handshake, 3WHS - the process of sending SYN, SYN-ACK and ACK segments), and thus requiring both parties to be able to see incoming traffic.
Being connectionless, UDP is easily abused for amplification attacks (NTP, DNS etc) if applications were not additionally protected by some kind of handshake. For example, wireguard is not vulnerable for amplification.