Re: Application or Software to detect or Block unmanaged swicthes
I’ve got an easy way to do this, I confiscate ‘em ;) As others have said, this is a management problem. Untrustworthy parties shouldn’t have physical access to your trunk ports. That said Layer 2 MAC ACLs should block everything and allow only your switches. Also do you have lit trunk ports just floating in space? You shouldn’t...
Re: Application or Software to detect or Block unmanaged swicthes
How about some scripts around fail2ban, if the same account logs in multiple times, its banning time. Kasper On Friday, June 8, 2018, David Hubbard wrote: > This thread has piqued my curiosity on whether there'd be a way to detect > a rogue access point, or proxy server with an inside and outside > interface? Let's just say 802.1x is in place too to make it more > interesting. For example, could employee X, who doesn't want their > department to be back billed for more switch ports, go and get some > reasonable wifi router, throw DD-WRT on it, and set up 802.1x client auth > to the physical network using their credentials? They then let their staff > wifi into it and the traffic is NAT'd. I'm sure anyone in a university > setting has encountered this. Obviously policy can forbid, but any way to > detect it other than seeing traffic patterns on a port not match historical > once the other users have been combined onto it, or those other users' > ports go down? > > David > > > On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" < > nanog-boun...@nanog.org on behalf of m...@beckman.org> wrote: > > When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, > which has a Layer-2 collection feature that identifies the number and MACs > of devices on any given switch port. We export this list and cull out all > the known managed switch links. Anything remaining that has more than one > MAC per port is a potential violation that we can readily inspect. It’s not > perfect, because an unmanaged switch might only have one device connected, > in which case it wont be detected. You can also get false positives from > hosts running virtualization, if the v-kernel generates synthetic MAC > addresses. But it’s amazing how many times we find unmanaged switches > squirreled away under desks or in ceilings. > > -mel > > > On Jun 7, 2018, at 4:54 AM, Jason Hellenthal > wrote: > > > > As someone already stated the obvious answers, the slightly more > difficult route to be getting a count of allowed devices and MAC addresses, > then moving forward with something like ansible to poll the count of MAC’s > on any given port ... of number higher than what’s allowed, suspend the > port and send a notification to the appropriate parties. > > > > > > All in all though sounds like a really brash thing to do to your > network team and will generally know and have a very good reason for doing > so... but not all situations are created equally so good luck. > > > > > > -- > > > > The fact that there's a highway to Hell but only a stairway to > Heaven says a lot about anticipated traffic volume. > > > >> On Jun 7, 2018, at 03:57, segs > wrote: > >> > >> Hello All, > >> > >> Please I have a very interesting scenario that I am on the lookout > for a > >> solution for, We have instances where the network team of my > company bypass > >> controls and processes when adding new switches to the network. > >> > >> The right parameters that are required to be configured on the > switches > >> inorder for the NAC solution deployed to have full visibility into > end > >> points that connects to such switches are not usually configured. > >> > >> This poses a problem for the security team as they dont have > visibility > >> into such devices that connect to such switches on the NAC > solution, the > >> network guys usually connect the new switches to the trunk port and > they > >> have access to all VLANs. > >> > >> Is there a solution that can detect new or unmanaged switches on the > >> network, and block such devices or if there is a solution that > block users > >> that connect to unmanaged switches on the network even if those > users have > >> domain PCs. > >> > >> Anticipating your speedy response. > >> > >> Thank You! > > >
RE: Application or Software to detect or Block unmanaged swicthes
David, If you are using a product like ISE/Forescout you could set up multiple layers of device identification prior to network authorization. For example, a user would need to spoof the results of a legitimate device to match the results of: -NMAP scan -Domain machine/user Auth -OID/MAC etc It's simply a matter of dissecting the signatures of legitimate devices to the finest level of granularity and denying everything else. Best, Christopher -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of David Hubbard Sent: Friday, June 8, 2018 12:32 PM To: nanog@nanog.org Subject: Re: Application or Software to detect or Block unmanaged swicthes This thread has piqued my curiosity on whether there'd be a way to detect a rogue access point, or proxy server with an inside and outside interface? Let's just say 802.1x is in place too to make it more interesting. For example, could employee X, who doesn't want their department to be back billed for more switch ports, go and get some reasonable wifi router, throw DD-WRT on it, and set up 802.1x client auth to the physical network using their credentials? They then let their staff wifi into it and the traffic is NAT'd. I'm sure anyone in a university setting has encountered this. Obviously policy can forbid, but any way to detect it other than seeing traffic patterns on a port not match historical once the other users have been combined onto it, or those other users' ports go down? David On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" wrote: When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, which has a Layer-2 collection feature that identifies the number and MACs of devices on any given switch port. We export this list and cull out all the known managed switch links. Anything remaining that has more than one MAC per port is a potential violation that we can readily inspect. It’s not perfect, because an unmanaged switch might only have one device connected, in which case it wont be detected. You can also get false positives from hosts running virtualization, if the v-kernel generates synthetic MAC addresses. But it’s amazing how many times we find unmanaged switches squirreled away under desks or in ceilings. -mel > On Jun 7, 2018, at 4:54 AM, Jason Hellenthal wrote: > > As someone already stated the obvious answers, the slightly more difficult route to be getting a count of allowed devices and MAC addresses, then moving forward with something like ansible to poll the count of MAC’s on any given port ... of number higher than what’s allowed, suspend the port and send a notification to the appropriate parties. > > > All in all though sounds like a really brash thing to do to your network team and will generally know and have a very good reason for doing so... but not all situations are created equally so good luck. > > > -- > > The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > >> On Jun 7, 2018, at 03:57, segs wrote: >> >> Hello All, >> >> Please I have a very interesting scenario that I am on the lookout for a >> solution for, We have instances where the network team of my company bypass >> controls and processes when adding new switches to the network. >> >> The right parameters that are required to be configured on the switches >> inorder for the NAC solution deployed to have full visibility into end >> points that connects to such switches are not usually configured. >> >> This poses a problem for the security team as they dont have visibility >> into such devices that connect to such switches on the NAC solution, the >> network guys usually connect the new switches to the trunk port and they >> have access to all VLANs. >> >> Is there a solution that can detect new or unmanaged switches on the >> network, and block such devices or if there is a solution that block users >> that connect to unmanaged switches on the network even if those users have >> domain PCs. >> >> Anticipating your speedy response. >> >> Thank You!
Re: Application or Software to detect or Block unmanaged swicthes
as already said - this can be covered with adequate processes and management (even so far as, not doing your job right? time for HR...). however, there are many ways to ensure that random ports arent doing anything other than what they should be doing - most of these are L2 security features - port-security, BPDUGAURD, default vlan pruning, along with other protections such as DHCP snooping etc. however, if its the network team doing this - then they could just turn those things off anyway - so you need to also ensure all managed switch configs have their configs audited and checked - grabbed by SNMP and checked/audited against known template etc etc. if a switch cannot be audited then disconnect its uplink. but then your end users/customers no longer have connections - which is why its really down to management processes. WHY are they doing this? there could be other reasons why due process isnt being followed other than eg incompetence, malice, laziness etc alan
RE: Application or Software to detect or Block unmanaged swicthes
Cisco ISE will accomplish this. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of segs Sent: Thursday, June 7, 2018 3:57 AM To: nanog@nanog.org Subject: Application or Software to detect or Block unmanaged swicthes Hello All, Please I have a very interesting scenario that I am on the lookout for a solution for, We have instances where the network team of my company bypass controls and processes when adding new switches to the network. The right parameters that are required to be configured on the switches inorder for the NAC solution deployed to have full visibility into end points that connects to such switches are not usually configured. This poses a problem for the security team as they dont have visibility into such devices that connect to such switches on the NAC solution, the network guys usually connect the new switches to the trunk port and they have access to all VLANs. Is there a solution that can detect new or unmanaged switches on the network, and block such devices or if there is a solution that block users that connect to unmanaged switches on the network even if those users have domain PCs. Anticipating your speedy response. Thank You!
Re: Application or Software to detect or Block unmanaged swicthes
Enterprise WiFi systems, such as those by HPE (Aruba) and Cisco, have built-in rogue detection including integrated spectrum analysis. Every AP becomes a spectrum analyzer, so the WiFi controller can detect rogue APs, identify whether or not they’re physically connected to your network, and then even tell you the switch and port they’re plugged into. You can disable that port to kill the rogue’s network access, then follow that cable to the interloper. We use a 2’ pipe wrench for enforcement :) -mel > On Jun 8, 2018, at 11:14 AM, Eric Kuhnke wrote: > > This is one of the reasons why large organizations, such as the ones you > describe, have both portable spectrum analyzers (covering the 2400 range > and 5150-5850 MHz 802.11(whatever) bands), and also ability to hunt for MAC > addresses of wifi devices that don't match known centrally managed APs. > Even if somebody sets up to not broadcast the SSID, the MAC will still be > there and can be recognized as an unknown device, then physically > triangulated upon for its OSI layer 1 location, with RSSI/RSL level and a > portable spectrum analyzer with directional yagi antenna. > > > > On Fri, Jun 8, 2018 at 10:32 AM, David Hubbard < > dhubb...@dino.hostasaurus.com> wrote: > >> This thread has piqued my curiosity on whether there'd be a way to detect >> a rogue access point, or proxy server with an inside and outside >> interface? Let's just say 802.1x is in place too to make it more >> interesting. For example, could employee X, who doesn't want their >> department to be back billed for more switch ports, go and get some >> reasonable wifi router, throw DD-WRT on it, and set up 802.1x client auth >> to the physical network using their credentials? They then let their staff >> wifi into it and the traffic is NAT'd. I'm sure anyone in a university >> setting has encountered this. Obviously policy can forbid, but any way to >> detect it other than seeing traffic patterns on a port not match historical >> once the other users have been combined onto it, or those other users' >> ports go down? >> >> David >> >> >> On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" < >> nanog-boun...@nanog.org on behalf of m...@beckman.org> wrote: >> >>When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, >> which has a Layer-2 collection feature that identifies the number and MACs >> of devices on any given switch port. We export this list and cull out all >> the known managed switch links. Anything remaining that has more than one >> MAC per port is a potential violation that we can readily inspect. It’s not >> perfect, because an unmanaged switch might only have one device connected, >> in which case it wont be detected. You can also get false positives from >> hosts running virtualization, if the v-kernel generates synthetic MAC >> addresses. But it’s amazing how many times we find unmanaged switches >> squirreled away under desks or in ceilings. >> >> -mel >> >>> On Jun 7, 2018, at 4:54 AM, Jason Hellenthal >> wrote: >>> >>> As someone already stated the obvious answers, the slightly more >> difficult route to be getting a count of allowed devices and MAC addresses, >> then moving forward with something like ansible to poll the count of MAC’s >> on any given port ... of number higher than what’s allowed, suspend the >> port and send a notification to the appropriate parties. >>> >>> >>> All in all though sounds like a really brash thing to do to your >> network team and will generally know and have a very good reason for doing >> so... but not all situations are created equally so good luck. >>> >>> >>> -- >>> >>> The fact that there's a highway to Hell but only a stairway to >> Heaven says a lot about anticipated traffic volume. >>> On Jun 7, 2018, at 03:57, segs >> wrote: Hello All, Please I have a very interesting scenario that I am on the lookout >> for a solution for, We have instances where the network team of my >> company bypass controls and processes when adding new switches to the network. The right parameters that are required to be configured on the >> switches inorder for the NAC solution deployed to have full visibility into >> end points that connects to such switches are not usually configured. This poses a problem for the security team as they dont have >> visibility into such devices that connect to such switches on the NAC >> solution, the network guys usually connect the new switches to the trunk port and >> they have access to all VLANs. Is there a solution that can detect new or unmanaged switches on the network, and block such devices or if there is a solution that >> block users that connect to unmanaged switches on the network even if those >> users have domain PCs. Anticipating your speedy response. Thank You! >> >> >>
Re: Application or Software to detect or Block unmanaged swicthes
There are a few options. 1. Most likely it will leak information (STUN, NAT-PMP, etc.). 2. You could look obvious signs of NATted traffic. (e.g. re-use of the same source port number to different destinations from the box, etc.) 3. You can look at the TTL or Hop-Count on packets coming out of the box. Most NAT routers (I believe DD-WRT included, IIRC) do still decrement the TTL/Hop-Count (v4/v6) when passing the packet. 4. NMAP the device… DD-WRT will usually look strikingly different from most desktop hosts. I’m sure there are other ways, but those are the first 4 that spring to mind. Each could be defeated by a particularly careful/clever implementer, but in an enterprise, usually it makes little sense to go to that much trouble to violate policy. Universities are an exception as that’s a whole different set of equations on risk/benefit. Owen > On Jun 8, 2018, at 10:32 , David Hubbard > wrote: > > This thread has piqued my curiosity on whether there'd be a way to detect a > rogue access point, or proxy server with an inside and outside interface? > Let's just say 802.1x is in place too to make it more interesting. For > example, could employee X, who doesn't want their department to be back > billed for more switch ports, go and get some reasonable wifi router, throw > DD-WRT on it, and set up 802.1x client auth to the physical network using > their credentials? They then let their staff wifi into it and the traffic is > NAT'd. I'm sure anyone in a university setting has encountered this. > Obviously policy can forbid, but any way to detect it other than seeing > traffic patterns on a port not match historical once the other users have > been combined onto it, or those other users' ports go down? > > David > > > On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" > wrote: > >When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, which > has a Layer-2 collection feature that identifies the number and MACs of > devices on any given switch port. We export this list and cull out all the > known managed switch links. Anything remaining that has more than one MAC per > port is a potential violation that we can readily inspect. It’s not perfect, > because an unmanaged switch might only have one device connected, in which > case it wont be detected. You can also get false positives from hosts running > virtualization, if the v-kernel generates synthetic MAC addresses. But it’s > amazing how many times we find unmanaged switches squirreled away under desks > or in ceilings. > > -mel > >> On Jun 7, 2018, at 4:54 AM, Jason Hellenthal wrote: >> >> As someone already stated the obvious answers, the slightly more difficult >> route to be getting a count of allowed devices and MAC addresses, then >> moving forward with something like ansible to poll the count of MAC’s on any >> given port ... of number higher than what’s allowed, suspend the port and >> send a notification to the appropriate parties. >> >> >> All in all though sounds like a really brash thing to do to your network >> team and will generally know and have a very good reason for doing so... but >> not all situations are created equally so good luck. >> >> >> -- >> >> The fact that there's a highway to Hell but only a stairway to Heaven says a >> lot about anticipated traffic volume. >> >>> On Jun 7, 2018, at 03:57, segs wrote: >>> >>> Hello All, >>> >>> Please I have a very interesting scenario that I am on the lookout for a >>> solution for, We have instances where the network team of my company bypass >>> controls and processes when adding new switches to the network. >>> >>> The right parameters that are required to be configured on the switches >>> inorder for the NAC solution deployed to have full visibility into end >>> points that connects to such switches are not usually configured. >>> >>> This poses a problem for the security team as they dont have visibility >>> into such devices that connect to such switches on the NAC solution, the >>> network guys usually connect the new switches to the trunk port and they >>> have access to all VLANs. >>> >>> Is there a solution that can detect new or unmanaged switches on the >>> network, and block such devices or if there is a solution that block users >>> that connect to unmanaged switches on the network even if those users have >>> domain PCs. >>> >>> Anticipating your speedy response. >>> >>> Thank You! > >
Re: Application or Software to detect or Block unmanaged swicthes
This is one of the reasons why large organizations, such as the ones you describe, have both portable spectrum analyzers (covering the 2400 range and 5150-5850 MHz 802.11(whatever) bands), and also ability to hunt for MAC addresses of wifi devices that don't match known centrally managed APs. Even if somebody sets up to not broadcast the SSID, the MAC will still be there and can be recognized as an unknown device, then physically triangulated upon for its OSI layer 1 location, with RSSI/RSL level and a portable spectrum analyzer with directional yagi antenna. On Fri, Jun 8, 2018 at 10:32 AM, David Hubbard < dhubb...@dino.hostasaurus.com> wrote: > This thread has piqued my curiosity on whether there'd be a way to detect > a rogue access point, or proxy server with an inside and outside > interface? Let's just say 802.1x is in place too to make it more > interesting. For example, could employee X, who doesn't want their > department to be back billed for more switch ports, go and get some > reasonable wifi router, throw DD-WRT on it, and set up 802.1x client auth > to the physical network using their credentials? They then let their staff > wifi into it and the traffic is NAT'd. I'm sure anyone in a university > setting has encountered this. Obviously policy can forbid, but any way to > detect it other than seeing traffic patterns on a port not match historical > once the other users have been combined onto it, or those other users' > ports go down? > > David > > > On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" < > nanog-boun...@nanog.org on behalf of m...@beckman.org> wrote: > > When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, > which has a Layer-2 collection feature that identifies the number and MACs > of devices on any given switch port. We export this list and cull out all > the known managed switch links. Anything remaining that has more than one > MAC per port is a potential violation that we can readily inspect. It’s not > perfect, because an unmanaged switch might only have one device connected, > in which case it wont be detected. You can also get false positives from > hosts running virtualization, if the v-kernel generates synthetic MAC > addresses. But it’s amazing how many times we find unmanaged switches > squirreled away under desks or in ceilings. > > -mel > > > On Jun 7, 2018, at 4:54 AM, Jason Hellenthal > wrote: > > > > As someone already stated the obvious answers, the slightly more > difficult route to be getting a count of allowed devices and MAC addresses, > then moving forward with something like ansible to poll the count of MAC’s > on any given port ... of number higher than what’s allowed, suspend the > port and send a notification to the appropriate parties. > > > > > > All in all though sounds like a really brash thing to do to your > network team and will generally know and have a very good reason for doing > so... but not all situations are created equally so good luck. > > > > > > -- > > > > The fact that there's a highway to Hell but only a stairway to > Heaven says a lot about anticipated traffic volume. > > > >> On Jun 7, 2018, at 03:57, segs > wrote: > >> > >> Hello All, > >> > >> Please I have a very interesting scenario that I am on the lookout > for a > >> solution for, We have instances where the network team of my > company bypass > >> controls and processes when adding new switches to the network. > >> > >> The right parameters that are required to be configured on the > switches > >> inorder for the NAC solution deployed to have full visibility into > end > >> points that connects to such switches are not usually configured. > >> > >> This poses a problem for the security team as they dont have > visibility > >> into such devices that connect to such switches on the NAC > solution, the > >> network guys usually connect the new switches to the trunk port and > they > >> have access to all VLANs. > >> > >> Is there a solution that can detect new or unmanaged switches on the > >> network, and block such devices or if there is a solution that > block users > >> that connect to unmanaged switches on the network even if those > users have > >> domain PCs. > >> > >> Anticipating your speedy response. > >> > >> Thank You! > > >
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Jun, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 703944 Prefixes after maximum aggregation (per Origin AS): 270298 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 337366 Total ASes present in the Internet Routing Table: 60965 Prefixes per ASN: 11.55 Origin-only ASes present in the Internet Routing Table: 52613 Origin ASes announcing only one prefix: 22991 Transit ASes present in the Internet Routing Table:8352 Transit-only ASes present in the Internet Routing Table:280 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 30 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table:73 Number of instances of unregistered ASNs:73 Number of 32-bit ASNs allocated by the RIRs: 22870 Number of 32-bit ASNs visible in the Routing Table: 18455 Prefixes from 32-bit ASNs in the Routing Table: 76985 Number of bogon 32-bit ASNs visible in the Routing Table:17 Special use prefixes present in the Routing Table:2 Prefixes being announced from unallocated address space:254 Number of addresses announced to Internet: 2858854723 Equivalent to 170 /8s, 102 /16s and 169 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 235189 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 192144 Total APNIC prefixes after maximum aggregation: 54502 APNIC Deaggregation factor:3.53 Prefixes being announced from the APNIC address blocks: 190877 Unique aggregates announced from the APNIC address blocks:77709 APNIC Region origin ASes present in the Internet Routing Table:8863 APNIC Prefixes per ASN: 21.54 APNIC Region origin ASes announcing only one prefix: 2487 APNIC Region transit ASes present in the Internet Routing Table: 1340 Average APNIC Region AS path length visible:4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3835 Number of APNIC addresses announced to Internet: 767495938 Equivalent to 45 /8s, 191 /16s and 15 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:209136 Total ARIN prefixes after maximum aggregation:99495 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 209874 Unique aggregates announced from the ARIN address blocks: 99071 ARIN Region origin ASes present in the Internet Routing Table:18200 ARIN Prefixes per ASN:11.53
Re: Application or Software to detect or Block unmanaged swicthes
This thread has piqued my curiosity on whether there'd be a way to detect a rogue access point, or proxy server with an inside and outside interface? Let's just say 802.1x is in place too to make it more interesting. For example, could employee X, who doesn't want their department to be back billed for more switch ports, go and get some reasonable wifi router, throw DD-WRT on it, and set up 802.1x client auth to the physical network using their credentials? They then let their staff wifi into it and the traffic is NAT'd. I'm sure anyone in a university setting has encountered this. Obviously policy can forbid, but any way to detect it other than seeing traffic patterns on a port not match historical once the other users have been combined onto it, or those other users' ports go down? David On 6/7/18, 10:18 AM, "NANOG on behalf of Mel Beckman" wrote: When we do NIST-CSF audits, we run an SNMP NMS called Intermapper, which has a Layer-2 collection feature that identifies the number and MACs of devices on any given switch port. We export this list and cull out all the known managed switch links. Anything remaining that has more than one MAC per port is a potential violation that we can readily inspect. It’s not perfect, because an unmanaged switch might only have one device connected, in which case it wont be detected. You can also get false positives from hosts running virtualization, if the v-kernel generates synthetic MAC addresses. But it’s amazing how many times we find unmanaged switches squirreled away under desks or in ceilings. -mel > On Jun 7, 2018, at 4:54 AM, Jason Hellenthal wrote: > > As someone already stated the obvious answers, the slightly more difficult route to be getting a count of allowed devices and MAC addresses, then moving forward with something like ansible to poll the count of MAC’s on any given port ... of number higher than what’s allowed, suspend the port and send a notification to the appropriate parties. > > > All in all though sounds like a really brash thing to do to your network team and will generally know and have a very good reason for doing so... but not all situations are created equally so good luck. > > > -- > > The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > >> On Jun 7, 2018, at 03:57, segs wrote: >> >> Hello All, >> >> Please I have a very interesting scenario that I am on the lookout for a >> solution for, We have instances where the network team of my company bypass >> controls and processes when adding new switches to the network. >> >> The right parameters that are required to be configured on the switches >> inorder for the NAC solution deployed to have full visibility into end >> points that connects to such switches are not usually configured. >> >> This poses a problem for the security team as they dont have visibility >> into such devices that connect to such switches on the NAC solution, the >> network guys usually connect the new switches to the trunk port and they >> have access to all VLANs. >> >> Is there a solution that can detect new or unmanaged switches on the >> network, and block such devices or if there is a solution that block users >> that connect to unmanaged switches on the network even if those users have >> domain PCs. >> >> Anticipating your speedy response. >> >> Thank You!
Re: Application or Software to detect or Block unmanaged swicthes
I guess you can do that and more with a linux based switch like cumulus and pica8. They allow you to do all sorts of things like that because they are open. On Thursday, June 7, 2018, wrote: > In my previous life, we used a nac appliance from Bradford Networks > whereby the mac address of every device needed to be registered or the > switch port it was plugged into would be disabled. > This kept spurious devices from appearing on the network and worked quite > well. > Cheers, Keith > > Sent from my android device. > > -Original Message- > From: Jason Hellenthal > To: segs > Cc: nanog@nanog.org > Sent: Thu, 07 Jun 2018 7:54 > Subject: Re: Application or Software to detect or Block unmanaged swicthes > > As someone already stated the obvious answers, the slightly more difficult > route to be getting a count of allowed devices and MAC addresses, then > moving forward with something like ansible to poll the count of MAC’s on > any given port ... of number higher than what’s allowed, suspend the port > and send a notification to the appropriate parties. > > > All in all though sounds like a really brash thing to do to your network > team and will generally know and have a very good reason for doing so... > but not all situations are created equally so good luck. > > > -- > > The fact that there's a highway to Hell but only a stairway to Heaven says > a lot about anticipated traffic volume. > > > On Jun 7, 2018, at 03:57, segs wrote: > > > > Hello All, > > > > Please I have a very interesting scenario that I am on the lookout for a > > solution for, We have instances where the network team of my company > bypass > > controls and processes when adding new switches to the network. > > > > The right parameters that are required to be configured on the switches > > inorder for the NAC solution deployed to have full visibility into end > > points that connects to such switches are not usually configured. > > > > This poses a problem for the security team as they dont have visibility > > into such devices that connect to such switches on the NAC solution, the > > network guys usually connect the new switches to the trunk port and they > > have access to all VLANs. > > > > Is there a solution that can detect new or unmanaged switches on the > > network, and block such devices or if there is a solution that block > users > > that connect to unmanaged switches on the network even if those users > have > > domain PCs. > > > > Anticipating your speedy response. > > > > Thank You! >
Spoofer Report for NANOG for May 2018
In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during May 2018: ASN Name Fixed-By 11232 MIDCO-NET 2018-05-14 11796 AIRSTREAMCOMM-NET 2018-05-22 577 BACOM 2018-05-25 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during May 2018: ASN Name First-Spoofed Last-Spoofed 3356 LEVEL32016-03-06 2018-05-15 577 BACOM 2016-03-09 2018-05-17 7922 COMCAST-7922 2016-06-04 2018-05-14 7029 WINDSTREAM2016-06-21 2018-05-09 2828 XO-AS15 2016-07-27 2018-05-30 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-05-31 6128 CABLE-NET-1 2016-09-03 2018-05-26 20412 CLARITY-TELECOM 2016-09-30 2018-05-30 20001 ROADRUNNER-WEST 2016-10-08 2018-05-09 6181 FUSE-NET 2016-10-10 2018-05-31 15305 SYRINGANETWORKS 2016-10-21 2018-05-16 25787 ROWE-NETWORKS 2016-10-21 2018-05-28 11427 SCRR-114272016-10-21 2018-05-19 174 COGENT-1742016-10-21 2018-05-29 271 BCNET 2016-10-24 2018-05-30 20082 ABSNOC1 2016-10-27 2018-05-02 32440 LONI 2016-11-03 2018-05-31 33182 DimeNOC 2016-11-08 2018-05-30 12083 WOW-INTERNET 2016-11-09 2018-05-31 5056 AUREON-5056 2016-11-10 2018-05-30 1403 EBOX 2016-11-12 2018-05-26 20105 URICHMOND 2016-11-15 2018-05-29 54858 AS-SBI2016-12-25 2018-05-23 2152 CSUNET-NW 2017-02-02 2018-05-31 21832 KELLINCOM-1 2017-02-03 2018-05-30 18451 LESNET2017-02-22 2018-05-03 7122 MTS-ASN 2017-05-16 2018-05-19 6461 ZAYO-6461 2017-06-21 2018-05-16 26253 SCINTERNET2017-06-30 2018-05-31 26793 ICS-LLC 2017-08-16 2018-05-03 63296 AMARILLO-WIRELESS 2017-09-01 2018-05-30 7233 YAHOO-US 2017-09-07 2018-05-31 33523 ROWANUNIVERSITY 2017-10-29 2018-05-12 546 PARSONS-PGS-1 2017-11-20 2018-05-07 54540 INCERO2018-01-15 2018-05-30 1 AKAMAI2018-02-14 2018-05-28 55236 CBC 2018-03-03 2018-05-24 3257 GTT-BACKBONE 2018-03-06 2018-05-28 29384 Qatar-Foundation 2018-03-08 2018-05-28 23148 TERRENAP 2018-03-15 2018-05-30 226 LOS-NETTOS2018-03-26 2018-05-29 15176 AS-INOC 2018-04-09 2018-05-16 20009 WADSNET 2018-04-13 2018-05-30 4201 ORST 2018-04-19 2018-05-30 11827 WSU 2018-04-19 2018-05-31 31863 DACEN-2 2018-04-26 2018-05-04 15301 IOVATION 2018-05-02 2018-05-03 19016 WCG 2018-05-19 2018-05-19 122 U-PGH-NET 2018-05-19 2018-05-19 21949 BEANFIELD 2018-05-21 2018-05-21 40764 DNA-DKLB 2018-05-29 2018-05-29 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can_block=1 Please send any feedback or suggestions to spoofer-i...@caida.org
