Last week I moved towards using a Lubuntu host for a management workstation in various scenarios. I need the following tools in order for this to be effective:

• SSH Client (for network devices, especially Cisco switches, routers, and firewalls)
• Web Browser (for various reasons, especially ESXi, iDRACs, and Collaboration / Ticketing software
• Remote Desktop Client (for pesky Windows systems)

Along the way I learned that Cisco has implemented SSH Key authentication in newer versions of the IOS. The OpenSSH client (included with Lubuntu by default) can be configured to connect per host, allowing simple user operation if the hostnames of the managed devices are known by the operator. This leads to the question of how to properly manage an SSH key infrastructure. This is an age-old problem with established best practices that can be found in this NIST document:

https://csrc.nist.gov/publications/detail/nistir/7966/final

Within this document is a reference to another NIST document that I need to keep on my reading list detailing currently recommended key lengths and approved algorithms:

https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final

Lately I’ve been setting up a couple of firewalls on Linux hosts using PF, and find myself looking up the same things over and over.  So here is a post with a couple of resources and the commands I need to remember.

First, the simple PF documentation from within the FreeBSD documentation:

https://www.freebsd.org/doc/handbook/firewalls-pf.html

Second, a really interesting looking manuscript that is more of a tutorial, and dedicated to the PF project:

https://home.nuug.no/~peter/pf/

Lastly, the commands for restarting PF or causing it to reload the rules set due to my changes:

pfctl -F all -f /etc/pf.conf  Flush all NAT, filter, state, and table rules and reload

pfctl -s [ rules | nat | states ]  Report on the filter rules, NAT rules, or state table.

pfctl -vnf /etc/pf.conf  Check /etc/pf.conf for errors, but do not load ruleset.

Today I stumbled on a series of articles detailing the use of the rsyslog daemon.  It looks applicable to many Unix / Linux systems, so here I copy the links:

https://www.linux.com/learn/remote-logging-syslog-part-1-basics

https://www.linux.com/learn/sysadmin/remote-logging-syslog-part-2-main-config-file

https://www.linux.com/learn/sysadmin/remote-logging-syslog-part-3-logfile-rules

https://www.linux.com/learn/sysadmin/remote-logging-syslog-part-4-log-rotation

All 4 articles were written by Chris Binnie at Linux.com in November and December of 2016.

At a previous job I deployed MediaWiki in order to provide our workgroup with a collaborative memory, which somewhere along the way developed into a inventory management too, life cycle planning tool and crude ticketing system.

A very sharing fellow showed me Request Tracker, an open source ticketing tool which does a lot of things better than we used to.  There is a standard version and a version optimized for incident response teams.  Both versions look mature and run on Unix/Linux operating systems.

I’ve continued working with the Security Onion distribution and have just tripped over another Open Source Security Information & Event Management (SIEM) product.  OSSIM can draw information from network equipment (firewalls, routers, & switches), Linux hosts, Unix hosts, and Windows hosts using a variety of methods.  It maintains this data locally in a SQL database for about 45 days, which provides some forensic capability for a small environment.