Solved: Unknown servers on VLAN
-
@jknott said in Unknown servers on VLAN:
customers on virtual machines, which means they're sharing everything below the VM
While sure this might be the case - but in the DCs my company runs. Customers are normally on their own VM host. I would have to get with that team if there is any instances at all of shared host.. Their could be some, but while they might share physical hardware - there would still be isolation practices put in place.
Their own vswitch, which is isolated to their specific vlan. While they might share the same physical host, and physical networking infrastructure etc... Customer A shouldn't be seeing traffic of customer B.. And they shouldn't be able to talk to their other devices no matter what they do - like just changing IP ranges for example ;)
Most customers in our DC are larger and have many different servers or VMs, etc. We don't cater single use VMs etc. Where you might get some customer with only 1 or couple VMs, etc. While this might be the case in hosts of vps where any user can just give a CC and get a VM on a month to month basis sort of thing.
Big issue with say meltdown and spectre was that very issue of customers on the same VM host being able to get info from other customers vms, etc. Segregation of customers to their own VM hosts makes for good practice against such sorts of exploits.
Even when customers VMs share the same host - they should still be isolated where A can not see B traffic. And vise versa.
-
Mmm, I'm not sure what you are actually testing there. I assume 1.1.1.1 is an IP you have substituted there? On which interface?
If you are seeing broadcasts from other unknown IPs on the DCLAN in a packet capture that's much more concerning IMO.
Steve
-
@stephenw10 said in Unknown servers on VLAN:
unknown IPs on the DCLAN in a packet capture that's much more concerning IMO.
exactly! Looks like to me he is just scanning a IP range, which would be attempted via routing if the IP range is not actually attached. Or you didn't force use of a specific interface, and use a specific source IP that was in the range you were scanning.
He is just scanning the DC network - so yeah its pretty much a given there is going to be some stuff on the DC network he can prob get to.. The ones with 22 and BGP screams a router to me.. Which since show "closed" say rejected vs dropped. Which could be common setup for blocking your own internal networks.. I reject stuff I block internally - so the client doesn't waste time with a retrans, etc.
I believe the default scan would be a syn scan, so showing closed means got back a RST.. If got no answer or got back an icmp unreachable then it would show as filtered.
-
The 1.1.1.1 is my edited WAN IP
To clarify, I have my own hardware in a rack at the DC, nothing shared, not a shared vm environment. I have my own WAN blend but also have a LAN connection to communicate with some other servers in the DC which aren't in my rack. However, that LAN is in fact a VLAN that is assigned to each customer and I was told that it is completely secure.
I'm scanning from the pfsense box which has three connected interfaces. One to WAN, one to a LAN switch then servers behind that and one I've called DCLAN which is my LAN/VLAN network.
When scanning and using the specific interface of DCLAN, all I really get is;
snip
setup_target: failed to determine route to 192.168.255.253
setup_target: failed to determine route to 192.168.255.254
setup_target: failed to determine route to 192.168.255.255
snip
But without entering any interface is when I see other servers.
I should not be seeing any private IP's through my WAN and I only have 10.0.0.1/24 IPs being used on my LAN so that's why I'm curious where these other servers are coming from since that would be from the DCLAN.I've asked the DC but of course, they have to explain what private IPs are like I know nothing what so ever which is frustrating. Meaning, any time you even bring up networking questions, they seem to get evasive or almost belligerent while as a customer, I'm just trying to understand what I'm seeing and why.
Update: Ah, today, someone says yes they didn't notice I had mentioned the internal LAN/VLAN so they are looking into it. I love this DC really but it's kinda funny how defensive they get when you ask about networking. In a DC, we're truly all together in this LOL.
-
Yes, that's expected then. Using the WAN as source you're not actually scanning anything in the DCLAN VLAN. You would need to set the DCLAN as source but when you do that it can only scan things in that subnet or for which is has a route using that interface.
So you could set the interface to have a huge subnet and it will ARP for everything.
Or run a pcap since almost everything will send a broadcast at some point and you will see it.Steve
-
@lewis said in Unknown servers on VLAN:
I should not be seeing any private IP's through my WAN
This is not actually true... While sure in a perfect world nobody would use rfc1918 in a DC.. A DC does have limited IP space - so internally they will almost always leverage rfc1918 space on devices in their network that is used to route other traffic.. example here is my trace to google from my isp..
Tracing route to www.google.com [172.217.1.100] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms sg4860.local.lan [192.168.9.253] 2 9 ms 10 ms 18 ms d47-69-1-60.col.wideopenwest.com [69.47.60.1] 3 11 ms 12 ms 8 ms 10.52.33.194 4 13 ms 16 ms 12 ms 76-73-164-154.knology.net [76.73.164.154] 5 18 ms 12 ms 13 ms static-75-76-101-196.knology.net [75.76.101.196]Look at hop 3 in my trace - this is clearly my isp network.. But it comes back as rfc1918.. Now that might also have a public IP, but the trace might have been responded with by the loopback or something. Or internally my isp might be using rfc1918 as their transit networks.. All perfectly fine and normal. Even if looks a bit odd via trace, etc.
rfc1918 are IPs that route, they are just not suppose to route over the public internet - but they for sure can route on any internal network, like an ISPs or a DCs etc.. Just like you can route them on your own local network.. They can route them on their internal network..
-
Thanks, lots of interesting information.
It makes sense that internally, they could be using both public and private IPs but on my VLAN which is supposed to be private, I would have thought I would see nothing but my own resources.
What I should do then is when I have everything fully set up and working is to test this in a more controlled way. As mentioned, using a large subnet or pcap.
I'll get back to this as I'd like to better understand the results of scanning networks.
-
@lewis you want really weird... Is when the DC uses public IP space internally, that is not theirs ;)
Lets just say I know a DC (multiple actually) where they leverage some of the DOD space internally in the DC.. So while tracing stuff that is internally to the DC you might see rfc1918, rfc1918, DOD space IP, rfc1918, where you traced too..
Your like WTF ;) I tried telling them hey that not really a good idea... But who am I some lowly network engineer from some backwater LBU.. Who am to question the almighty powers that be.. They don't need to get to those networks, none of their customers need to get to those networks (they hope).. And it frees up rfc1918 space they would of used that their customers can now use.. Now if those networks ever leaked out via bgp - they would be in some shit for sure..
I tried bringing it up multiple times - wasn't going to be a hill I died on, and just let it drop.. Ok you clearly no better than me ;) hehehe
edit: So I just scanned that 10 IP in my isp network, and I get back this is open
[22.01-RELEASE][admin@sg4860.local.lan]/var/db: nmap -Pn 10.52.33.194 Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower. Starting Nmap 7.91 ( https://nmap.org ) at 2022-03-15 10:34 CDT Nmap scan report for 10.52.33.194 Host is up (0.013s latency). Not shown: 999 filtered ports PORT STATE SERVICE 646/tcp open ldp Nmap done: 1 IP address (1 host up) scanned in 127.12 secondsIf I had to guess since LDP is used for exchanging labels in a mpls network, that is one of their routers and why I see it in my trace.. Now is that an optimal setup - prob not ;) But prob not a big deal because onlything that could possible get to that would be stuff internal to the isp network, or clearly their customers ;) hehehe
-
@johnpoz LOL, sometimes we get into trouble just for being curious I guess. But on the other hand, if no one ever questioned anything, things would come apart. Where is the balance? In your pay level maybe? :)
-
DC tells me it's their own hardware and as someone mentioned, because I was scanning all interfaces.
Thank you for the responses. Always learning :).
-
@lewis said in Unknown servers on VLAN:
because I was scanning all interfaces.
From the command you showed it wouldn't be scanning all interfaces, other then the interfaces you had that were in the networks you scanned. And then it would just send networks that were not directly attached out your default gateway. Which would be routed through your DCs network via your default gateway.
-
There are three NICs connected in the pfsense box.
One is WAN and two are LANs. All are of course routed internally so I'm sure LAN/WAN meet here and there.When I ran the nmap, I didn't specify an interface but I did specify a network.
-
@lewis said in Unknown servers on VLAN:
When I ran the nmap, I didn't specify an interface but I did specify a network.
Exactly - so if you scanned 192.168/16 and you had say 2 lan networks of say 192.168.100/24 and 192.168.200/24
It would scan those 2 networks because they are directly attached sending the traffic out those interface. But when it say scanned 192.168.101/24 out of your 16 it would of sent that to the default gateway out the wan.
As to lan/wan meeting??
If you scanned 10/8 and you had no interfaces in a 10.x network and or no other routes to get to 10.x then all of that traffic would of been sent to the default gateway.
-
@johnpoz said in Unknown servers on VLAN:
If you scanned 10/8 and you had no interfaces in a 10.x network and or no other routes to get to 10.x then all of that traffic would of been sent to the default gateway.
Yes, there were no replies from anything in the 10 network.
What I mean by LAN/WAN meeting is probably wrong. I was told by the DC that the LAN and WAN are fully separated networks within the infrastructure. -
@lewis said in Unknown servers on VLAN:
DC that the LAN and WAN are fully separated networks within the infrastructure
Wells your "lans" are completely isolated because they are behind pfsense ;) into your own switches that do not connect to anything else other than your devices - right?
-
@johnpoz said in Unknown servers on VLAN:
Wells your "lans" are completely isolated because they are behind pfsense ;) into your own switches that do not connect to anything else other than your devices - right?
Not exactly since I have two LAN connections and one WAN connection. The WAN is just that but one LAN goes into my own switch and the other LAN goes to the DC's internal LAN network where I am given a private VLAN that acts as my own LAN in the DC.
Hope that makes sense :)
-
@lewis said in Unknown servers on VLAN:
LAN goes to the DC's internal LAN network where I am given a private VLAN that acts as my own LAN in the DC.
Ah well then it could be possible for stuff to be on this network that you might not want on what is "your" network... So as suggested would check this network for devices that are not yours. You could do a arp scan, this is way better then doing a nmap scan.. Since you could scan for really any network at all that are on the same L2 (vlan)..
https://www.freebsd.org/cgi/man.cgi?query=arp-scan&sektion=&manpath=freebsd-release-ports
-arpspa=<s> or -s <s>
Use <s> as the source IP address. The address should be specified in dotted quad format; or the string "dest", which sets the source address to be the same as the target host address. This sets the 32-bit ar$spa field in the ARP packet. Some operating systems check this, and will only respond if the source address is within the network of the receiving interface. Others don't care, and will respond to any source address. By default, the outgoing interface address is used.You could just install the freebsd port onto pfsense if you have no other say linux box on this "dc" vlan that is one of your lan networks.
You could also get sneaky and set van IDs in your arp scan to see if you can jump vlans. Which would be bad in a DC..
But also just running a packet capture looking for arps on this network and see if you see any arps from stuff that is not yours on this dc "lan" network would be way to check as well.
-
Using arp, I see only my own stuff. I'll spend more time on this once I get everything else done. That way, it'll be a complete working config and hopefully, very secure as promised.
-
@lewis yeah arp scanning is very fast, and most anything is going to answer an arp, even if firewall blocking all protocols and ping, etc. Only problem with that sort of scan is you have to be on the same L2..
But for what your looking for its prob more in line with what your looking to do..
-
@johnpoz said in Unknown servers on VLAN:
@lewis yeah arp scanning is very fast, and most anything is going to answer an arp, even if firewall blocking all protocols and ping, etc. Only problem with that sort of scan is you have to be on the same L2..
But for what your looking for its prob more in line with what your looking to do..
Yes, basically just wanting to make sure I have my own relatively secure LAN (VLAN) network.
I'll do it again once everything is up.
