Monitor operating system changes and analyze introduced attack surface when installing software
dawgmon - Dawg the Hallway Monitor
SUMMARY
The name of this tool is based upon an episode (season 10, episode 10) of South Park in which Cartman is Dawg the Hallway Monitor patrolling the hallways of his school. It's a tool which helps one to monitor changes which have taken place on a Linux-based system since the previous time the tool was ran.
One way to use it is to use something like the included sample cronjob to run dawgmon on a regular interval and email the results to the system administrator. This can help with identifying machines upon which nefarious things are happening and monitor who's installing what and where. Please note that any serious kernel backdoor will easily be able to hide itself from this tool and as such it's just one added tool in one's toolkit but it should not relied upon for full security monitoring of Linux machines. It's just one extra option in one's toolbox.
The other way it's useful is by generating a baseline before installing a piece of software. Then after installing this piece of software one will run the tool again and then it's easy to see which changes were made on the system. An example after establishing a baseline and then installing virtualbox on a machine might yield something like this:
1 change detected (0 warnings)
[...]
33 changes detected (0 warnings)
The above helps with now doing a thorough security review of virtualbox. The installed suid binaries are obvious points of entry and the run services are interesting.
Another example run which correctly detects TCP ports opening and closing:
0 changes detected (0 warnings)
[1] 12489
1 change detected (0 warnings)
nc -l -p 4455 ^C
1 change detected (0 warnings)
The tool is not meant for complete accuracy. There are very serious recommendations normally to not rely on the output of GNU core-utils such as ls for tool input. In other words; one should rarely build tools to parse and rely on this type of output as it can change all the time. Realistically the output of these tools is relatively stable as a lot of people and automatic tools already rely on their outputs for all kinds of purposes.
However the tradeoff for dawgmon is the following; we would need to implement a lot of logic to do file system monitoring ourselves, build complex binaries that include libraries to do the parsing and monitoring of block devices, the network interfaces and what not more. This will also make the tool way more complex and less maintainable. On projects right now one can add a new command including change detection in very little time as the main dawgmon tool already takes care of caching, executing the command and then supplying the previous and current output when running a comparision to a command implementation. This means that on time-constrained projects one can very quickly add a new command and run analysises including those new commands.
A command can be added by simply inheriting from the Command class. This class is defined in commands/init.py. That file contains also the master list of commands (and the order in which they're executed when doing a full analysis). Then the properties like 'name', 'shell', 'command' and 'desc' will have to be set and two methods 'parse()' and 'compare()' will have to be implemented. Enough commands are included to get a good idea on how to implement and add new ones.
USAGE
For best results run the tool as root. For help type -h/--help and for version information type -v/--version.
A main action will always have to be specified. These actions are: -A: analyze the system -C: compare cache entries -E: list available commands -L: list cache entries
dawgmon -A
dawgmon -A -e list_suids -e list_tcpudp_ports
dawgmon -E
dawgmon -L
dawgmon -C 3 5
Further options to help with the analysis are:
-d: show debug output -e: execute a specific command (can be used multiple times) -f: force a run without warning about running as root -g: colorize the output -l: location of the database cache to use -m: maximum amount of cache entries to allow in cache (if cache has more entries than this amount it will truncate the database) -t: do not output timestamp information per detected anomaly.
For more usage information run the tool with -h.
LIMITATIONS
The tool parses output of commandline tools and relies on GNU core-utils specific options for some of it. There's no specific reason why this tool and the command implementations cannot be quickly ported to other operating systems such as the BSD's but right now no Operating System detection is taking place nor is there a classification of commands based on Operating System support being done. That would have to be implemented first.
Regarding the finding of pipes, UNIX sockets, files in /boot, /etc and more one should note that the usage of -xdev passed to 'find' means that not all filesystems mounted under the start directory will be traversed. This means that for example /boot will be properly scanned but /boot/efi might not be. Some smarter approach will have to be used here in the future.
The timestamps when doing a current analysis might be a bit confusing. By default a timestamp for a warning, normal or debug anomaly message will be the timestamp of its generation time (as can be seen in commands/init.py). The anomalies are generated after a full commandline scan has been done. So the output upon which this detection works was generated earlier and subsequently the timestamps for individual anomalies show a time after the time of the scan. When comparing cache entries the timestamp of the scan is being used to output the time at which the detection happend as that makes logically simply more sense.
ABOUT
All rights reserved. Copyright (C) 2017-2019 by Anvil Ventures Inc. For licensing information see LICENSE. For more information contact Vincent Berg gvb@anvilventures.com
To find updated source code or to contribute patches go to the following URL: https://github.com/anvilventures/dawgmon/
FAQs
Monitor operating system changes and analyze introduced attack surface when installing software
We found that dawgmon demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
In this segment of the Risky Business podcast, Feross Aboukhadijeh and Patrick Gray discuss the challenges of tracking malware discovered in open source softare.
Research
Security News
A threat actor's playbook for exploiting the npm ecosystem was exposed on the dark web, detailing how to build a blockchain-powered botnet.
Security News
NVD’s backlog surpasses 20,000 CVEs as analysis slows and NIST announces new system updates to address ongoing delays.
