Added Layer Of Obscurity: Finding a non-standard port for your service
Designing your security model using only obscurity is always a bad idea, but after sound measures have been put in place, an added layer of obscurity might make the service/account harder to find for the malicious, and lower the resources wasted by their brute forcing, etc.
An example would be the changing of private services (e.g. SSH) to run on non-standard ports (I see this frequently recommended as part of hardening guides anyway; there's port knocking too which could be even better, but that's not the point of this post).
In the example of hiding SSH ports, the question then comes: what port to use? One of the many ways is to make use of nmap's frequently used ports list to help make a decision. Nmap scans using the top 1000 frequently used ports in a normal scan (although we change the scan to scan based on any top n used ports too). So we run this in a shell to list the top 1000 (or n of your fancy) used ports:
cat /usr/share/nmap/nmap-services | \
awk '{print $3 "\t" $2 "\t\t" $1}' | \
sort -nr | head -n1000 | less
Let's break this command down:
cat /usr/share/nmap/nmap-services prints out the contents of the nmap-services file (used to track the probabilities of the ports used) to STDOUT.
awk '{print $3 "\t" $2 "\t\t" $1}' formats the contents of the nmap-services for the sort command to work on.
sort -nr sorts the entries by reverse numerical order.
head -n1000 shows only the top 1000 lines of output (change to any number you wish, or remove altogether to see the full list)
less displays the output in a scrollable, searchable manner.
On an ending note, it probably would be a bad idea to go straight for the last entries in the sorted list for your port selections. Remember: we want to be unpredictable, and not simply different.
Splunk 4.2
The next version of Splunk is out!
Amongst the new features that Splunk's advertising, a quick glance through the new version reveals that the revamped management interface might seem to make administering it/clusters easier. Also that the search and reporting features seem to have been beefed up too!
More to come after I poke around some more, and if I have the time to write something 
Network Forensics
Learnt a whole lot from the FOR558 Network Forensics class conducted (by George Bakos, also a real hardcore Linux g33k!) this week, a real eye opener on what can (and should) be done regarding digital evidence from the network: (Manual!) DPI...reverse engineering custom network protocols/tunnels...reconstruction and correlating of network activities from logs/caches... Mad stuff, this is.
Whether or not there'll be opportunities to put these into direct use in the (near) future, will start looking into doing some more network logging for my own analysis and practice. Perhaps some ideas/"research"/tools could come of it as a result?
<brag> On a side note, George gave me his SANS Lethal Forensicator Coin for participation in the class! Really surprised, heh </brag>
More interestingly is how this coin came about:
... in which many in the field call "Nintendo Forensics" where there is too much reliance on automated examinations vs. traditional analysis. The main argument is that too much reliance on automation produces poor reports. ... The term Forensicator stuck and is being utilized in many computer forensics and incident response firms to describe individuals that essential perform the same type of work as "Forensicator Pro".
Have to remember to keep things simple, but yet not to shun a method/technique just because the easiest way to do so is tough (which usually is the case).