LMConfig and Reporting on ConfigSources
Hi Guys, Wejust implemented LMConfig and I'm trying to run a report to see what devices do not have the IOS configuration successfully downloaded. We have some legacy equipment still not Configured for SSH and TACACS accounts.soI'm trying to get out of having to manually hunting through all our devices to determine what ones need SSH configured and what ones need the TACACS account added.Even justbeing able to pull a report on all devices and whatones have the ConfigSources - IOS Configs field would be a big help. See attached pic for a visual Cheers and Thanks in advance Joel23Views0likes2Comments
Windows ConfigSources: Active Directory
LogicMonitor's configuration backup product, LMConfig, has traditionally been focused on network device configuration backup and diff alerting. However, like other LogicMonitor LogicModules, we provide the capability to run both Groovy and PowerShell scripts in order to retrieve this information.Given those PowerShell capabilities, we can tap into theWindows Active Directory PowerShell modules and use LogicMonitoras an auditingtool. For example: Query Active Directory for a list of domain computers, and generate an alert if this list changes: Query Active Directory for the Default Domain Password Policy, and generate an alert if it doesn't comply with Microsoft best practices. The current suite of Active Directory ConfigSources consists of (11) ConfigSources that will attempt integrated authentication using a Windows collectors' service account -unless it finds wmi.user and wmi.pass properties set - in which case it will attempt to use those instead. I've published them to Github and they can be downloaded from the ConfigSources repository. *These are "officially unsupported" by LogicMonitor, so please proceed with caution!12Views0likes0Comments
ConfigSource that writes outputs to dashboard
A while back I published some very simpleConfigSources to monitor your collector .conf files: a href="https://communities.logicmonitor.com/topic/1345-collector-configsources/" rel="">https://communities.logicmonitor.com/topic/1345-collector-configsources/ Here's an adaptation that writes the various collected configs to a dashboard, writing each of the config outputs to a text widget. Notes: THIS IS A PROOF OF CONCEPT. No warranty is given or implied (value of your investments may go down as well as up, check with your health professional before taking this medicine, etc). Please test before deploying! As with all data within LogicMonitor (or any system), be aware of access rights of users - in this case to whatever Dashboard(s) the config data will be presented on. Be sure to configure your Roles and Users such that only users who have legitimate need to see this data can access whatever Dashboard(s) you send it to. This uses the REST API v1 to verify the target dashboard exists or create it if it doesn't, and also to create / update the text widgets. It will therefore need an API token for an account with management permission for the relevant Dashboard(s), with ID and Key values set as device propertiesapiaccessid.key and apiaccesskey.key. All of the API interaction is contained with a groovy checkpoint, rather than within the config collection script, so this could very simply be copied into other ConfigSources. The same logic could be used in other LogicModules, such as to write non-numeric outputs of SQL queries or any data collection methods to dashboards. While this provides no history retention as written, it will show current / most recent values. Within the script you can define the desired Dashboard path, e.g.'Collector Configs/Groovy Check' (default as presented here), Dashboard name (hostDisplayName is the default), widget name format (hostDisplayName: wildvalue) and other initial parameterssuch as widget colour scheme, description, etc. This is written for REST API v1. One day I may get around to updating it for v2, for greater efficiency, but today is not that day. Tomorrow is not looking likely either. Dashboard text widgets do have a maximum character limit (65,535 characters). I don't think I've seen a collector config near to or in excess of this, so I have no idea whether a larger config from another devicewould be truncated or whether the widget creation would fail. Other widgets on the dashboard are unaffected by this script creating and updating widgets; likewise later manual changes to widget size, colours, etc should be respected; updates should be to the text content of the widgets only, so the target dashboard could contain other data from the device. For example, it might look a bit like this: Known issues: On the first config collectionfor a multi-instance ConfigSource like this, and where the target dashboard does not already exist, only one widget will be created in the dashboard. This is because all instances collect more or less simultaneously, and each determines the dashboard is not initially present. Each, therefore, attempts to create the dashboard and as soon as the first instance does so, the others will fail as they cannot create a dashboard that (now) already exists. This could be coded around with a simple delay / re-check on failure, but I haven't had time, and the second config collection will create all expected widgets without issue. Additionally, if you create the dashboard first, this issue will not occur.9Views0likes4CommentsTracking DataSources changes with ConfigSource
How do we monitor our DataSources? One of our customers asked an interesting and challenging question. He would like to know how he can track and alert changes to his customised DataSources. Well, there was no straightforward way, not until recently. This is made possible with the recent release of the ConfigSource add-on module and the publishing of the dataSource REST API. At a high-level, we can create a Groovy script ConfigSource which makes a REST API call to export a targeted DataSource to XML format, store and check for changes to the XML in ConfigSource, then send an alert when there is a change. Creating the ConfigSource:- 1. Create REST API token 2. Create an embedded groovy script ConfigSource with the following information:- Name : DS_XML Display Name : DS_XML Applies To : This ConfigSource can be applied to any device Collect Every : Up to your company policy, minimum 1 hour Multi-instance? : Check this option Enable Active Discovery : Uncheck this option Collector Attributes : Select Embedded Groovy Script Groovy Script : [... Attached Below ...] Config Check : Select Any Change (Check For: option) 3. Save the ConfigSource import org.apache.http.HttpEntity import org.apache.http.client.methods.CloseableHttpResponse import org.apache.http.client.methods.HttpGet import org.apache.http.impl.client.CloseableHttpClient import org.apache.http.impl.client.HttpClients import org.apache.http.util.EntityUtils import javax.crypto.Mac; import javax.crypto.spec.SecretKeySpec; import org.apache.commons.codec.binary.Hex; //define credentials and url def accessId =hostProps.get("api.access.id"); def accessKey =hostProps.get("api.access.key"); def account =hostProps.get("api.account"); def resourcePath ="/setting/datasources/##WILDVALUE##"; def url = "https://" + account + ".logicmonitor.com" + "/santaba/rest" + resourcePath + "?format=xml"; // get current time epoch = System.currentTimeMillis(); //calculate signature requestVars = "GET" + epoch + resourcePath; hmac = Mac.getInstance("HmacSHA256"); secret = new SecretKeySpec(accessKey.getBytes(), "HmacSHA256"); hmac.init(secret); hmac_signed = Hex.encodeHexString(hmac.doFinal(requestVars.getBytes())); signature = hmac_signed.bytes.encodeBase64(); // HTTP Get CloseableHttpClient httpclient = HttpClients.createDefault(); httpGet = new HttpGet(url); httpGet.addHeader("Authorization" , "LMv1 " + accessId + ":" + signature + ":" + epoch); response = httpclient.execute(httpGet); responseBody = EntityUtils.toString(response.getEntity()); code = response.getStatusLine().getStatusCode(); println responseBody httpclient.close(); 4. Go to the device where the ConfigSource is applied to, define the following device properties :- api.access.id : < API Token Access Id > api.access.key : < API Token Access Key > api.account : < LM Account > Adding ConfigSource Instances 1. Identify the DataSource id. You can find it in the UI by looking at the URL of the DataSource definition 2. Add ConfigSource instances by selecting 'Add Monitored Instance' from the Manage Dropdown next to the manage button for the device Name : < DataSource Name > Wildcard value : < DataSource Id > DataSource : DS_XML 3. Repeatabove step 1 and 2 to add more datasource instances. Point to Note: 1. To execute a ConfigSource, you will need a minimum collector version of 22.110 2. One Datasource Id per instance 3. Differences in DataSource are viewed in XML format 4. Previous DataSource version can be restored by downloading and importing the previously compared XML from the ConfigSource history 5. Thanks and credits to David Lee (Our Jedi Master)for enhancing the original concept to a more user-friendly multi-instances ConfigSource. Screenshots of the ConfigSource result:6Views0likes2CommentsConfigsources ignore all but one line check
Configuration backups in LogicMonitor is a great feature to help you be aware of changes being made ,storeversion history and restore your device configurations. Newerdevices are canhave subscriptions that pull the latest datafrom the manufacturer, such as malicious IP address lists.Encrypted information may be re-hashed for added security and these are expected behaviours - NOT a config change. So you need to ignore these changes, as they are not operational changes and you do not need to be woken at 3 in the morning to see that there are some newly added malicious Ip addresses. Is there a way to ignore these updates (often multiple in a day) and simply key on the first few lines where the config version is referenced ? #config-version=whateverversioninfo #conf_file_ver=177424565748364543 #buildno=somebuildno We need to alert on line 2 and ignore every other change. As you are no doubt aware you can edit your configsource to ignore certain lines with regex.So you can add an ignore change for lines that contain builldno for example. But stipulating every line except one would be a nightmare and you never know what the lines contain all the time. So flip it on its head. Make an ignore check, select ignore lines with this regular expression and use the expression!("#conf_file_ver=").Basically this means ignore every line that does not contain#conf_file_ver= You can see in my example above I have changed the file version and it is shows and is alerted on, but I have also changed the buildno and that is ignored, also added a newline which is ignored. David4Views0likes0CommentsImproved configuration change detection
The addition of configuration backups in LogicMonitor has been a great feature for our support team and really helps streamline things. If you like to be aware of people making changes and retain version history is is wonderful, but we have an issue on some of the more modern devices. Many new devices are intelligent and have subscriptions that pull the latest IPS, AV, malicious IP address lists, etc. from the manufacturer. There is also a periodic re-hashing of encrypted information for added security and these are expected behaviors - NOT a config change. We developed our own config backup using SCP for the devices so no passwords are stored in LM either, but the key here is that a login event (human or automated) causes the config version to change. The suggestion I have is simple - there needs to be a way to ignore these updates (often multiple in a day) and simply key on the first few lines where the config version is referenced - #config-version=FWF60D-5.02-FW-build742-161129:opmode=0:vdom=0:user={redacted} #conf_file_ver=17742419038372504090 #buildno=0742 That conf_file_version (line 2 above) would be the trigger and ignoring everything else would be perfect. Thoughts welcome!4Views0likes1CommentList config changes in config DifferenceTest alerts
Our networking team would like to generate email alerts for network device configuration changes. I would like to see the option to add text in the config DifferenceTest alerts that actually shows old vs. new configs to see what changed in the email, especially for road warriors who don't have an option to immediately log into the device or LM to drill down and manually check to see what changed. For example, we use Meraki and in the Meraki portal, and below is an example email alert that shows the old and new values of the device configuration: DeviceName / 25 was changed by John Doe (jdoe@email.com). Old value: Allowed VLANs: all New value: Allowed VLANs: 123,456,789 This would be very beneficial for auditing, troubleshooting, and security response.3Views1like1Comment