Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Version control tools aren't only for Developers InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Version control tools aren't only for Developers

Published: 2017-10-12
Last Updated: 2017-10-12 06:56:35 UTC
by Xavier Mertens (Version: 1)
5 comment(s)

When you start to work on a big project or within a team of developers, it is very useful to use a version control system. The most known are probably ’svn’[1] or ‘git’[2]. For developers, such tools are a great help to perform tasks like:

  • to keep different versions of the same files
  • to compare different versions
  • to start working on new branches
  • to merge the changes from multiple developers

The teamwork is greatly improved but also the follow-up of who did what and when. If such tools offer so many advantages to developers, can it be the same for security peeps? Of course yes!

Besides powerful command line tools, the ‘git’ system is also available via a web-based repository manager: GitLab[3] or GitHub[4]. The second one is very popular amongst developers and allow them to host their projects online on (public) repositories. How to benefit from the version control in our security field? My public projects are hosted on github.com/xme but, in parallel, I’m also maintaining a private and secure GitLab server for personal data. 

The first example is the quick deployed of files. I’ve projects containing scripts, password lists, URLs, etc that can be deployed at any time when I’m working on a specific project or at a customer. If I need to get some password lists or python scripts:

$ git clone https://git.tld/passwords.git
$ git clone https://git.tld/scripts.git

All my Docker compose files are also available in repositories and ready to be deployed on any new host.

$ git clone https://git.tld/docker_spiderfoot.git
$ cd docker_spiderfoot
$ docker-compose up

During pentest engagements, I like to push all the collected information and piece of code that I wrote to a dedicated project.

The second example is the management of backups and configuration files. The following configurations are stored in my GitLab repository:

  • Firewall configs
  • Switches
  • Routers
  • Access-points
  • Servers (ex: Apache, Postfix, …)
  • Docker compose files

In this example, I’m often using the 'diff' feature to check what changed between two version and when. Trust me, this is super useful to debug some networking issues.

Finally, the third example is to use GitLab as an ‘information exchange' platform. If there exist platforms like MISP to share IOC’s, there is also a lot of other information that can be shared between applications and tools:

  • IP addresses or URLs whitelists/blacklists
  • Pools of internal resources (IP addresses, domains,...)
  • Public lists (like the Alexa ranking list)
  • GeoIP databases

By having all those files centralized, you just have to grab them when needed and only one update is needed. At a customer, we export IOC’s from MISP to a GitLab server in CSV format. Then, they are re-used by multiple other tools like Splunk to perform lookups in security events.

[1] https://subversion.apache.org/
[2] https://git-scm.com/
[3] https://about.gitlab.com/
[4] https://github.com/

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

5 comment(s)
Diary Archives