So when I last left you guys I was attending Splunk .conf. My plan was to write each day but I quickly realized how long the day was when you included 9 hours of conference, plus commuting to and from DC each day so screw that.
So today was day one of Splunk .conf2017. This being my first time at .conf, I wasn’t entirely sure what to expect. The morning started off with the keynote address by the CEO of Splunk, Doug Merritt. A couple of interesting numbers to start with. 7,187 people were regestered to attend .conf this year from 65 countries who traveled a combined 65 million miles to get to Washington DC (enough miles to go to and from the moon over 100 times).
Congrats to all of the NCOs who have been selected to join the ranks of the Signal Warrant Officer Corps.
Today was the first (well sort of) day of the 8th annual Splunk .conf convention here in DC. .conf covers a range of topics, is three days (well really 2.5) long, has over 200 technical sessions, and includes over 6,000 participants. In short, its a bit of a data science nerd orgie.
A while back I wrote about the importance of using a standardized time source. Keeping accurate time across devices is essential so that you can easily correlate events within logs across the network. But what do you do when you’re operating on a closed network and there is no time source that you can pull from?
This is the first of what will be a number of posts on building out parts of a basic mission network. This network will be based on Centos 7 (Linux), with an IPA server (Linux version of Active Directory), have a local patching server, and a number of there features. Today’s article will focus entirely on the basic build of a Centos 7.0 system and will serve as the base system for all of the other lessons in the future
I know I’m a little bit late getting this posted but here is the schedule for the first half of FY 18 warrant officer selection board. As I’ve written before a few times, it’s our job to find our replacements so make sure you take the time to talk to your NCOs that show promise and mentor them to come to the dark side.
You likely haven’t noticed yet, but if you look at the top corner of your browser, you should be seeing a little lock symbol up there for the first time (at least when you came to this site). For years now, Signal-Chief has been served up on straight HTTP. I was never really worried about it because there is no personal information on the site, and the only person who actually logged into it was me (and I use unique passwords on everything)
So you may not have noticed (hopefully) but I recently moved signal-chief from a shared hosting instance on GoDaddy to a dedicated VPS system. As a cyber guy, one of the first things I wanted to do was to start with some basic security so of course step one is to run yum update to update all of my packages, and step two was to setup some firewall rules. To allow me to initial a connection (DNS, http, whatever) from the server and get the return traffic back. Unfortunately when I tried to run this command I got “iptables: No chain/target/match by that name” sent back to me. Well that’s frustrating.
Imagine this scenario…. “The first neutron passes the LD and engages enemy position. The enemy position is destroyed and the damage is extensive enough to cause an adjoining position to catch fire. When the ammunition in that adjoining position explodes it takes out another position…” Huh?