New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Can a destination ip be spoofed?
I've heard about spoofed src ips in packets, but now I got flooded with packets with a wrong dst ip.
Can those be spoofed as well?
But even then: why should that machine get the traffic?
Or is this just a routing error from upstream?
(It's a vps using dhcp).
Thanked by 1WyvernCo
Comments
Ok, no idea what they are doing there again, but it looks as if I see the whole traffic for a /24 or at least all neighboring vps/dest ips on the same hypervisor while having only one /32.
wtf. I was wondering already about that crazy ingress.
Most likely, the issue is related to your hosting provider’s network routing
Yepp, new day, new problems with one special vps provider...
@allthemtings even your are a client of that company
but probably not with vps.
It sounds like a misconfiguration on the hypervisor's virtual switch or bridge. Your VPS is likely receiving traffic meant for other VMs on the same host due to incorrect VLAN or routing settings. This is definitely an internal issue with your provider's network infrastructure.
Looks like your hypervisor is allowing promiscuous mode on your virtual network device. I have seen one or two providers doing this.
You probably captured traffic with tcpdump or other tool that sets promiscuous mode on when starting (and sets it off when stopping).
Try to capture with: sudo tcpdump --no-promiscuous-mode -i yourinterface
If you then only see your own packets (and maybe arp requests), then all is fine.
If the hypervisor/switch doesn't enforce/filter IP-MAC binding, anyone in the same rack can transmit a packet with your MAC as destination MAC but with arbitrary destination IP.
Your NIC would then receive such packets even without promisc mode.
Your OS should drop these packets as it's not listening on this IP.
What company?
@yoursunny, yes the OS seems to drop those, but I still find it curious that I can see all those packets not belonging to me but others.
@eliphas thank you, this sounds exactly as what is happening.
But I do not get why the provider would allow that promiscuous mode to see the other traffic but I had the -p flag in the call.
Yep, I've seen that before. You can spy on DNS answers because they're unencrypted. It's fun.
That's the way old-fashioned Ethernet hubs (not switches) used to work. Back then, it was up to each client to simply ignore messages not meant for it. Of course, as time went on and speeds increased, collisions started becoming an issue, so switching became mandatory for pretty much anything above 10 Mbps on pure hardware.
With virtual servers, the issue is almost always going to be a mere misconfiguration.
I think iHostArt has or had that problem too, btw.
I do think so as well as this is only happening in some of the providers locations, but not all.
And I cannot reproduce this with any other provider at the moment.
Find another IP on that /24 which is in use (just find one that responds to pings), then send a TCP SYN to it from some different machine while running tcpdump in promiscuous mode on your own VPS. If you see that SYN arrive, you know it's leaking traffic for sure. If that's the case, it's a serious security issue and you should report it to them.
This is what I see e.g.:
..... > ......, ethertype IPv4 (0x0800), length 74: aa.aa.aaa.aa.15026 > bb.bbb.bbb.bb.80: Flags [S], seq 478507701, win 65535, options [mss 1400,sackOK,TS val 3707720702 ecr 0,nop,wscale 8], length 0
where aa.aa.aaa.aa is some ipv4 from some external isp, while bb.bbb.bbb.bb is one the same /24 than my vps, but not mine - instead it's a neighbor on the same hostnode.
This is captured with tcpdump -tulpen so it is in non-promiscuous-mode.
(and a lot more with different ips from the same /24 and different ports: tls, ssh etc.)
With aa.aa.aaa.aa is an IP that you control, and you've confirmed that bb.bbb.bbb.bb is actually in use and allocated to some other customer (e.g. by checking if any ports are open or checking if it responds to ping)?
Why
-uand-l? That looks more like a series of netstat flags than tcpdump!No, aa.aa.aa.aa is not mine, it's a third party (e.g. a client unknown to me connecting to bb.bbb.bbb.bb port 80 where bb.bbb.bbb.bb is also not mine and unknown to me but is on the same /24 than me and on the same hostnode). So my vps would have bb.bbb.bbb.cb as example and that is where I capture the traffic to bb.bbb.bbb.bb.
Regarding -u and -l, I get the same without them and have no idea why in my old degrading brain why I saved those -tulpen into memory (probably because a) I never figure tcpdump and b) it is easy to remember in German
All this started when my monitoring alerted me on ingress traffic that would resemble a (D)DoS attack and I checked the traffic via tcpdump and saw all that traffic captured that are for other vps on the same hostnode that are not mine.