Whether it's Dropbox, LinkedIn, MySpace, PlayStation, or whatever the latest breach happens to be, it's almost inevitable that you will be caught up in one of these breaches and have your username, password and possibly other information exposed in a data dump. Here's how to respond when that happens.
I wanted to jot down some quick notes relating to running a virtual Firepower sensor on ESXi and how to validate that all the settings are correct for getting traffic from the physical network down into the sensor.
Firepower is the name of Cisco's (formerly Sourcefire's) so-called Next-Gen IPS. The IPS comes in many form-factors, including beefy physical appliances, integrated into the ASA firewall, and as a discrete virtual machine.
Since the virtual machine (likely) does not sit in-line of the traffic that needs to be monitored, traffic needs to be fed into the VM via some method such as a SPAN port or a tap of some sort.
At the time that I'm writing this I've been working at Cisco for just over 3 years as a Systems Engineer. Prior to that I worked for multiple Cisco customers and was heavily involved in Cisco technologies. I know what a monster cisco.com is and how hard it can be to find what you're looking for.
Since starting at Cisco, the amount of time I've spent on cisco.com has shot up dramatically. Add to that studying for my CCIE and it goes up even more. In fact, cisco.com is probably the number 1 or 2 site I visit on a daily basis (in close competition with Google/searching).
After spending all this time on the site and given how vast the site is and how hard it can be to find that specific piece of information you're looking for, I'm writing this post as an aid to help other techies, like myself, use the site more effectively.
This post is about finding and fixing a memory leak I discovered in the SNMP daemon, snmpd(8), in OpenBSD. This sort of analysis is foreign territory for me; I'm not a software hacker by day. However, using instructions written by Otto Moerbeek as my Rosetta stone and Google to fill in the blanks when it came to usage of the GNU debugger, gdb(1), I was able to find and fix the memory leak.
I'm documenting the steps I used for my future self and for others.
I've had enough real life experience with replacing drives in the ZFS pool in my home NAS that I feel comfortable sharing this information with the community.
I've been working on something that at this point in my career I never thought I'd be doing: another Cisco Certified Network Associate (CCNA) certification. The CCNA Voice, to be exact. Now that I'm in a job role where I'm expected to be somewhat of a jack-of-all-trades, I can no longer avoid learning voice :-) For a long time I've focused on just the underlying network bits and left the voice “stuff” to others. Since I now need to talk intelligently about Cisco voice solutions, products, and architectures, I decided to go through the CCNA Voice curriculum as a way to establish some foundational knowledge.
This post is about the tools and methods I used to build a small lab to support my studies.
I installed OmniOS on my home filer over the Christmas break. Jumping from a Solaris Nevada build to OmniOS meant figuring out what software packages are available in the OmniOS repositories, what third-party repos are available and what software I would have to compile by hand. Given that this machine is only acting as a filer and isn't running any other services to speak of, the list of software to get up and running is small; however a critical component is apcupsd which talks to the Uninterruptible Power Supply (UPS) and cleanly powers down the filer if the power goes out for an extended time.
The hangup for me is that my UPS connects to the filer via USB, not a serial connection. It took me some hours to figure out how to get apcupsd installed with USB support. Here's how.
Ahh the Christmas break. The perfect time for good food, enjoying the company of family and friends and of course…. IT projects at home! My project last year was to immerse myself in the source code for OpenBSD's snmp daemon so that I could integrate my patch-set for Net-SNMP directly into the native OpenBSD daemon. That was time well spent as I was able to integrate my code in the following weeks. This year I have maintenance to do in the home lab. It looks like 2013 is going to be a busy year as far as getting my hands on new stuff so I want the lab ready to rock.
First project: upgrade my VMware ESXi server from 4.1 to 5.1.
Cisco's Identity Services Engine (ISE) is a powerful rule-based engine for enabling policy-based network access to users and devices. ISE allows policy enforcement around the Who?, What?, and When? of network access.
- Who is this user? A guest? An internal user? A member of the Finance department?
- What device is the user bringing onto the network? A corporate PC? A Mac? A mobile device?
- When are they connecting? Are they connecting to the secure network during regular business hours or at 02:00 in the morning?
These questions can all be answered easily within ISE and are all standard policy conditions that are relatively easy to implement. In the post below I'm going to focus on the How? — How is the user or device connecting to the network? Asked another way, the question is Wired? or Wireless?
Although it would be awesome to ditch Net-SNMP altogether now that the base OpenBSD SNMP daemon has support for all of the OpenBSD-related MIBS (CARP, PF, kernel sensors), reality is that Net-SNMP still offers some features that are needed. OpenBSD doesn't have any SNMP tools (snmpwalk, snmpset, etc) so these are still required from Net-SNMP. There's also some unique features in the Net-SNMP daemon that are still useful if you want to do things like monitor BIND9 or Postfix statistics.
Here's how to run both at the same time and leverage snmpd for the OpenBSD-related MIBs and the Net-SNMP daemon for its ability to retrieve data from scripts and extend itself using loadable modules and smux sub-agents.