Printable View
If a device in a VLAN is hacked, whether this be an internetworking device or a computer system of some type, would'nt the hacker be able to see the other devices on different Virtual LANs by looking at the packets that are sent and recieved by that device? If this is true, would there be a way for one to have some type of packet stealth to prevent this?
Brandon64
The only way this could be done is if the device in question was on a vlan trunk (a trunk being a segment that receives packets/frames from multiple vlans because devices on that segment (or a downstream segment) belong to diffrent vlans. Usually, you don't have hosts (computers) sitting on a trunk segment, you would usually have trunks only between switches/routers (L3 switches). At the end of a trunk segment or when there's no trunking at all, (most often) the switch is setup to associate a vlan with certain port(s) so it only forwards frames for the determined vlan on that/those physical ports.
On the other hand, if there is a device like a normal computer with a NIC that supports VLANs (intel pro/100 for example) sitting on a trunk segment, it would be possible to have it "sniff" all the vlans by configuring the NIC as a member of those vlans...
Hope this helps a bit...
Ammo
Ammo
What about the packets? Is there no way to encrypt them? THanKS!
Which packets?
Are you refering to ip packets (datagrams) or ethernet packets (frames?)
For IP packets there are ways to encrypt them (IPSec) however can only encrypt unicast (not multicast or broadcasts). As for ethernet frames, AFAIK there is no way to encrypt them since it would brake the protocol... And VLAN does not provide encryption capabilities either; it's just not designed for that...
Ammo
There really is no need to encrypt everything on a VLAN either. I really wish I could have answered this one for ya, but ammo did a hell of a job explaining it and there is not much else to say, except that another way to be able to sniff all VLANS is to be connected to a SPAN port that is configured to mirror (SPAN) all other ports on the layer 2 or 3 switch.
Is this necessarily true anymore? I was under the impression that dsniff could do some spoofing magic with ethernet frames and trick a switch into delivering all traffic to the box connected in the switch, essentially giving it the capability to sniff all of the ports and circumventing the inherent protections of the switch (not saying this is easy, but merely possible).
The most feasible way would be to use only encrypted protocols, ssh, scp, sftp, ssl, etc for information you consider sensitive, (logon to system, anytime passing creditcard info, etc). I have always considered it a good security practive to never send this type of information in clear if possible to avoid and would recommend you move away from protocols that do not support encryption (if possible, which it isn't always) such as telnet, ftp, etc. Or you could also use encryption on top of insecure protocols for example using PGP to encrypt email traffic...
I always assume someone is looking and act accordingly :)
/nebulus
nebulus, this is basically the same thing you just said, just in a slightly different manner. You are exactly right.
My point is why encrypt something that doesn't need to be encrypted. A huge part of risk management is determinining what and what not to protect. If the cost (meaning $$ or resources) of protecting something outweighs the risk of losing it, then it is probably not a good decision. For example, do you really care if all the SPAM you get is encrypted. I guess that question is truly answered by how much value SPAM has to you, but for most of us, it is not worth the time or energy to protect something that is useless to begin with.
Regarding VLAN Trunks, surely a PC or Packet Sniffer sitting in a trunk VLAN would only see the data that needs passing between switches, not necessarily the data belongs to a VLAN that exists wholly within a single switch?
That's correct alanmott...
Ammo
Read:
http://naughty.monkey.org/~dugsong/dsniff/
http://www.linuxsecurity.com/feature..._story-89.html
Didn't say it was easy, just possible.
/nebulus
Actually nebulus, spoofing arp (dsniff) still does not give you to ability to sniff hosts on other vlans:
that is because the switch determines if the physical port is a member of the particular vlan: it is not based on MAC addresses... So if you were to use dsniff in a VLAN, you would be able to sniff other hosts on that vlan, but not hosts on other vlans (unless on a trunk link as I said eariler, in which case you wouldn't even need dsniff...)
Ammo
ACL's man....
ACL's have nothing to do with this...
ACL's do not prevent someone from using a packet sniffer to see what is going across the wire
When a port of a switch enter trunk mode . The datagram are not encrypted it self . If we use ISL trunk , Cisco Switch or Router add 4 field , call ISL header -everybody knows that- , or 802.1q internal header .
Trunking line is different from normal Accesslink in one aspect , capable of trasmiting data from more than 1 VLAN . Basically , Trunking is poor design for security , i guess .
A traffic-analyzer can easily capture Trunk-ethernet frame . Knowing the correct mode of trunk , so the hacker/cracker can easily decode it , determine which VLAN does this frame belong , and so on , the user data .
iNVicTus, Nebulus,
do you mean that tools like dsniff may fool a 802.1pq ethernet switch?
I am very surprised, because VLANs are hardware based (e.g. galnet) soft is there only to program cams. :confused:
If you ever heard or read a such experiment I'll be glad to learn about it!!!
:D
Whether VLAN are hardware based or software based has nothing to do with its proness to hacker's attack . Their principals remain the same . The hacker could always plug his PC to one port of the switch legally ( he is user in his Vlan) but when he crack down the Switch console , he could turn his port into trunk mode , and his local line to the switch become trunk line (with some setting in his pc - that is also a trunk port) and analyz other Vlan traffic by simply removing the ISL or 802.1q header (external and internal) . But that is Trunk .
In a dynamic Vlan enviroment , spoofing the the Vlan Membership Policy server (VMPS) about the host 's MAC address is quite possible . But a well designed Lan security policy will easily shut this hole .
Here ya go networker...enjoy:
http://www.sans.org/newlook/resource...ed_network.htm
Should we bother in such solution ? I think we just have to statically asign the MAC address of the critical server when we are configuring switch .
Thanks iNViCTuS,
that's quite a good paper (SANS is a good site anyway). I agree with that analysys adding maybe that the main risk is about DoS and not confidentiality (I don't believe in arp spoofing for spying a connection, real end users will quickly know that smth is wrong).Quote:
But DoS & ARP spoofing may be use to place a zombie in the white city and that's a way a coompromisong an host/server.
Anyway I still don't beleive there is a way to fool a ethernet switch properly configured.
For instance Hacher is in a default_VLAN (admin made sure that there no way to take hand on internal switch servers such as telnet or ftp from the default_VLAN=> hacker can not change anything about ports configuration) and the target is VLAN A.
I don't think that the hacker host as a chance to sniff anything on VLAN A just by sending layer 2 data to the zswitch to compromise it!
Of course , but changing his MAC address is quite possible ?Quote:
Originally posted here by Networker
For instance Hacher is in a default_VLAN (admin made sure that there no way to take hand on internal switch servers such as telnet or ftp from the default_VLAN=> hacker can not change anything about ports configuration) and the target is VLAN A.
I don't think that the hacker host as a chance to sniff anything on VLAN A just by sending layer 2 data to the zswitch to compromise it! [/B]
Yuna, do you mean that separate VLAN does not prevent from arp spoofing!?Quote:
Of course , but changing his MAC address is quite possible ?
Of course it does not, but you'll be only able to spoof mac adresses belonging to default_VLAN!
Remember that target is on VLAN A.
I believe (but i'll be very happy to be contradicted on this one) that the only naughty power of the attacker placed on default_vlan is a DoS attack on all VLAN but not compromising the confifentiality of other VLAN than default_vlan.
Indeed, switch MAC table is common to all VLANs (have a look in the RFC, VLAN are identified in the table thanks to additive parameter vlan_id or tag),
1- therefore the malicious attacker could flood with a large number of mac adresses (e.g incremental) and force the switch to drop valid mac adresse, temporally denying services to legal users!
2- the attacker could also duplicate MAC adresses to perturb the MAC table, but normally good switch implementation should prevent from taht risk by first looking at the vlan_id argument before mac adresses => such swich prevent from trouble with duplicate mac on separate VLAN.
(I'll test it on my lab if I have the opportunity to, but if someone had already done it i'll be glad to know about :D )
To Networker : Thanks for acknowledge my idea .
What i am saying is just that VMPS - dynamic Vlan , are more vulnerable than the static or port-centric one . That's right , MAC address spoofing itself can't be too dangerous if you has a well designed Switch network .
But in a dynamic VLan enviroment which vlan-membership are asigned by the VMPS server . Hacker always can spoof the VMPS clients (switchs) with VMPS server MAC address OR sniff the VMPS server transaction with clients to have valid MAC address ?
I've once hacked my own server with this technique . But problem is if you need to hack the VMPS server , you'll need more than MAC spoofing .
Thanks.
I've been looking for information over the net about VLAN threats and I've found one about Hopping VLAN attack within the SANS site (Note: the paper is 2 years old).
This attack is a blind attack that allow you to send packets to a VLAN you do not belong to(brrr).
P.S. I've written a tutorial on L2P attacks and mitigation I learned about => threadid=237836 ;)