<![CDATA[Shadow Trackers - Blog]]>Mon, 21 Aug 2017 18:56:20 -0700Weebly<![CDATA[Baking my own Pi3]]>Tue, 22 Aug 2017 01:19:25 GMThttp://shadowtrackers.net/blog/baking-my-own-pi3For the past few weeks, I’ve been working at installing Bro IDS onto a Raspberry Pi 3. This is for a project I’ve been thinking about for a while and if successful, I will submit to several cons. But in the meantime, I want to document what I’ve done both for myself and anyone who may be interested.
I’m not going to repeat things where someone else has done a great job of writing them up. I will merely put a link to the web page where you can go read.
To start with I have a Raspberry Pi 3 (https://www.raspberrypi.org/products/raspberry-pi-3-model-b/) on which I installed Rasbian Lite (https://www.raspberrypi.org/downloads/raspbian/). I used Etcher (https://etcher.io/) to burn the image to a 32GB microSD card. I also bought a power supply for the Pi3 after trying unsuccessfully to use one of the MicroUSB cables/plugs I had lying around the house. Turns out most of the ones used to recharge phones are at most 2.1 A (and some not even that) and the Pi3 needs 2.5. So my Pi3 kept rebooting over and over until I got the new power supply. (BTW, this is when I REALLY miss Radio Shack. This delayed me two days waiting for Amazon to deliver). So my advice is buy the power supply when you buy the Pi3.
I don’t have a HDMI monitor, but I have plenty of VGA connected monitors. A simple HDMI=>VGA converter works no problem. I’m using the Inland brand from MicroCenter (yes, I know, why didn’t I buy the power supply while I was there… IDK..anyway). Anyway:

Once I burned the image, had the right power supply and booted up and voila! I was in.

username: pi
password: raspberry
I shouldn’t have to tell you, change these as soon as possible.
Now, I had a working Pi3, on a monitor with a keyboard. I connected it to my network and proceeded to update and patch, apt-get update && apt-get upgrade.
The raspberry foundation has a nice list of configuration steps here: https://www.raspberrypi.org/documentation/configuration/ and I worked thru them as I thought they applied to my environment.
Run the raspi-config configuration tool and set up your environment. This is where you turn on the ssh server.
I set about securing the Pi3 by doing things like turning off the bluetooth, disabling telnet, locking down ssh, etc. (https://www.raspberrypi.org/documentation/configuration/security.md)
I worked on setting up the wireless card, since I wanted the wired port to be the listening port.
That turned out to be a little bit tricky. The instructions given on the Pi3 page didn’t work for me: https://www.raspberrypi.org/documentation/configuration/wireless/wireless-cli.md
but these did:
Except if I reboot, I have to turn the wifi back on. Argh. Still working that out.
Once I got the wifi to work, ssh’d to the wlan port so I could leave the wired port for bro to use exclusively.
Once I got Raspian configured to where I liked, I started looking at how to install Bro on the Pi3. There are a bunch of folks on the web who’ve done this before:
As well as lots of instructions for installing Bro in general:

I just chose to follow the instructions here:
Since all of these instructions are pretty much the same, I’ll just note some of the challenges I had with my install and how I got through them. Obviously, YMMV.
First, regarding the pre-requisites:
I had to make sure ‘git’ actually installed correctly. It’s much easier to pull and install Bro using git. Also, a lot of custom bro scripts are kept on github, so having git installed makes it easy to deploy those.
Make sure you install GeoIPv6 as well as GeoIPv4. Raspian and the Pi3 understand IPv6 so you don’t want to miss out on that data.

Getting sendmail configured so that it could send me mail to my gmail account took a little bit of trial and error. Fortunately, I found this page:
For those that need to connect to a different port than 25, I found this:
I ran into an error when I was testing and I got :

535 Incorrect authentication data. >>> MAIL From: SIZE=18 AUTH=pi@mydomain.com”
But I must to confess…. I don’t remember what I did to fix it. If I remember, I’ll update. (second time I ran through these steps, I did NOT get this error… argh)
All of the other prerequisites installed fine. I did not install pf-ring as I did not think my environment needed that.

Finally, I was ready to install Bro. As I said, I followed the instructions at

Bro installed very nicely. I’m running as root, so I didn’t have to do any of the permission changes.

I then started bro and voila! Analysis of my network started to happen.

To monitor my network, I put in a bought a SharkTap Network Sniffer for about $70. If I had to do it again, I would buy the GS105Ev2 – ProSAFE Plus 5-port Switch for about $40. It does port mirroring and is not a single point of failure (wife and kids losing streaming because of overloaded tap: not fun to fix while at work). Both are on Amazon.

So that’s it for now. My next post on bro will talk about my adventures learning to write scripts that alert and having those alerts send me email notices.

<![CDATA[What is old is new again]]>Thu, 04 May 2017 01:15:10 GMThttp://shadowtrackers.net/blog/what-is-old-is-new-againMy family was driving back from a trip to my parents house a couple of weeks ago.  During that drive I had several hours where I was looking to fill the time. So I wrote down some blog ideas, listened to some podcasts, and read some blogs in my RSS feed. But I also started going through notes from past cons. I've mentioned before about how important I think it is we apply what we learn at cons.  The way I do that is by taking notes and then referring to those notes later. I often take a LOT of notes; sometimes by hand in a notebook and sometimes digitally for two reasons:

  1. Remember suggestions/tips/tricks that will help improve security
  2. Share what I learned with those who didn't go

The problem is that with so much information in my notes, things get lost or buried over time.  This means that some items that fall into category #1 don't get implemented.  So I've started taking downtimes such as the drive home to review my notes and find those things I forgot about, determine if they are still relevant, and send myself a new reminder to try them out.

So, have you been taking notes at cons that you go to?  Are you saving them in a safe place?  If so, set some time to review your old notes.  You may find some forgotten treasure in there you didn't know you had.
<![CDATA[What Does Security Do?]]>Thu, 20 Apr 2017 00:38:26 GMThttp://shadowtrackers.net/blog/what-does-security-doRemember a few years ago, there was a popular meme going around where people described what they did vice what other people think they did vice what they actually did? Well, I was thinking the other day during one of the Scout hikes I was on (The Boy Scout troop my sons are in is a hiking/backpacking troop, but that’s another blog post) about that and instead of applying it to myself, I tried to apply it to information security as a whole. Below are my thoughts based on recurring issues within information security.  Then I end with what I think we should be doing. 
What Users think Security Does
  • Add more authentication to every part of the network
  • Block access to all websites
  • Deny all requests for additional features
  • Spy on all traffic
  • Restrict permissions on each machine so that it’s unusable
What Management thinks Security Does
  • Ask for new tools/devices
  • Add additional paperwork for new regulations/laws/requirements
  • Request more training
  • Block new tech/say things can’t be done
  • Cry ‘wolf’ all the time (New attack! New Vulnerability! 0 Day! Nation State! Danger Will Robinson!)
What Operations think Security Does
  • Break things by scanning
  • Prevent systems from working by implementing unnecessary security settings
  • Slow deployments by requiring security testing/compliance
  • Increase complexity of network
  • Slow network down
  • Constant sci-fi doomsday scenarios based on unicorn possibilities
What Developers think Security Does
  • Reject completed projects/apps for “lack of security”
  • Add additional unnecessary hurdles to nearly completed projects causing delays
  • Add complexity to applications/projects
  • Confuse customers and users with ‘requirements’
  • Slow the application with implemented security
  • Raise sci-fi doomsday scenarios based on unicorn possibilities requiring esoteric configurations
What we think we do in Security


While leading a mild manner life as an overwhelmed security tier 1 security analyst

What we in Security should be doing
  • Working alongside users to understand their work flows and processes to integrate security as seamlessly as possible
  • Working with ops to engineer security into deployments and applications
  • Participating in management discussions to develop solid risk analysis based on a solid understanding of the business, critical data/processes and strategic partners.
  • Working with developers to understand the requirements of each project and design security into the application so that it is as transparent as possible to the user/customer. So that security is integrated into the solution behind the scenes and alternative solutions can be found if necessary.
  • Actively monitoring the environment, of traffic going out, coming in, and moving internally as well as activity on user workstations, externally facing servers, and internal devices for malicious and suspicious activity.
  • Developing and maintaining procedures for investigating and responding to malicious and suspicious activity.
  • Developing and executing hunt methods to find hidden malicious activity.
  • Providing management status and metrics showing the risks they are facing and where the organization stands in relation to their horizontals and verticals in terms of security.

<![CDATA[How I got into Security Engineering and what it means to me]]>Sun, 26 Feb 2017 03:05:38 GMThttp://shadowtrackers.net/blog/how-i-got-into-security-engineering-and-what-it-means-to-meMy career started with a degree in Electrical Engineering and that started with a strong curiosity to learn how things worked.  After graduating, I spent ten years in the military working on networks.  First as a sysadmin, then assigned to a team that focused on optimization and troubleshooting networks at different bases all over the world.  This is where I truly learned about how networks worked, why they worked, and how to make them work better, all the while ensuring the mission was not interrupted.  My next career stop was in a network security manager role at a government organization where I learned to navigate both the politics of getting permission to improve security and the technicality of implementing security; again without disrupting the missions of multiple interest groups.  The experience I gained during both of these jobs formed my basic philosophy of how I approached every job since then. 

This philosophy boils down to three things:

1.  My jobs as an Security Engineer is to improve the protection of users, data and processes while impeding those users, data and/or processes as little as possible.
  • Don't negatively affect the mission of your organization.  In a fight between security and mission, mission will always win.

2.  I can't do #1 without understanding how my protection improvements work, and how they have to be integrated into the network to work properly and what the impact to the network will be during and after integration. 
  • Nothing affects your credibility more than appearing that you don't have a clue about how your tools work or how the environment your tools are in work or that the effects were unanticipated.

3.  My job cannot be done in isolation.  I must have a good interactive relationship with the operations group, dev group, compliance group, users group and the management group.  Otherwise I run the risk of being ineffective, disrupting the mission and making the network less secure. 
  • You will make your job that much harder if you are arrogant, or stubborn, or condescending, or all three toward your coworkers.  They will not want to cooperate and will stonewall you and your efforts regardless of how much those efforts make sense or are required.

<![CDATA[What you need to learn to start learning Infosec]]>Sun, 05 Feb 2017 03:03:59 GMThttp://shadowtrackers.net/blog/what-you-need-to-learn-to-start-learning-infosec 
This is a little bit of a long post. Here’s the TL;DR
  • There are at least three groups of people where it appears that a percentage of each group lacks a basic understanding of IT. These groups are: Individuals getting into infosec, recent colleges grads and compliance auditors
  • My suggestion is to generate a common ground of IT knowledge all infosec professionals should know, no matter what infosec career they choose
  • I suggest this common ground have three categories: Computing, Operating Systems and Networking. In each category, there will be certain knowledge you must know and skills you must have.
  • I hope my suggestion will start many more discussions so that at some point there is a general consensus, one driven by the industry not by a company.

One of the questions I, and many others, are often asked is “How do I get into Information Security?” and over the past few years, there have been several excellent blog posts and talks covering that very topic (see the links at the bottom of this post or this link to a compilation on ForgottenSec github). However, I recently had a situation where an individual asked me this question and I realized that none of those blogs or talks could help him… yet. The reason those resources could not help him was because they all assumed the person interested in information security already had experience in IT. This person did not.

Now, as you know, not having any experience in IT is not an impediment to becoming a great infosec worker. Most of us learned IT along the way. Some people were self driven, always trying to figure out how things worked or how to make THIS work to get THAT to work. I took a different path as I was a 9-5er who was blessed enough to get some great training and have good jobs until I was bitten by the bug… now I’m as driven as any; going to cons, writing a blog, giving talks, etc. But I realized my advice to this individual was going to have to take a different approach. He was interested in learning, but I could not just have him start running nmap or playing with metasploit since he didn’t even understand TCP/IP. I first had to come up with what I thought were the prerequisites he needed to enter into the infosec field.

While I was working on this list, Shmoocon was going on and I had a chance to bounce my thoughts off several individuals at that con. Several of them pointed out another group of individuals that would benefit from this list of prerequisites: Recent graduates of colleges who had a received a cybersecurity degree of one type or another. They pointed out that many of this grads have a good understanding of what security is, but not about how it works technically. This concern was confirmed in a recent discussion on one of the SANS email lists where multiple infosec professionals talked about the challenges they were having hiring recent graduates that met the technical requirements needed to perform entry level jobs. These grads understood policy and concepts, but they couldn’t actually look at packets or even in one case, recognize a hard drive visually.

So now I had two categories of people who need some kind of baseline IT knowledge. While I was researching this article, I thought of another type of person who would benefit from that baseline; the compliance auditor. We’ve all run into the issue where we need to work with a policy or compliance auditor who only understands the checklist or the theory written into the policy. This inevitably leads to conflict when a technical solution is implemented that meets the purpose of the policy, but is unorthodox and the auditor rejects it because it doesn’t match what is written. Or the opposite, when the auditor accepts a solution because it meets what is written, but the solution doesn’t actually protect what the policy says it is supposed to protect. An auditor who has a fundamental IT understanding underneath the security knowledge would do much better in these situations.

So I looked at some certifications, some job descriptions, some course requirements, and had some discussions to get an idea of what was expected of new infosec professionals from different groups. I then began to compile a list of what I thought was common ground among all these sources. Thinking about this common ground reminded me of something. (stay with me on this) In the past, I’ve heard some people compare the maturing of our industry to how medicine matured over then centuries in training and practice and standards. While I don’t think you can take that comparison too far, I will use this one analogy: We should have a “med school” requirement. That is, there should be a certain set of skills and knowledge every infosec practitioner should learn first, regardless of the career field they enter. So when the pentester talks to the compliance auditor talks to the forensic expert, they may each have specialized abilities, but there is a common foundation they all understand. How should this common set should be formed? Well like everything else, through lots of discussion, arguments, more discussions and practical observations. Will we need some kind of industry wide board like the AMA that makes a final decision or will the masses come to some kind of general agreement? I don’t know. Please, though, let’s not have some company come up with their own certification and try to sell that to us. Will those that are self driven learn far more that this common knowledge set? Sure. Will is ensure that every infosec person is competent? No. But I hope that it is a start and what I do know is that whatever we come up with needs to be flexible as it probably should change at least every year. I think as we work to mature this field and we look for ways to bring massive amounts of people in to fill all the open positions, we need to standardize knowledge and skills.

So, here are my suggestions for the things that I suggest are the common foundational skills and knowledge needed for someone to enter into infosec. This baseline knowledge enables a person to understand the underlying architecture of how the Internet works. These are the thing that experience infosec professionals know inherently, that new people should know. And therefore, these are also the skills and knowledge someone who is non-technical needs to attain so they can start learning infosec.

A person needs to have skills and knowledge in the following three areas: Computing, Operating Systems, and Networking. Note that while there will be overlap between areas, I’ve tried to create a layered approach to the levels. So, for example, while Network Drives may be a form of storage, I’ve left that out of the Computing section and put it into the Networking section.

All about the computer, what it is, how it works and what forms it takes (desktops to IoT and everywhere else)

A person needs to know:

  • How a computer works
  • Input devices (keyboards, scanners, etc)
  • Storage (RAM, Hard Disks, USB, CD/DVD, etc)
  • Processing
  • BIOS, hard drive boot sector, booting, etc
  • How a computer program runs
  • High level language vs machine language
  • How instructions are loaded, executed and output delivered

A person should be able to:

  • Point out major components of a computer
  • Do a hard reboot, soft reboot, get into the BIOS, change boot order

A person should know about the places computers are going into and what form factors they may take.

Operation Systems 
All about the software that makes the hardware work

A person needs to know:

  • Different types of OSs (Windows, Linux/Unix, OS X at least)
  • Purpose of kernel and “user space”
  • Purpose of drivers, applications, daemons/services,
  • Purpose of accounts, groups, and their access levels (root, administrator, user, guest) and how to create new groups with new levels of access.
  • Purpose of objects and their permissions
  • How users, groups and their access levels interact with objects and their set permissions
  • Logging, what gets logged and why
  • Firmware, software, etc
  • Difference between authentication and authorization

A person needs to be able to:

  • Install an OS
  • Create users, files, folders and set permissions for different levels of access and abilities
  • Install applications and set different levels of permissions for use
  • Enable logging and read and understand logs and be able to diagnose basic problems
  • Use the command line and gui for common commands

All about how computers talk to one another, how data gets transferred and how things are controlled remotely

A person needs to know:

  • OSI model and the protocols that go with each layer
  • How the Internet works (addressing, routing, subnets, DNS, 3-way handshake, how data is transferred, ….)
  • What the following are, how they work and what they are used for:
    • Firewall
    • IDS/IPS
    • Proxy
    • DNS
    • Email server
    • Routers/Switches and permeations of this group
    • VPN/RAS/RADIUS/etc
    • Web Servers
    • Databases
  • What network traffic looks like and what the packets look like in a traffic analyzer
  • how client/server methodology works
  • Windows networking
  • *NIX networking
  • Network Authentication and RADIUS
  • Encryption
  • Remote access (RDP, telnet, ssh, scp, ftp….)
  • How accounts and groups are created and managed on a networking vs stand alone
  • How objects are created and managed on a network vs stand alone
  • How applications work on a network vs stand alone
  • How object and application permissions interact with users and groups and their access level on a network vs stand alone
  • Understand how computers and networks use binary, hexadecimal and decimal numbers
  • On a windows server: Understand windows GPO, Security policies, user accounts, user groups, event logs
  • On a Linux server: user/group, iptables

A person should to be able to:

  • Capture, identify and read network traffic (using wireshark or equivalent)
  • Install *NIX and configure different users into different groups for ssh remote access
  • Install Windows Server and configure basic policies
  • Understand logs and perform basic troubleshooting of network activity
  • Create users and groups on different platforms and configure remote access
  • Perform basic network troubleshooting (ping, traceroute, netstat, ps/tasklist, etc)

I know I forgot some things. I know I left out other things. The point is to continue the discussion.
So what have I left and and why do you think those things should be included?

Are the other people who have compiled and published their own list of common knowledge and skills? Other collections that have been proposed as a standard?

Or is this concept wrong to begin with?

Let me know your thoughts. If you have other links, I’ll post those on my page and I hope others will post my link on their page so these discussions can continue.

NOTE: I gave a 20 minute presentation on this topic at Shmoocon Epilogue in January. This post is an expansion on what I talked about then. If you want the slides, however, they are here.
File Size: 89 kb
File Type: pptx
Download File