I wanted to use variables in a bash script’s for loop inside awk’s print statement.
Here’s an easy way to do it – enclose the bash variable within "’"

Here’s a sample scripts to take a list of IPs and do a DNS lookup and generate a CSV:

for ip in `cat ips.txt`
do
  host $ip|grep -v NXDOMAIN|sed 's/\.$//g'|awk '{print "'"$ip"'"","$NF}'
done

9 hrs down the line I’m still capturing packets, now comes the challenging part-to make the hash tables of raw data! My Rabin’s hash algo seems to be working but the only hiccup that could happen was when the negative hash values are obtained. I don’t know whether it is a bug in my code or what but I got negative values for Rabin’s Hash when I gave the string “this is test”! This is gonna test me for sure.

I like using dcfldd for creating the raw images, because it shows a nice status…it’s interesting to see progress.

dcfldd if=/dev/sda of=/mnt/sdb1/filename.dd hash=md5 md5log=hashfile.md5 conv=noerror,sync bs=4096

It’s the ‘bs’ (stands for bytesize) that makes the difference (…always does doesn’t it ;-).

Autopsy – The forensics browser always uses the ~/.autopsy as the base directory for storing the files from the cases. The following command is helpful in changing the directory in which the cases should be stored:

./autopsy -d /mountpoint/dirname

The exiftool is a cool application that can read meta-information to determine the different types of files.

Last night I was trying to get a VeriSign issued SSL certificate installed on my ASA using Cisco ASDM 6.2. I installed the Intermediate CA and the CA certificates all installed. I then imported the SSL certificate into the “Configuration -> Device Management -> Manage Certificates -> Identity Certificates” but it did not seem to work. I kept getting an error “Failed to parse or verify imported certificate”. The certificate was in the .p7b form. Changing the format of the certificate to X.509 Base64 Encoded format resulted in acceptance of the certificate.
I sincerely hope that Cisco alters its error messages to accurately reflect that .p7b is not a format supported by them.

Update: This link has the information on how to install SSL certificates on ASA:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00809fcf91.shtml

SSH is an excellent piece of software which can help you do a lot of things such as have encrypted shells etc. But what makes SSH incredibly flexible is having tunnels.

A typical ssh tunnel works from the client to the ssh server and it forwards a local port on the client to the server seamlessly.

client ----> ssh_conn ----> ssh_server
client --> tunneled_port --> ssh_server

ssh -L 10000:localhost:10000 username@ssh_server

This connection creates a tunneled port on client:10000 i.e., anything sent to this port appears as if it’s automatically sent to ssh_server on port 10000. The localhost here is confusing, but think of it as….”what is localhost for ssh_server?”. It would be the ssh_server itself, right?
If you do a netstat on the client, you see a listener on the port 10000/tcp.

Now comes the more interesting reverse tunnel. The reverse tunnel is different in that, you have a tunnel being initiated by the client that says to the ssh server, “Hey, I’m initiating this connection that will allow you to automatically access a port on *me* after *I* initiate the connection?” (confused!!?!)

client ---> ssh_connection ---> server  ---+
                                           |
client <-- tunneled_port  <----- server ---+

ssh -NR 10000:localhost:10000 user@ssh_server

Here the meaning of localhost is slightly different, though.  The “localhost” means what is localhost for the client (and not on the server as in the previous case)!   So what you’re saying is, “Hey SSH server, I’m initiating this connection to you but if you connect to your port 10000 you will get a tunnel to *my* port 10000.”  If you do a netstat on the server you see a listener on port 10000. Isn’t it great that you can make the server listen to a port which acts as a tunnel to you…so anyone on the server can seamlessly connect to you even though technically you were the client!

There has been a lot that’s being said about the use of AI in Cyber Security. This is for good reasons – people have said here and folks in information security (as we have called “cyber security” for decades now) have experienced first-hand. It’s only natural that already stretched InfoSec teams look at AI as the “saviour” to the skills / personnel gap to close it. Then again, there is a lot being said about companies selling products as “AI enabled” too.

But realistically speaking are there some things traditional organizations (“non-AI”) can do to actually do what many of these “AI enabled” products do? I wouldn’t have written this blog post now would I if the answer was anything but yes! 🙂

Let’s look at them:

1. Anomaly Detection – this is age old! Almost all security tools that “alert” us on something are essentially using this. How well? That’s debatable. The kind of anomaly detection that I am talking about is simple (but different). For example, abnormal login attempts on your Internet-facing systems is anomaly detection. So is abnormality of DNS queries. Your Cloudtrail logs (in AWS) showing an inordinate spend on EC2 instances is also anomaly. A abnormally small amount of time spent between a git commit and a production deployment of that commit is also odd! Your SaaS or Okta bill being high or your APIs getting throttled (without any known changes) are all anomalies. The response time for these depends on whether or not you have been able to automate these anomalies. The day you automate these “known” anomalies you are already doing what many of these “AI enabled” products are doing today (after of course charging you an arm and leg!)
2. UBA / User behavior analytics – a lot of products do that but the most simplistic things are reduction of logins / preventing logon from areas where you do not expect your users to originate from. This is “reduction” of attack surface. Is that foolproof? Hell no! Why? Generally, speaking adversaries do not attack systems from their home computers. Adversaries operate by using trampoline servers (sometimes layers of them) to send the attack from the “attacker controlled bots”. But it reduces your area of concentration. And then you can use UBA more effectively since you do know where your users are expected from at a macro level. To improve your “AI-ness” you can then add capabilities which are able to say not at a macro-level but on a per user level where that specific user is expected to originate from. And if it looks abnormal (or anomalous) then ask them to step up. There are numerous vendors in this space as well as products on the cheap which you could do. There are open source libraries that can also help you do that on the cheap. Again, something very expensive “AI enabled” products can do too.

I am sure there are many other things that as an organization one can start doing. Obviously, at the end of the day, every initiative takes resources and by no means are any of these simple but YMMV depending the size of your datasets, users, and organizations.

I’ve been waiting for a good writeable NTFS file system. I used Captive-NTFS but wasn’t really happy with it. Lots of errors when I used it last in July – August 2006 (if I remember the timeline correctly). Now we have a great writeable NTFS file system for Linux called NTFS-3g.

On my Kubuntu machine, I installed it as:
sudo apt-get install ntfs-3g
I also installed ntfsprogs available from http://packages.debian.org/unstable/otherosfs/ntfsprogs for my Kubuntu machine. The use for the NTFS-Progs is that you can use utils like ntfs fix if your mounted NTFS is tainted. If you do not have a latest version installed of ntfs-progs you might run into issues where ntfsfix might not work. Use the latest version from the above link. You might need to install libntfs9 from the debian package as
dpkg -i libntfs9_1.13.1-6+b2_i386.deb
Now I was getting tired of having to unount my NTFS partitions first and then re-mount them in ntfs-3g mode to make them writeable. So I installed ntfs-config and also the patched pmount debian package. Then all you have to do is run ntfs-config and choose the option that suits you best.
Now all my USB drives that have NTFS on it mount in read/write mode!