Howto configure a TG588 from A1 Telekom as VDSL modem and a Mikrotik device as router
September 11, 2015
Our big nation provider A1 Telekom went ahead and provided our house as first provider with VDSL – hoped FTTH makes the race … but anyway VDSL is better than the old stuff I had before. So I went ahead and ordered it and I got send an TG588 modem/router where you can almost configure nothing. e.g. UPNP is enabled and you can’t even deactivate it – when was it a good idea that a clients tells a firewall what to do in the first place? So I had to 3 options
- Buy a VDSL router like FRITZ!Box 3390, which is also a home router where I don’t like the configuration methods and feature set
- Buy a VDSL modem/bridge like Vigor130, and connect via a real router over pppoe. But the system is not on the A1 Telekom vectoring devices whitelist. No change for vectoring than ….
- Get the TG588 to play only modem and let my real router to do pppoe tunnel.
As you most likely already guested I opt for the last one. This howto shows you how to configure the TG588 as modem and an Mikrotik router as router (could be any other devices that supports pppoe in client mode). I was not that easy to gather all this information and so it maybe helps others to save time.
First lets connect the TG588 to the telephone line and the Mikrotik with one interface (in my case ether0) to it. Let everything boot up and connect your PC to the Mikrotik clients ports (in the default config). Log into the Mikrotik and configure the interface to the modem like this:
/interface ethernet set [ find default-name=ether1 ] name=ether1vlanTransitModem
/ip address add address=10.0.0.1/24 interface=ether1vlanTransitModem network=10.0.0.0
/ip firewall nat add action=masquerade chain=srcnat comment="nat the traffic to the dsl modem web interface, only activate when needed" out-interface=ether1vlanTransitModem
This gives the interface a nice name, sets the IP address of that uplink interface and configures the router to perform an source NAT, so you’re able to configure the modem even if you’re behind the Mikrotik router.Make sure that there is not DHCP Client running on the Mikrotik (specially on the ether0 interface)
Now log into your TG588 by going to http://10.0.0.138
. Your default user has not the rights to change anything – so we need to change to an other default created user, with higher privileges. Click on the “admin” username:
Choose “change to other user”:
Provide following user data (worked at the time of writing, may got changed)
User: Telek0m
Password: Austria!Eur0
Now your user should have changed to following:
After that you will have more options to select from. Click onto “A1 WLAN Box” followed by “Configuration” and then choose “reconfigure A1 WLAN Box”
On the following page you need to select “single user” mode and click on reconfigure
Now you’re done with the TG588 – after rebooting it should be fine. Now you need only following two pages on the TG588 – the rest is done by the Mikrotik router
First the event log, here you can check if something does not work:
And following page shows you the speed you’re connected with the provider network
The easy part
Now after all that clicking the Mikrotik part is easy:
/interface pppoe-client add add-default-route=yes disabled=no interface=ether1vlanTransitModem max-mru=1492 max-mtu=1492 mrru=disabled name=pppoeDslInternet password=XXXXXXXX use-peer-dns=no/yes user=XXXXXX
Replace XXXX
with the data you got from A1 Telekom.
Now you’re internet connection should be up … test it with
ping 8.8.8.8
after that we only need some Firewall rules move the client traffic correctly to and from the Internet.
/ip firewall mangle add action=change-mss chain=forward comment="max MTU size for pppoe 1492" new-mss=1452 out-interface=pppoeDslInternet protocol=tcp tcp-flags=syn tcp-mss=!0-1452
/ip firewall nat add action=masquerade chain=srcnat comment="nat all traffic which goes over dsl into the internet" out-interface=pppoeDslInternet
Now you’re done. Hope this helped.
My heart misgives me, if I think about them implementing smart meters
July 30, 2015
Update: The site is used by TINETZ but not operated by it – so their IT department is not responsible. The Whois entries shows this also.
I got today a letter that requests me to enter my electric meter counter reading into the web website of the electric supply company. After getting a warning in my browser I checked the site – and oh my god … they can’t even implement TLS correctly and they want to deploy smart meters with a remote kill switch? Opt-Out if you can 😉
ps: I heard they are ISO 27001 certified – guess not for the website. 😉
Beware: Extreme Networks EXOS ships with hidden SNMPv3 default admin user
July 28, 2015
Update:
Jan reported in the comments that the problem exists also with SNMPv2 – and that’s correct – Just didn’t see that as we’re using only SNMPv3
show configuration "snmp" detail
shows following
configure snmpv3 add community private name private user v1v2c_rw
configure snmpv3 add community public name public user v1v2c_ro
You need to delete that with:
configure snmpv3 del community private
configure snmpv3 del community public
Original article:
A college of mine just found something by performing security hardening on our Extreme Network switches (Thx for this!). We’ve moved away from SNMPv2 sometime ago and are using only SNMPv3. So as we did
disable snmp access snmp-v1v2c
and configured our own SNMPv3 users and we thoughed we’re safe. But that is not true even if typing
show configuration "snmp"
shows only your own users. Typing
show configuration "snmp" detail
(detail = display all configuration data including default, otherwise default would not be displayed)
shows following
configure snmpv3 engine-id xxxxx
configure snmpv3 add user admin authentication md5 auth-encrypted hex 35:dc:03:fb:58:13:d3:54:92:0e:1d:fd:ab:3f:b5:9a privacy privacy-encrypted hex 35:dc:03:fb:58:13:d3:54:92:0e:1d:fd:ab:3f:b5:9a
configure snmpv3 add user initial
configure snmpv3 add user initialmd5 authentication md5 auth-encrypted hex 72:e7:51:a0:6b:37:81:a1:26:a5:f0:a1:b8:25:e6:b6
configure snmpv3 add user initialsha authentication sha auth-encrypted hex e9:9d:30:c1:6a:bf:21:45:7e:20:e4:ff:14:2e:28:5f:9c:2e:f3:30
configure snmpv3 add user initialmd5Priv authentication md5 auth-encrypted hex d1:67:eb:88:85:19:4d:7b:c7:09:a4:d4:d5:ba:21:eb privacy privacy-encrypted hex d1:67:eb:88:85:19:4d:7b:c7:09:a4:d4:d5:ba:21:eb
configure snmpv3 add user initialshaPriv authentication sha auth-encrypted hex 34:1d:66:c1:a2:ba:4d:26:8a:da:f5:f6:00:2a:e6:04:88:47:f0:4c privacy privacy-encrypted hex 34:1d:66:c1:a2:ba:4d:26:8a:da:f5:f6:00:2a:e6:04:88:47:f0:4c
configure snmpv3 add group v1v2c_ro user v1v2c_ro sec-model snmpv1
configure snmpv3 add group v1v2c_rw user v1v2c_rw sec-model snmpv1
configure snmpv3 add group v1v2c_ro user v1v2c_ro sec-model snmpv2c
configure snmpv3 add group v1v2c_rw user v1v2c_rw sec-model snmpv2c
configure snmpv3 add group v1v2cNotifyGroup user v1v2cNotifyUser1 sec-model snmpv2c
configure snmpv3 add group v1v2cNotifyGroup user v1v2cNotifyUser2 sec-model snmpv2c
configure snmpv3 add group admin user admin sec-model usm
configure snmpv3 add group initial user initial sec-model usm
configure snmpv3 add group initial user initialmd5 sec-model usm
configure snmpv3 add group initial user initialsha sec-model usm
configure snmpv3 add group initial user initialmd5Priv sec-model usm
configure snmpv3 add group initial user initialshaPriv sec-model usm
configure snmpv3 add access admin sec-model usm sec-level priv read-view defaultAdminView write-view defaultAdminView notify-view defaultNotifyView
configure snmpv3 add access initial sec-model usm sec-level noauth read-view defaultUserView notify-view defaultNotifyView
configure snmpv3 add access initial sec-model usm sec-level authnopriv read-view defaultUserView write-view defaultUserView notify-view defaultNotifyView
configure snmpv3 add access v1v2c_ro sec-model snmpv1 sec-level noauth read-view defaultUserView notify-view defaultNotifyView
configure snmpv3 add access v1v2c_ro sec-model snmpv2c sec-level noauth read-view defaultUserView notify-view defaultNotifyView
configure snmpv3 add access v1v2c_rw sec-model snmpv1 sec-level noauth read-view defaultUserView write-view defaultUserView notify-view defaultNotifyView
configure snmpv3 add access v1v2c_rw sec-model snmpv2c sec-level noauth read-view defaultUserView write-view defaultUserView notify-view defaultNotifyView
configure snmpv3 add access snmpv3group sec-model usm sec-level priv read-view defaultAdminView write-view None notify-view None
configure snmpv3 add access v1v2cNotifyGroup sec-model snmpv1 sec-level noauth notify-view defaultNotifyView
configure snmpv3 add access v1v2cNotifyGroup sec-model snmpv2c sec-level noauth notify-view defaultNotifyView
....
enable snmp access
disable snmp access snmp-v1v2c
enable snmp access snmpv3
enable snmpv3 default-group
enable snmpv3 default-user
enable snmp traps
configure snmp compatibility ip-fragmentation disallow
enable snmp access vr VR-Default
enable snmp access vr VR-Mgmt
Oh my god what are these users? A check into the manual (one of 1732 pages) shows following:
Yes, these are all default users, with published passwords – and sure it works as following shows:
$ snmpwalk -u admin -A password -a MD5 -X password -x DES -l authPriv switchIpAddress -v3
iso.3.6.1.2.1.1.1.0 = STRING: "ExtremeXOS (X450e-48p) version 15.3.4.6 v1534b6-patch1-8 by release-manager on Thu Oct 30 13:07:09 EDT 2014"
iso.3.6.1.2.1.1.2.0 = OID: iso.xxxxxxxxxxxxxx
.....
I really don’t know what the engineers smoked when they put default SNMPv3 users into the switch configuration! Whats the purpose? And then hiding them from show configuration
! What do you need to do to fix this?
disable snmpv3 default-group
disable snmpv3 default-user
Now you get:
$ snmpwalk -u admin -A password -a MD5 -X password -x DES -l authPriv switchIpAddress -v3
Error in packet.
Reason: authorizationError (access denied to that object)
If you delete the users additionally with following commands:
configure snmpv3 delete user admin
configure snmpv3 delete user initial
configure snmpv3 delete user initialmd5
configure snmpv3 delete user initialsha
configure snmpv3 delete user initialmd5Priv
configure snmpv3 delete user initialshaPriv
You’ll get:
$ snmpwalk -u admin -A password -a MD5 -X password -x DES -l authPriv switchIpAddress -v3
snmpwalk: Unknown user name
I recommend deleting every configuration line (be it user or group) you don’t need. Only 2 lines protect you otherwise from a completely open switch …. some firmware did make the switch to forget a config line (e.g. when the syntax changed) … so lets be more save by also removing the users.
Looking for a way to change an email address and found clear text admin password
July 9, 2015
Today I wanted to change the email address of my admin User in the Unifi management software. As I couldn’t find anything in the GUI I started to look into the mongodb, which I’m already familiar with as I needed it for the last fix described here. So the part of changing the email was quite simple .. I just did that:
# /usr/bin/mongo --port 27117
MongoDB shell version: 2.6.10
connecting to: 127.0.0.1:27117/test
> use ace
switched to db ace
> db.admin.find()
{ "_id" : ObjectId("YYYYYYYYYYYYY"), "name" : "admin", "lang" : "en_US", "x_password" : "XXXXXXXXX", "email_alert_enabled" : true, "email" : "[email protected]" }
> db.admin.update({"_id" : ObjectId("YYYYYYYYYYYYY")}, { $set: {"email" : "[email protected]"}})
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
> db.admin.find()
{ "_id" : ObjectId("YYYYYYYYYYYYY"), "name" : "admin", "lang" : "en_US", "x_password" : "XXXXXXX", "email_alert_enabled" : true, "email" : "[email protected]" }
>
But as you see there is a field x_password with the admin password in the clear. What the heck? Why that, this is only needed for login on, the device password can be set per site. So I searched in the internet that someone else found it – and yes, this was reported to the vendor over a year ago.
Unifi upgrade 2.4.6 to 3.2.10: maps not working
July 8, 2015
So after the migration itself worked and I’ve updated the access points I looked into the problem that my maps did not work anymore. Every map showed only white and I was not able to add new maps. After long googling I found part of the answer here. My solution is a bit different and works on the fly:
- Unifi management needs to be running
- check where your mongod is running … on my system its ports 27117
# netstat -pnl | grep mongod
tcp 0 0 127.0.0.1:27117 0.0.0.0:* LISTEN 16760/bin/mongod - login with
/usr/bin/mongo --port 27117
- and type following
use ace
followed bydb.map.chunks.dropIndex("files_id_1_n_1")
- choose a new map in the drop down box and it should work again
the full communication looks like this:
# /usr/bin/mongo --port 27117
MongoDB shell version: 2.6.10
connecting to: 127.0.0.1:27117/test
> use ace
switched to db ace
> db.map.chunks.dropIndex("files_id_1_n_1")
{ "nIndexesWas" : 2, "ok" : 1 }
>
bye
Unifi upgrade 2.4.6 to 3.2.10: exception: remove needs a query at src/mongo/shell/collection.js
If you try to upgrade Ubiquiti Networks Unifi system from version 2.4.6 to 3.2.10 it is possible that you’ll run into following problem:
Exception in thread "launcher" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'class.super': Instantiation of bean failed; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: Factory method [public final com.ubnt.A.new.B com.ubnt.A.new$$EnhancerByCGLIB$$ad7756e2.class.super()] threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'Ø00000': Invocation of init method failed; nested exception is com.mongodb.CommandResult$CommandFailure: command failed [$eval]: { "serverUsed" : "/127.0.0.1:27117" , "errmsg" : "exception: remove needs a query at src/mongo/shell/collection.js:299" , "code" : 16722 , "ok" : 0.0}
when trying to start it like this
/usr/bin/java -jar /opt/UniFi/lib/ace.jar start
Searching through the Internet shows that more people have the problem but a working solution is not posted anywhere. So here is it:
The reason for the problem is quit easily found here. Basically the syntax of the command is not correct. So I started to search through the lib directory for a file that contains this incorrect string. It is within /opt/UniFi/lib/ace.jar
so I installed the jar command line utility (on Centos 6)
yum install java-1.7.0-openjdk-devel
and extracted all files to search in which it was. As I found it, its easier for you just type:
jar xf ace.jar com/ubnt/A/ooOO/OOoO.class
Now you need a Java class editor – we use this Java one. Download and extract it and start it like this:
java -jar ce.jar
Now you need to find and change the values:
- Click on “Constant Pool”
- Type
db.cache_device.remove
in the search field and find the line 459 - Activate the “Modify Mode” and change the values
In the end it should look like this (the second one is a link to the fist, just update):
Now save the file and update the jar file:
jar uf ace.jar com/ubnt/A/ooOO/OOoO.class
Now a restart and migration should work. Hope this helps others .. it took me one hour to find my solution, so I hope its now faster for you. 😉
Austrian consumer organization Konsument.at slips on web security
June 26, 2015
Today I just surfed on the web site www.konsument.at of the Verein für Konsumenteninformation (VKI), which is a consumer organization in Austria. So you would think that the security of user data (=consumers) is high on their list – but it is not. Just looking at the homepage for 5 minutes shows you that they don’t really care. Lets take a look:
1. Login data not encrypted
On their start page customers of them are able to login:
Ok, the page itself, which shows the login mask, is not HTTPS, thats not good as an attacker can change it. But when you click on the logon button it gets worse.
Yes, it is also not encrypted and surely the login data is in clear text as form data:
So you would think that they just don’t have any HTTPS, but that’s not correct. If you go the create account page you get HTTPS.
And if you look at the form sent button you’ll see:
WTF? That’s the same URL – just different parameter and of course this time with HTTPS. So they just have forgotten that HTTPS the first time?
2 TLS at its worst
After the first fiasco I thought – let’s check the HTTPS config, and it is a F grade (=that is bad).
Everything you possible could forget to secure was forgotten here.
Howto filter rogue DHCP servers on Ubiquiti Networks UniFi access points
June 25, 2015
This short post shows how to filter rogue DHCP servers, which are connected via the WiFi to the network. The UniFi management software allows you to block traffic between 2 clients connected to the same access point. This feature is often called “client isolation”. But for seamless handover to an other access point, all need to be in the same layer 2 network. So an rogue DHCP server can serve clients on an other access point. This setup filters that traffic.
For this you need to put following lines into a file called config.properties (most likely you need to create the file).
config.system_cfg.1=ebtables.1.cmd=-A FORWARD -i ath* --protocol ipv4 --ip-protocol udp --ip-destination-port 68 -j DROP
config.system_cfg.2=ebtables.2.cmd=-A FORWARD -i ath* --protocol ipv4 --ip-protocol udp --ip-source-port 67 -j DROP
config.system_cfg.3=ebtables.3.cmd=-A FORWARD -i eth0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67 -j DROP
The location of the file depends on the version of your UniFi management software.
- Version 2:
/opt/UniFi/data/config.properties
- Version 3+:
/opt/UniFi/data/sites/the_site/config.properties
– to get the site id take a look at this article.
After that change you need to trigger the re-provision on the access points affected. You can do this by enabling and disabling the guest portal(for the entire site) or on a per access point basis, changing TX power one by one, for example.
To verify that the configuration got deployed, log into the access point via ssh and check the ebtables – it should look like this:
BZ.vx.x.x# ebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 3, policy: ACCEPT
-p IPv4 -i ath* --ip-proto udp --ip-dport 68 -j DROP
-p IPv4 -i ath* --ip-proto udp --ip-sport 67 -j DROP
-p IPv4 -i eth0 --ip-proto udp --ip-dport 67 -j DROP
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
Securing your client network 2: Separate by device classes
June 16, 2015
The second article in the securing your client network series (after Enforce DHCP usage) is about separating different client device classes in the network. Typically enterprises separate different departments in separate VLANs. If the VLANs are routed in the same VRF and no ACLs separate them, the gained security is negligible. If you’re configuring ACLs for this, you have too much time on hand or the rules are not tight. And the setup works only good if you’re within one central office building and your network is not distributed over an city or even country. So after I told you what is not a good idea – what setup do I recommend for bigger networks (> 500 client switch ports .. works great for > 10.000 ports and more).
Separate not by department, separate by device class
Yes, that’s the basic idea behind it. Why is that better?
- less work
Employees and departments move around. You need to keep your configuration up to date and if part of a department moves to an other location you need to extend the layer2 network think about something else - simpler and more secure firewall rules
If your VoIP phones, PCs and printers of an department are in the same Layer2 network you need to keep track of the devices for the firewall rules or allow a printer the same access as an PC or an VoIP phone. If you separate your printers in a separated network the firewall rules for them are easy, every device in that network is a printer. The firewall rules can be much more strict than in the PC network – a printer needs to talk to the print server (and dns, dhcp, ntp) but nothing else – a PC needs much more - network authentication tailored to the device class
MAC authentication works for any device, but 802.1x only works if the device supports it. Switching 802.1x on for all devices at the same time won’t work, but if only one device is allowed into a network area with only MAC authentication – It does not help that all others use 802.1x, the attacker just fakes that MAC address. With a separation by device classes you can implemented 802.1x for some networks and others not. e.g. 802.1x for Windows PCs with AD integration is not that complicated – so for the PC network 802.1x could be required, but for the printer network MAC authentication is Ok. This is specially valid if the firewall rules in the printer network are much more strict – even if someone gets access to that network he is not able to connect to the Exchange, database or file server … only the print server is allowed to connect to the printers and not the other way round - separate systems with different patch intervals
Most likely your Windows clients get an update very month but when did your company the last time update the firmware of the printers? Separate them and attacker can’t jump systems that easy any more.
- block client to client communication
If a network area is only used for devices classes that don’t need (or should) communicated directly with each other, you can just block that communication with ACLs. The ACLs are the same for all Layer 2 client access switches and are maintenance free. A classic example for this would be the printer network … why should one printer talk with an other printer – just the print server needs to be able to reach the printers. So if one printer gets pwned it does not affect the other printers. The same is true for building automation networks (like cameras, access control systems, attendance clock) or maybe your PCs don’t need to talk to each other – VoIP most likely needs to 😉
I hope I convinced you its an good idea, but how is it technically done.
Dynamic VLAN assignment
I recommend to use dynamic VLAN assignment via MAC or 802.1x authentication (via RADIUS Server) .Lets assume you’ve following setup:
- Edge: Layer 2 edge switch to which the clients are connected to
- Distribution: Layer 3 switch which aggregates multiple Layer 2 edge switches in the same building
- Core: aggregates the distribution switches in the data center
- Firewall: firewall between DMZ and between the different client network areas
The names of the VLANs on every edge switch are the same, just the VLAN IDs are different. This allows the RADIUS server to return the name of the VLAN the switch should assign to a port or MAC. As the name is the same for all switches, the RADIUS server does not need to know the VLAN IDs. The RADIUS server just has a table that tells it which MAC or common name (in case of 802.1x EAP-TLS) does go into which VLAN. All your switches are configured exactly the same, just the management IP address and the VLAN IDs are different … that makes deploying and maintaining really easy.
For getting the traffic from the edge to the data center I recommend using VRF (Virtual Routing and Forwarding) and OSPF. Just assign the PC VLANs in one VRF and vlanPrinter in an other VRF. The link from the core to the firewall is also tagged. The firewall is now the only way to get from the PC network to the printer network.
I hope that example makes the setup clear, if now just write a comment.
Securing your client network 1: Enforce DHCP usage
June 14, 2015
In my last blog post I talked about going the full Layer 3 way and not building complex Layer2 subnets throughout your network. As many have the argument of security for building their networks this way I thought I write down how I secure client networks. With client networks I mean the part of the network client systems like PCs, phones, printer, … are connected to. Some of the articles and setups can also be used for the data center networks but thats an other story … 😉
All setups I describe in this series I have implemented in productions networks over the years and are therefore not stuff that only works in theory but they work in real life and solve real world problems. So lets start with something easy but which has real benefits not only for security – enforcing DHCP usage by all client systems.
Motivation
Sure, everybody knows for what DHCP is used but lets talk a little bit about the benefits besides not needing to configure each clients manually.
- If clients get their IP address via DHCP its easier to move the client systems to other subnets. So the need to extend your subnet over multiple switches decreases.
Result: Helps you to a more routed network and so simpler and more stable network. Clients can move through out your network and it just works. - It is also easier to change the client subnet if needed it for an upgrade/change of the network architecture.
Result: Makes much more flexible to change your network. - If you enforce the use of DHCP you also get an log file which client had which IP address at a given time and also to which switch port the client was connected. If there are static IP addresses in your network which you don’t control your log file ins incomplete.
Result: Audit logs in case you need to do a forensic investigation on how and by what systems an attack was carried out. Most systems log the IP address and you need to map that to a specify systems/location. - Also if you enforce the usage of DHCP, you can use the DHCP requests/replies for protection against of ARP spoofing (or at least mitigation) in your network.
Result: An attacker can not sniffer the traffic from an other client system in the same subnet. - If enforced, no idiot configures an IP address static which is also used dynamically.
Result: Quieter life for you. 😉
Implementation
To enforce DHCP usage we need to make sure that not using DHCP does not work. How can we do that? Simple – disable ARP learning on the Layer 3 switch, which is the default gateway of a client subnet. ARP (Address Resolution Protocol) is used to resolve IP addresses to MAC addresses, so if the default gateway needs to send a packet to a client systems and it does not know the MAC address (in its ARP table) – its not able to send the packet. Of course the setup needs to work for systems that use DHCP. How is this done? Also simple, the default gateway is most likely already configured as DHCP relay for the central DHCP server so it gets every request and reply. The DHCP reply contains the IP address assigned by the server and the MAC address of the client. The layer 3 switch just needs to write that into its ARP table. From this time on the IP address resolves always to that MAC address until a new DHCP rely provides and not MAC address for a given IP address.
For Extreme Networks switches (XOS) it is as simple as typing that lines per client VLAN/subnet:
enable ip-security dhcp-snooping vlan <vlanClient> port <ClientPorts> violation-action drop-packet snmp-trap
configure trusted-ports <UpLinkPorts> trust-for dhcp-server (only once needed)
enable ip-security arp learning learn-from-dhcp vlan <vlanClient> ports <ClientPorts>
enable ip-security arp gratuitous-protection vlan Default
disable ip-security arp learning learn-from-arp vlan <vlanClient> ports <ClientPorts>
If the clients are connected directly to the layer 3 switch (default gateway for the client subnet) I recommend changing the first command to
enable ip-security dhcp-snooping vlan <vlanClient> port <ClientPorts> violation-action drop-packet block-port permanently snmp-trap
So that guy who did start a DHCP server in your network needs to call you, before it works again – otherwise I recommend configuring that this way on the switch the client is connected to.
Optional
Following setups / configurations should be done to increase the security in this part still more:
- Save the DHCP log file for a longer time period as is default for Windows DHCP servers which rotate every week and make sure all information you need is in the log file.
- Enable ARP spoofing protection also on the clients systems where possible (most likely on on PCs possible). Most enterprise endpoint protection systems allow such a configuration.
- Integrate the configuration of DHCP reservations (e.g. for printers) into your network authentication solution. It already needs to know the MAC address of the client so adding the IP address there is simple. It keeps also the DHCP scopes clean, so if a client is removed from the network authentication, it automatically removes the reservation from the DHCP server. The side benefit is that your service desk employees could also use this to create DHCP reservations without needing DHCP administrator privileges – and its often easier to have an audit log of the changes than on the Windows DHCP server.
Powered by WordPress
Entries and comments feeds.
Valid XHTML and CSS.
36 queries. 0.053 seconds.