All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Very weird inbound traffic I've never met
On my VPS, The inbound traffic reached 3T within several hours. The VPS has only sshd alive.
Then I do:
sudo tcpdump -i eth0 -n -c 50
it shows many rows like (I replaced the real ip addresses):
03:17:07.890241 IP 1.2.3.4.32864 > 1.2.3.5.49153: Flags [P.], seq 3355219349:3355284509, ack 606118437, win 502, length 65160
My VPS IP address is 1.2.9.9.
Then I use Firewalld to ban 1.2.3.0/24. The inbound traffic continues.
firewall-cmd --add-rich-rule='rule family="ipv4" source address="1.2.3.0/24" reject'
Now my situation is that the inbound traffic rises fast unless I shut down the VPS, so I did.
ChatGPT says this situation is already out of my control, and it is the provider that needs to look into it.
I'm not a veteran in this field.
Any suggestion, ideas would be much appreciated.
Comments
Not sure if it's the same provider, but I ran into this problem with one of them. They solved it by making my VPS unmetered.
It's probably traffic from inbound traffic to other VM's on the same VLAN with your provider. Poor configuration can cause this, such as leaked broadcast traffic. We've had this issue in the past ourselves that we only noticed when a customer pointed it out.
who need proper solution anyway
Is it LiteServer? I’ve had this issue. I could even inspect the data and see other VMs traffic. They were also kind enough to include it in my bandwidth quota
”Fixed” it by migrating me lmao
needs to be filtered on the hypervisor level, you cant do anything about it
I've seen this kind of BUM traffic happening on several providers before, and will send them a ticket when I notice it. Some eventually filtered them out, some still cannot.
My understanding is if your inbound traffic is not counted toward your monthly traffic quota, then you don't have to worry about it.
Does your VPS has forwarding enabled (is a router)?
If you have
And NO blocking firewall rules, your VPS could be used as a router, to send any packets from your IP. Even if you don't have IPv4 NAT (MASQUERADE) rules, and the attacker could not receive replies for the requests, they still can send the packets one-way and use your VPS IP for DoS.
Run
tcpdumpwith-eoption, you'll see MAC address for each packet. If the destination MAC is the MAC of the VPS network interface, than it's the case (VPS is a router).If not, then something is wrong on the hosting/switch side.
Automatically enabling forwarding and NOT block the transit traffic is common for some software configurations. This will happen if you install LXD/Incus for example (and the developers don't consider it a bug or a vulnerability, I've reported that).
I'm not sure I'd be at all worried about this.
Firstly, you have to go to a lot of effort to forward packets back out on the interface they came in on.
Secondly, your IP wouldn't appear in the outgoing packets, only your ethernet address. If the provider is smart enough to track down spoofed traffic by ethernet address, they'd not be broadcasting everyone else's non-broadcast traffic to you anyway.
Even if you weren't receiving everyone else's packets anyway, but you blindly forwarded all traffic sent to you, then you'd still be at risk from this. But like I said, by default Linux wouldn't forward back to the same interface anyway, which is why this isn't normally an issue.
It's an arp problem in the switch. Unicast traffic should only go to ports that responded with the MAC address.