Threat Level: green Handler on Duty: Russ McRee

SANS ISC: Guest diary: Detecting Suspicious Devices On-The-Fly SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network
https://isc.sans.edu/honeypot.html

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Guest diary: Detecting Suspicious Devices On-The-Fly

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

Adrien de Beaupre

353 Posts
ISC Handler
Nov 25th 2014
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>
Anonymous
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.
Marlon

9 Posts
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.
Jim

416 Posts
ISC Handler
Quoting Marlon: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.


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
Xme

537 Posts
ISC Handler
sorry for the malformed XML snippets. Our XSS filter really didn't like them. I replaced them with images now.
Johannes

3914 Posts
ISC Handler
Anyone know if this could be used to trigger a Nexpose scan as well, or could offer a sample CLI snippet?
Johannes
1 Posts
Are there any commercial tools with a similar functionality built in?
Michael

32 Posts
Check out ForeScout as commercial tool that provides the same functions.
Anonymous

Sign Up for Free or Log In to start participating in the conversation!