For Ubuntu/Debian users, the APT package to install would be:

$ sudo apt-get install geoip-bin

MaxMind has (free and commercial) databases that can be queried using these command line tools in Linux. Installing the geoip-bin package installs the free version of the country database, but you don't need to stop there!

By default, the free IP-Country database is situated at /usr/share/GeoIP/GeoIP.dat. Do note that the APT package for it is NOT updated automatically, so you will need to update it yourself.

Grabbing hold of the other two free databases (they're updated monthly I think) and placing them the shared folder. IP-ASN is a nice way to quickly determine the ownership of an IP address, which you can follow up with actually looking through the WHOIS info should that be too generic. IP-City info comes with geolocation (lat-long coordinates!) info, which is very nice for plotting IP address lists on nice maps for analysis, or for the less technically inclined (or your bosses ).

$ ls /usr/share/GeoIP/
GeoIPASNum.dat  GeoIP.dat  GeoLiteCity.dat

It appears that GeoIP and GeoIPASNum are queried automatically by default

$ geoiplookup 8.8.8.8
GeoIP Country Edition: US, United States
GeoIP ASNum Edition: AS15169 Google Inc.

Now let's try querying for basic location information:

$ geoiplookup 8.8.8.8 -f /usr/share/GeoIP/GeoLiteCity.dat
GeoIP City Edition, Rev 1: US, N/A, N/A, N/A, 38.000000, -97.000000, 0, 0

What are the MaxMind database versions currently "installed"?

$ geoiplookup 8.8.8.8 -v
GeoIP Country Edition: GEO-106FREE 20120403 Build 1 Copyright (c) 2012 MaxMind Inc All Rights Reserved
GeoIP ASNum Edition: GEO-117 20120402 Build 1 Copyright (c) 2012 MaxMind Inc All Rights Reserved

$ geoiplookup 8.8.8.8 -f /usr/share/GeoIP/GeoLiteCity.dat -v
GeoIP City Edition, Rev 1: GEO-533LITE 20120403 Build 1 Copyright (c) 2012 MaxMind Inc All Rights Reserved

If you want more verbose reporting (shows the IP address block that matched the query):

$ geoiplookup 8.8.8.8 -i
GeoIP Country Edition: US, United States
  ipaddr: 8.8.8.8
  range_by_ip:  8.7.211.0 - 8.14.223.255
  network:      8.8.0.0 - 8.11.255.255 ::14
  ipnum: 134744072
  range_by_num: 134730496 - 135192575
  network num:  134742016 - 135004159 ::14
GeoIP ASNum Edition: AS15169 Google Inc.
  ipaddr: 8.8.8.8
  range_by_ip:  8.8.8.0 - 8.8.8.255
  network:      8.8.8.0 - 8.8.8.255 ::24
  ipnum: 134744072
  range_by_num: 134744064 - 134744319
  network num:  134744064 - 134744319 ::24

$ geoiplookup 8.8.8.8 -f /usr/share/GeoIP/GeoLiteCity.dat -i
GeoIP City Edition, Rev 1: US, N/A, N/A, N/A, 38.000000, -97.000000, 0, 0
  ipaddr: 8.8.8.8
  range_by_ip:  8.7.228.0 - 8.8.37.255
  network:      8.8.0.0 - 8.8.31.255 ::19
  ipnum: 134744072
  range_by_num: 134734848 - 134751743
  network num:  134742016 - 134750207 ::19

Cooking all of this with a little CLI script-fu for mass lookups!

$ output=outputfile.csv; echo "ip,country" > $output; for  i in $( cat /path/to/list-of-ips.txt ); do echo "$i,\"$( geoiplookup -f /usr/share/GeoIP/GeoIP.dat $i | cut -d' ' -f4-99 )\"" >> $output; done

HTH, and have fun!

While I did dabble with OpenVPN sometime back, protocols like L2TP would be more commonly supported, especially on the "venerable" iOS device (iPhone, iPod Touch, iPad), and on Windoze machines, Android, etc.

This post will be on what you'll need to setup a L2TP server in Ubuntu for iOS devices to connect to. The server is assumed to be directly accessible from the internet. Some of the stuff are taken from other places, for my own reference here. There's also a great write up on IPsec over at Steve Friedl's Unixwiz.net Tech Tips site, for you geeks who actually want to understand a little regarding what you're using (high five!).

The L2TP server setup mainly comprises of three parts actually (surprise!). The L2TP daemon, IPsec daemon and the PPP daemon (providing DHCP services).

Main steps:

1. install openswan (for IPsec), xl2tpd (L2TP) and ppp
2. configure
3. configure the (Linux) kernel to turn on IP forwarding, and IP masquerading if the iptables firewall is on
4. configure the device itself
5. take a break, have a pina colada or something
6. profit!

Step #1: install

sudo apt-get install openswan ppp xl2tpd

Say "No" to creating a certificate when installing openswan. You will be using a pre-shared secret (password) instead.

Step #2: configure
The config files:

---
/etc/ipsec.conf

version 2.0

config setup
  nat_traversal=yes
  virtual_private=%v4:10.0.0.0/8,%v4:192.168.1.0/16,%v4:172.16.0.0/12
  oe=off
  protostack=netkey

include /etc/ipsec.d/l2tp-psk.conf

---
/etc/ipsec.d/l2tp-psk.conf
(change left & leftnexthop values accordingly)
left is your external interface IP
leftnexthop is the router for the external interface

conn L2TP-PSK-NAT
  rightsubnet=vhost:%priv
  also=L2TP-PSK-noNAT

conn L2TP-PSK-noNAT
  authby=secret
  pfs=no
  auto=add
  keyingtries=3
  rekey=no
  type=transport
  left=192.168.1.22
  leftnexthop=192.168.1.1
  leftprotoport=17/1701
  right=%any
  rightprotoport=17/%any
  dpddelay=15
  dpdtimeout=30
  dpdaction=clear
  #Uncomment the line below for OSX on MAC?  untested!
  #rightprotoport=17/0

---
/etc/xl2tpd/xl2tpd.conf
(change ip range & local ip)
Important: "local ip" value must be outside "ip range"

[global]
ipsec saref = yes
[lns default]
ip range = 192.168.1.231-192.168.1.239
local ip = 192.168.1.230
refuse chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

---
/etc/ppp/options.xl2tpd
(change ms-dns value to point to the relevant DNS resolver for the server)

require-mschap-v2
ms-dns 192.168.1.1
asyncmap 0
auth
crtscts
lock
hide-password
modem
debug
name l2tpd
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4

---
/etc/ppp/chap-secrets
(change and create username & password values as needed)
In the example below, username=test and password=testpass
Important: The IP address ("192.168.1.233") for each user must be in the "ip range" from the /etc/xl2tpd/xl2tpd.conf setting. Repeat for additional users using different IP addresses within the range.

test l2tpd testpass 192.168.1.233
l2tpd test testpass 192.168.1.233

---
/etc/ipsec.secrets
(change IP address to your external IP, and the secret "TestSecret" to something else)

192.168.1.22   %any:  PSK "TestSecret"

---
Restart the daemons after configuring. Remember to configure your firewall for inbound access on UDP/500, UDP/4500 and UDP/1701 too.

sudo /etc/init.d/pppd-dns restart
sudo /etc/init.d/xl2tpd restart
sudo /etc/init.d/ipsec restart

Step #3: configure IP forwarding
edit this file below, and add in these lines above the "exit 0;" line in the file (the last line)
/etc/rc.local

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

after editing the file, run it once first

sudo /etc/rc.local

Step #4: configure your device
iOS (iPhone, etc.) settings are below, the settings for desktops like Windows should be similar. You can set them in iOS devices under Settings > General > Network > VPN > Add VPN Configuration...remember to change the example accordingly to what you set in your own configuration files above (you didn't use the sample configuration flies wholesale...did you?)

L2TP
Description: <as you wish>
Server: <server's external IP address>
Account: test
RSA SecurID: OFF
Password: testpass
Secret: TestSecret
Send All Traffic: ON
Proxy: Off

Step #5: take a break
You've survived! Now take a breather

Step #6: profit!
Turn on the VPN by activating the slider in Settings, and enjoy!

HTH.

This is another scratchpad post: little to no explanation/breakdown on the script involved (unless there's the "impetus" to elaborate in future). Feel free to ask/discuss in the comments section below though.

Any user who logs in should trigger the sending of the notification email from the server immediately, and if it wasn't an expected login, well at least you'd know it's time to trigger some incident response processes.

As an improved version of the old post on the same topic, this script similarly is to be appended to /etc/profile or the relevant ~/.bash_profile per user.

echo -e "$(hostname) shell access\n$(date)\n$(who)\n\
$(for i in $(who|cut -d"(" -f2|cut -d")" -f1|cut -d":" -f1|sort -u);
do echo -e "==========\nwhois $i"; whois $i;
echo -e "\n=====\nreverse $i"; dig -x $i;
done;)" | \
mail -s "$(hostname) alert: shell access from \
$(who|cut -d"(" -f2|cut -d")" -f1|cut -d":" -f1|tr "\n" " ")" \
'youremail@domain.com'

Changes namely are the adding of whois and reverse IP (DNS PTR) lookups for all IP addresses currently logged on via SSH, and also the use of the more readable $() Bash command substitution expansion rather than the backtick (`).

You will need to have installed the mailutils package (apt-get install mailutils), and probably a MTA like postfix or exim too.

HTH.

Edit 30 Apr 2012: small bug fix in the sequence to extract all IPs from the who command output.

In the various infosecurity circles, it is not uncommon to see various people and organizations contributing to community: be it in the form of knowledge/HOWTOs, or discussions, or tools written and released.

While commercial offerings (courses, products, solutions) have their place. It is pretty much the case everywhere to see that most people get started off, and maintain, their training and equipping in the "open source"/free realm.

As a sysadmin turned webappsec ethical hacker turned DFIR geek, the situation is very much the same too. Much of what I know came thanks to those who shared selflessly with the community.

I'm very much a tools kind of person, which is also why I see the scale as from one who only uses (i.e. leeches ) to the ones who know enough to modify/add on to existing tools, to the ones who get their hands dirty, implementing the tools that they envisioned themselves. This is also one of the scales along which I would want to progress professionally: from one who feeds/leeches off the feeders, to eventually feeding the community.

At what stage am I at now? Probably the "tool hacker" kind of stage, although I've been leeching too much of late! Time will tell if I move (up or down this scale), or if priorities change altogether. But whichever the case, it should always hold true that we need to give back to community with our work. And what better way than to start off by giving back the same way we learnt the ropes ourselves?

Along the way in my work life (so far), I have been asked the question "What do you want to be working as in the end?"

That question has never been of prime importance to me, though for personal preferences I'm pretty sure I'd like to be in the infosec industry (as of now I guess?).

The more important guiding principles/question would be "Why do you work?"

Got a good reminder today regarding some core reasons for working:

1. To care for family (eg. put food on the table)
2. To care for the church (people, work)
3. To be of use to society with the work done

I left my first job because it stopped fulfilling all three conditions. Will need to keep on remembering these as I continue to slog work for the most part of my remaining years.

Log analysis is (the) trying to make sense of system and network logs.

Computer forensics is (the) application of the scientific method to digital media in order to establish factual information for judicial review.

So...

Log forensics is (the) trying to make sense of system and network logs, in order to establish factual information for judicial review.

Makes sense, maybe I've been googling for the wrong keywords all this time! Till of late, I've been looking at this field largely from a data mining viewpoint.

Just like in incident response, two things held true:

• If you don't have a "incident" response plan, you're only going to panic (a lot more) when it happens.
• Doing an AAR helps!

There're things that can be done to make the loss/theft of your phone a lot less traumatic, and possibly less painful if you really don't get your phone back. They happen to be the things that you could do when you get a new phone.

Preparing for what should not happen:

• Note down IMEI of phone (dial *#06#)
• Set up phone tracking/remote lockdown. Apple users have MobileMe / iCloud for iOS. There are ways to do so for Android too. Remember to set a good password which is not reused anywhere else!
• Note down details of the taxis that you board (taxi company, license plate, make/model of taxi). Takes getting used to though.

What to do when phone's stolen/lost (in order)

1. DON'T PANIC, knee jerk reactions are not what you want!
2. Recall when you last used/saw the phone. Retrace your steps and narrow down the possibilities on where to search. Confirm that it was indeed dropped somewhere/in the taxi.
3. Lock phone remotely if you can, and haven't locked it already (Apple's Find My iPhone allows you to do that if you've set it up already). For the average Joe who picks up the phone, it makes the world of difference between a phone that he/she can use straight away and one that he/she is better off returning.
4. Call in 5-15 minute intervals to locate/get someone's attention to the phone. Don't call non-stop as there's no point in spamming your phone, especially if it's going to result in a flat battery which is worse off.
5. Leave a message for any would-be finder to be able to contact you and return the phone. You could use the phone tracker, or simply SMS/WhatsApp/etc. Many phones show the message contents without having to unlock the screen (!!!).
6. Locate the phone, mainly to see if it's trivially retrievable (left on the floor somewhere, or taxi's stationery), or for the police report to come later.
7. Call for help (taxi company). There's an awesome list of Singapore taxi companies' numbers out there.
8. Lodge reports especially when your chances of getting the phone back are slim, or when it's been a while since you've been able to find it/get it back. For the phone itself (property) and any other items of importance that was lost together like identity cards, call the police or make use of the SPF's e-services to lodge a report. Credit cards that were with the phone should be cancelled regardless of whether you get the phone back or not since there's a high likelihood that someone else has seen your CC number and CVV. You do NOT want to go through additional heartache and trouble of undoing credit card transactions by the unscrupulous.

That's all for now. Stay safe, and stay calm

Edit: I guess if this happens you could just skip straight to locking the phone and calling the police.

Also first run in bloody hot weather, thank God we didn't get heat stroke or anything.

While it is really sexy (oh yeah!) to be able to dig out stuff from a computer that Joe or that pesky malware writer tried to hide, responding to incidents requires information to be surfaced as much and fast as possible in order to solve the mystery and contain the damage. And for organization-scale incidents, one great source of information would be the logs generated from the various endpoints/perimeter devices.

So far there's the area of SIEMs and logs management, where we get the heavyweights like Anton Chuvakin. The closest could perhaps be SANS' network forensics course offerings, but the coverage is glancing at best. But looking for discussions in terms of analyzing logs specifically for DFIR, zilch. Perhaps I'm looking at the wrong areas, if so do let me know

As with many security-related domains, the more an area is publicly shared, researched and discussed, the more the good guys stand to gain. The flip side argument being that the bad guys are reading the same stuff too, but that's another topic to be visited another time.

Till then, will share whatever I can about this area that I've learnt so far. It's really a curious monster in itself amongst DFIR efforts.

DShield.org in collaboration with SRI International has established a new experimental custom source address blacklist generation service available to all DShield.org contributors. This new service utilizes a radically different approach to blacklist formulation called Highly Predictive Blacklisting. Each DShield contributor can now access a unique HPB (instructions below) that reflects the most probable set of source addresses that will connect to that contributor's network over a prediction window that may last several days into the future.

Highly predictive blacklists employ a link analysis algorithm similar to Google's PageRank scheme used to find the most relevant web pages given a user's query. Similar to a web query, DShield contributor's firewall logs are cross-compared in search of overlaps among the attackers they report. Each attacker address that is included in an HPB is selected by favoring those ad-dresses that are encountered by other contributors that share degrees of overlap with the HPB owner.

How does it work (for non math geeks ): We compare your firewall logs to firewall logs submitted by others. If you and other submitters are hit on similar ports, then your are more likely to be attacked by the same IPs. Your personal "HPB" is created from the IP addresses that target submitters with similar reports as you.

While this is directly useful to firewall administrators, the concept could potentially be extended to other domains/uses too. Filing this under "bag of tricks" for now