One thing that has bothered me about MR deployment for a while is when you first add an MR to a network it creates a default SSID with open authentication (no encryption) and "Allow local LAN access" enabled.
So this means if you just plug in a MR, anyone connect connect to your network.
I also don't like how you can't disable all the SSIDs. You must have at least one enabled.
This really needs to be changed so it is "secure by default". Ideally all SSIDs should be disabled, or some kind of WPA2 key needs to be assigned. Anything to prevent randoms attaching to the new network.
It is just not right allowing anyone to connect to a new network.
I've considered filing a Cisco PSIRT over this several times. Maybe I should just stop thinking about it and do something - alas someone from Meraki can do something about this.
you are right, @PhilipDAth! @meraki: please also note, that many of us have to apply to the rules of the GDPR by 2018-05-25. as IP-addresses are considered as personal data, connecting a new MR-device - for now - exposes those to anyone in the wifi-range of the MR. so this is not yet compliant to to the following article:
Article 25
Data protection by design and by default
1. Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons.
3. An approved certification mechanism pursuant to Article 42 may be used as an element to demonstrate compliance with the requirements set out in paragraphs 1 and 2 of this Article.
Whereas:
(78) | The protection of the rights and freedoms of natural persons with regard to the processing of personal data require that appropriate technical and organisational measures be taken to ensure that the requirements of this Regulation are met. In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default. Such measures could consist, inter alia, of minimising the processing of personal data, pseudonymising personal data as soon as possible, transparency with regard to the functions and processing of personal data, enabling the data subject to monitor the data processing, enabling the controller to create and improve security features. When developing, designing, selecting and using applications, services and products that are based on the processing of personal data or process personal data to fulfil their task, producers of the products, services and applications should be encouraged to take into account the right to data protection when developing and designing such products, services and applications and, with due regard to the state of the art, to make sure that controllers and processors are able to fulfil their data protection obligations. The principles of data protection by design and by default should also be taken into consideration in the context of public tenders. |
thanks for reading and taking a note. should be very simple to implement.
you are right, @PhilipDAth! @meraki: please also note, that many of us have to apply to the rules of the GDPR by 2018-05-25. as IP-addresses are considered as personal data, connecting a new MR-device - for now - exposes those to anyone in the wifi range of the MR. so this is not yet compliant to to the following art
Article 25
Data protection by design and by default
1. Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons.
3. An approved certification mechanism pursuant to Article 42 may be used as an element to demonstrate compliance with the requirements set out in paragraphs 1 and 2 of this Article.
Whereas (78):
The protection of the rights and freedoms of natural persons with regard to the processing of personal data require that appropriate technical and organisational measures be taken to ensure that the requirements of this Regulation are met. In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default. Such measures could consist, inter alia, of minimising the processing of personal data, pseudonymising personal data as soon as possible, transparency with regard to the functions and processing of personal data, enabling the data subject to monitor the data processing, enabling the controller to create and improve security features. When developing, designing, selecting and using applications, services and products that are based on the processing of personal data or process personal data to fulfil their task, producers of the products, servicesand and applications should be encouraged to take into account the right to data protection when developing and designing such products, services and applications and, with due regard to the state of the art, to make sure that controllers and processors are able to fulfil their data protection obligations. The principles of data protection by design and by default should also be taken into consideration in the context of public tenders.
thanks for reading and taking a note. should be very simple to implement.
Agreed, we live in an age where network security requirements are increasing every day yet this "default" seems silly if I'm honest. I would rather no default SSID.
Also if you were doing a full rebuild of a wireless deployment you would possible want to be able to delete every SSID so you can start from scratch.
This should be simple to implement so @meraki_ team how do we push to make this happen, a security flaw like this shouldn't require as all having to make a wish.
Life would be much simpler if we could set up a VLAN as an Isolated VLAN (remember PVLAN options?).
The isolated port on a switch is not very helpful in real world SME/SOHO installations.
So by default the Guest Network is on an isolated VLAN. So no access to the local network, other VLANs or other users on the same VLAN.
If guests need to print documents, then set up a printer that prints what is emailed to it, and put the printer in a secure location so that users have to ask for their print outs.
At present moving the default Guest SSID to a VLAN seems to break the isolated attribute of the VLAN . . . and the documentation appears to be out of step with the software.
@Uberseehandel wrote:Life would be much simpler if we could set up a VLAN as an Isolated VLAN (remember PVLAN options?).
@Uberseehandel: you may want to use the new "Layer 2 LAN isolation" feature under Wireless / "Firewall & traffic shaping". i use that successfully from through a segregated VLAN. https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/Wireless_Client_Isolation
it is available since firmware 25.8. 25.9 (current) fixed the issue with the splash pages.
@nikiwaibel wrote:@Uberseehandel: you may want to use the new "Layer 2 LAN isolation" feature under Wireless / "Firewall & traffic shaping". i use that successfully from through a segregated VLAN. https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/Wireless_Client_Isolation
it is available since firmware 25.8. 25.9 (current) fixed the issue with the splash pages.
Yes, I've been using that, but one had to work at it. It involved several different pages to set it up. This should all be set up on the same page. That is the logical approach.
It should be something along the lines of:
I have now created a formal Cisco PSIRT notification about this security issue. Lets see if anything happens.
Perhaps all these issues will be addressed in the MXX Evoluzione model (as they would put it in Modena). The list of issues to be addressed feels as if it is getting longer not shorter at the moment.
Well my PSIRPT finally got a response. Not what I would call satisfactory.
"Thank you very much for your patience.
We have completed our discussions with the Meraki team and have agreed to:
1. Keep the default open SSID for ease of installation.
2. Clearly document the default open SSID.
3. Disable local LAN access for that default SSID.
That concludes the PSIRT investigation for this issue."
They shouldn't complain if they get described as limp wristed.
This is hilarious. Cisco APs out of the box have radios disabled, Meraki radios are enabled!
Can't stress this enough, need a way to disable Meraki radios/all SSIDs...plain and simple.