Guest diary: Detecting Suspicious Devices On-The-Fly

Published: 2014-11-25. Last Updated: 2014-11-25 20:27:26 UTC
by Adrien de Beaupre (Version: 1)
8 comment(s)

If you apply classic hardening rules (keep the patch level, use an AV, enable the firewall and use them with due diligence), modern operating systems are more and more difficult to compromise today. Extra tools like EMET could also raise the bar. On the other side, networks are more and more populated with unknown/personal devices  or devices which provide multiple facilities like storage (NAS), printers (MFP), VoIP, IP camera, ...

Being easily compromised, they became a very good target to pivot into the network. They run out-of-the-box, just plug the network/power cables and they are ready to go! A classic vulnerability management process will detect such devices but you still have the risk to miss them if you run a monthly scan! To catch new devices on the fly and to have an immediate idea of their attack surface (example: is there a backdoor present), I'm using the following toolbox: Arpwatch, Nmap and OSSEC as the conductor.

Arpwatch is a tool for monitoring ARP traffic on a LAN. It can detect new MAC addresses or pairing changes (IP/MAC). Nmap is the most known port scanner and OSSEC is a log management tool with many features like a built-in HIDS.

A first good news is that Arpwatch log entries are processed by default in OSSEC. It has a great feature called "Active-Response" which allows to trigger actions (read: execute scripts) in specific conditions. In our case,  I just created an active-response configuration to trigger a Nmap scan of any new device reported by Arpwatch:

conifguration snippet

The above configuration specifies that nmap-scan.sh will be executed with the argument 'srcip' (reported by Arpwatch) on the agent '001' when the rule 7201 or 7202 will match (when a new host or a MAC address change is detected). The nmap-scan.sh script is based on the existing active-response scripts and spawns a Nmap scan:

nmap -sC -O -oG - -oN ${PWD}/../logs/${IP}.log ${IP} | grep Ports: >>${PWD}/../logs/gnmap.log

This command will output interesting information in grepable format to the gnmap.log file: the open ports (if any) of the detected IP like in the example below. One line per host will be generated:

Host: 192.168.254.65 (foo.bar.be)  Ports: 22/open/tcp//ssh///, 80/open/tcp///,3306/open/tcp/// ...

OSSEC is a wonderful tool and can decode this by default. Just configure the gnmap.log as a new events source:

And new alerts will be generated:

2014 Oct 27 17:54:23 (shiva) 192.168.254.1->/var/ossec/logs/gnmap.log
Rule: 581 (level 8) -> 'Host information added.'
Host: 192.168.254.65 (foo.bar.be), open ports: 22(tcp) 80(tcp) 3306(tcp)

By using this technique, you will immediately detect new hosts connected to the network (or if an IP address is paired with a new MAC address) and you'll get the list of the services running on it as well as the detected operating system (if the fingerprinting is successful). Happy hunting!

Xavier Mertens

Keywords:
8 comment(s)

Comments

Great writeup and helpful tip, thanks!

I thought I'd point out that there's a few minor syntax issues in your configurations though, in case anybody was having difficulties getting this to work:

On the active response code, the example shows:
</active_response>
When it should actually be:
</active-response>

Also, the example shows:
<rule_id>7201,7202</rule_id>
When I believe it's actually:
<rules_id>7201,7202</rules_id>
In a network with several VLANs, how would this monitoring be implemented? Using local collectors which send the logs to a central server where OSSEC analyzes them?
Marlon.
You are correct, fixed the rules_id issue, not sure what is going on, in the diary editor I see </active-response> as it should be.
[quote=comment#32573]In a network with several VLANs, how would this monitoring be implemented? Using local collectors which send the logs to a central server where OSSEC analyzes them?
Marlon.[/quote]

Hello Marion,
The solution is based on the OSSEC Active-Response feature. This means that it can be implemented on any host running an OSSEC agent (and with the required tools - nmap/arpwatch).
As you said, you can have a distributed solution across multiple VLANs.

Xavier
sorry for the malformed XML snippets. Our XSS filter really didn't like them. I replaced them with images now.
Anyone know if this could be used to trigger a Nexpose scan as well, or could offer a sample CLI snippet?
Are there any commercial tools with a similar functionality built in?
Check out ForeScout as commercial tool that provides the same functions.

Diary Archives