Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I rent a dedicated server from a hosting provider. I ran wireshark on my server so that I could see incoming HTTP traffic that was destined to my server.

Once I ran wireshark and filtered for HTTP I noticed a load of traffic, but most of it was not for stuff that was hosted on my server and had a destination IP address that was not mine, there were various source IP addresses. My immediate reaction was to think that somebody was tunnelling their HTTP traffic through my server somehow.

However when I looked closer I noticed that all of this traffic was going to hosts on the same subnet and all of these IP addresses belonged to the same hosting provider that I was using.

So it appears that wireshark was intercepting traffic destined for other customers who's servers are attached to the same part of the network as mine.

Now I always assumed that on a switch based network that this should not happen as the switch will only send data to the required host and not to every box attached.

I assume in this case that other customers would also be able to see data going to my server. As well as potential privacy concerns, this would surely make ARP poising easy and allow others to steal IP addresses (and therefor domains and websites)?

It would seem odd that a network provider would configure the network in such a way. Is there a more rational explanation here?

share|improve this question
    
just a guess but is it host management traffic, as in the something along the line of vmtools etc being talked to via http. –  tony roth Oct 19 '12 at 17:14
    
@tony roth , It doesn't look like it. I visited some of the URLs and it was a variety of stuff but it was all fairly "general" web stuff like website pages and streaming videos etc. –  user350325 Oct 19 '12 at 17:17
    
yikes then thats a poor hosting site, I'd throw a host based FW up if I were you. So you are seeing http traffic that has a source and destination ip thats not yours? –  tony roth Oct 19 '12 at 17:22
    
Yes, that is what I see. The destination ips are the same as mine apart from the last octet. Source IPs vary. I'm not sure if a FW would help me here? As I understand it there is nothing stopping somebody else from reading traffic to my server and replying to it themselves? –  user350325 Oct 19 '12 at 17:28
    
kinda stumped here as far as I know the only two ways for this to happen is that your port is being spanned to or its plugged into a hub.. your device should be on its own vlan minimally so this is really screwed up. –  tony roth Oct 19 '12 at 17:33
show 6 more comments

2 Answers

Clearly what you have described is a very bad practise for a shared environment and I would take it up with your hosting provider.

The most reasonable explanation would be a load balancer, possible a high availability firewall in load sharing mode within the same network segment using a multicast MAC address with a unicast IP address for routing. By using a multicast MAC more then one firewall can see the traffic and they would implement their own load balancing algorithm so online cluster members each only respond to a part of the traffic. The unicast IP address is attached to a virtual IP for the purpose of routing. Because the IP resolves to a multicast MAC any traffic sent to it get multicast on the local segment and picked up by one of the cluster nodes.

I have seen this configuration before, however without knowing the network it is only a guess, but the most likely given it is a hosting provider.

One example is NLB http://technet.microsoft.com/en-us/library/bb742455.aspx however I know Check Point firewalls in some configurations as well as a hand full of other products that do the same.

Reiterating though, it is an insecure configuration for a shared hosting model.

share|improve this answer
    
Good suggestion. CLUSTERIP iptable in Linux (often driven by Corosync) provides the same unicast IP on multicast MAC solution –  Alastair McCormack Oct 20 '12 at 9:23
add comment

Switches work like this:

By default, they operate as a hub; all traffic goes out all interfaces. But once traffic comes inbound with a given source MAC, traffic destined for that MAC will only go out that interface. If a given MAC is seen on multiple interfaces, it will go out on both; possibly eventually resetting and only going out the one where traffic was most recently seen.

That's the default behavior. It't the only behavior for cheaper hardware, but managed switches can be configured to your heart's content. So anything is possible. Note that at no point did I mention IP addresses; switches traditionally work on layer 2, not 3. Expensive managed switches can blur the line with routers, but traditionally they only worry about MAC addresses. However, poor configuration can override the typical switching behavior and do away with any sort of host isolation.

There's one other thing worth mentioning though: A bridge. How is that relevant? It matters if your hardware is virtualized, as is becoming increasingly common even with "dedicated" (definitely in air quotes) hosting providers. Specifically, VMs are connected to the network either by co-opting the network adapter or by attaching to a virtual network within the box, typically set up as a bridge. In both cases, all the VMs are on the same switch segment, which means packet-capture-palooza.

Finally, they could be using a hub. Yeah, probably not. But just sayin.

share|improve this answer
    
-1. This is SO much NOT how Switches operate. A normal Switch noramlyl onfigured by a non-idiot will not work likea hub. It will learn IP addresses by ARP. Your Default behavior would make a Switch useless. –  TomTom Oct 20 '12 at 9:37
    
@TomTom Switches don't learn IPs, they learn MACs. This is why you can use a switch with non-IP network protocols. Layer 3 switches can do IP inspection, but they're really by definition routers instead of switches specifically for that reason. Switches can use ARP returns to learn MACs, but really any traffic will do, ARP included. This is why a switch plugged into an active network will immediately become functional without requiring all the hosts to re-discover their neighbors. Here's a text on the subject if you want to fact-check my work. –  tylerl Oct 20 '12 at 19:41
    
Well, at no Point does a Switch work like a hub. That is the Point I do. –  TomTom Oct 21 '12 at 6:03
    
@TomTom Oh? really? You're just dead certain of that are you? From Cisco: "If the switch receives a packet with a destination MAC address that does not exist in the bridge table, the switch sends that packet over all its interfaces that belong to the same VLAN assigned to the interface where the packet came in from." But what does Cisco really know about switches, anyway. Right? –  tylerl Oct 21 '12 at 7:41
    
@tylerl in this case he's talking about the http protocol not an l2 protocol. So on a switched network he should not be seeing http based communication BETWEEN other nodes on the network, either the source or destination IP should be his node. Even most virtual networks are switched thus its not really "packet-capture-palooza" –  tony roth Oct 22 '12 at 15:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.