Smathermather's Weblog

Remote Sensing, GIS, Ecology, and Oddball Techniques

Archive for the ‘Security’ Category

Arming an escaped convict– giving Artillery to a Jailbroken iPod Touch

Posted by smathermather on March 26, 2012

Some achievements are too easy, but that shouldn’t be construed as complaint. This one was pure fun.

Keeping in mind dire warnings of the dangers of rooting my iPod from security professionals I know and respect, I decided to root a spare iPod, so I wouldn’t have to worry so much about security for my primary one with all its precious info.

Once rooted, how would one secure such a device? Let’s throw a honeypot/monitoring/prevention tool at it, say Artillery.

First the rooting/jailbreaking. I used http://blog.iphone-dev.org/tagged/redsn0w to jailbreak my iPod, as it matched up with my iOS version in the list of jailbreaking software at http://en.wikipedia.org/wiki/IOS_jailbreaking. It was wicked easy. Just follow the instructions. At the end it installs http://cydia.saurik.com/ which is an alternate app store/package management suite. For the linux users out there, this is very familiar. There are three levels to the package categorization, User, Hacker, and Developer. If you want Python like I did, you need to choose Developer.

Next Python. If you install Python, it auto installs SSH. This is good. What’s bad is SSH is automatically turned on– I do wish there was a graphical (iOS) interface for turning SSH on and off, so I could turn it on when only on a dedicated wifi network. Anyway, log in quickly using these instructions: http://cydia.saurik.com/openssh.html and change your password to something secure. Better yet, change your password and then generate some keys to use for login, but that’s another post.

You will also need to install subversion from cydia, plus I recommend a text editor. I chose vim, but I think I’ll probably switch to a less painful vi-like editor soon.

Now the rest is basically the directions on http://secmaniac.com… .


iPod:~/Library root# svn co http://svn.secmaniac.com/artillery artillery/

iPod:~/Library root# cd artillery/
iPod:~/Library/artillery root# ls
artillery.py  config  database    readme    remove_ban.py  restart_server.py  setup.py  src
iPod:~/Library/artillery root# ./setup.py

I did run into one problem which I haven’t solved yet:


iPod:~/Library/artillery root# Unhandled exception in thread started by <function ssh_monitor at 0x61d41c>
Traceback (most recent call last):
File &amp;quot;/private/var/artillery/src/ssh_monitor.py&amp;quot;, line 42, in ssh_monitor
for line in fileopen1:
UnboundLocalError: local variable 'fileopen1' referenced before assignment

So, I hacked it for the moment:


iPod:~/Library/artillery root# vim /var/artillery/config

and turned off brute force monitoring. I suspect I can just modify ssh_monitor.py and define fileopen1 in the correct sequence, but haven’t looked under the hood yet.


# DO YOU WANT TO MONITOR SSH BRUTE FORCE ATTEMPTS
SSH_BRUTE_MONITOR=OFF

Now to restart Artillery:


iPod:~/Library/artillery root# python /var/artillery/restart_server.py

Now, I didn’t really want to ban my laptop, so I opted instead to ban my other iPod by using Scanny http://itunes.apple.com/us/app/scany-network-port-scanner/id328077901?mt=8 :

Checking the ban list:


iPod:/var/artillery root# vim /var/artillery/banlist.txt

I see my IP in the banlist. No banning in place though, just constant honeypots. Maybe I need to add iptables… .

–edit–BSD, not linux… Different firewall rules, ala: http://modmyi.com/forums/iphone-ipod-touch-sdk-development-discussion/733566-iptables-iphone.html

Posted in Security | Leave a Comment »

Beefing up the firewall using Artillery — part 2

Posted by smathermather on March 18, 2012

So, how easy is it to install and use Artillery?  Really easy.  I’ve now installed it on Debian, Ubuntu, and Mac OS X.  But, assuming you don’t believe me, I’ll walk you through the steps.  Warning for my advanced readers– this is an entry level post… .

Artillery is maintained in a subversion repository, so the best way to get it and keep it up-to-date is the subversion.  On a Mac, you already have subversion installed, so downloading it is as easy as going to the terminal, and running:

svn co http://svn.secmaniac.com/artillery artillery/

This will create a subdirectory called artillery.  Change to that directory:

cd artillery/

And look at the contents:

You should see the following:

artillery.py        database        remove_ban.py        setup.py
config            readme            restart_server.py    src

To install, simply run:

sudo ./setup.py

If this doesn’t work, try:

sudo python setup.py

Follow the prompts, and you should be set up. If you want to change the default configuration, have it e-mail you when there are changes to the monitored directories, etc., type:

sudo cp /var/artillery/config /var/artillery/config.backup
sudo chmod -w /var/artillery/config.backup
sudo nano /var/artillery/config

(Of course if you feel that nano is beneath you you can use vim or emacs I guess… .)
When you’re done changing the configuration, just restart the server:

sudo python restart_server.py

Posted in Security | Tagged: , | Leave a Comment »

Beefing up the firewall using Artillery

Posted by smathermather on March 13, 2012

We have a project that an external group is helping with, and wanted a hardened machine for them to ssh into without worries.

For projects like this, I recommend you wander over to secmaniac to see Dave Kennedy’s blog on security related stuff.  He’s got out a relatively new tool (a few months old) that’s (a first for him) on the defensive side of security (as opposed to the breaking stuff side of security) called Artillery.  Now I know, you are probably a geospatial professional and therefore leave the security to someone else (if at all).  Don’t.  It’s no fun to be pwned.

Anyway, I deployed it on Ubuntu 11.10 with great ease, just svn a copy and follow the directions in the readme.  It will re-write your firewall rules, leave some ports of your choice open for sniffing, and then write a permanent deny entry for connecting on your machine’s ports.  I banned my own machines pretty quickly before remembering to whitelist… .  In Dave’s words:

“Artillery is a tool designed to confuse attackers and block them before an actual attack occurs. Artillery is a newer project and does a combination of host monitoring, security hardening, and honeypot type defensive strategies. Artillery has an active component where if it detects a connection on a given port that is triggered as a honeypot, it will automatically block the offending IP address.”

I’m hoping to modify it a bit to handle whitelisting dynamic IPs, but I don’t think I even need to poke under the hood to do that– just write a script to modify the config file whitelist and reload.

While I advocate you look into this tool, do watch the licensing– while released under a modified BSD, it does have a clause requiring a hug and a beer be offered if you meet Dave in a bar.  Don’t use it if you aren’t comfortable with the terms.

Posted in Security | Tagged: , | 1 Comment »

#OGC Web Services and #Security

Posted by smathermather on March 6, 2012

A while back, I had a (somewhat cryptic) post on OGC services and security.  A couple months later, I saw this post on GeoSolution’s site on GeoServer security and the ins and outs of various options, from native to proxied security.  It is quite a bit more nuanced than my own… .  I recommend you read it, even if you don’t use GeoServer– it is enlightening about the specific problems of securing spatial data that go beyond the simple authentication/authorization models that apply to most other datasets.

Posted in GeoServer, Other, Security | Tagged: , , | Leave a Comment »

Postgis for breakfast: ST_Donut — Revision

Posted by smathermather on October 27, 2011

A commenter on my last ST_Donut post pointed out that we were essentially using not one but two buffers and and ST_Intersection to test where a point lay.  Bad Spatial SQL. Very bad Spatial SQL. Actually, at Paul Ramsey’s PostGIS for Power Users presentation at FOSS4G this year, I think he mentioned not doing that very thing, and I chuckled to myself, “Well, even I know better than that.” So much for false pride.

So here’s the revision, adapted as before from Sorokine:

Revised Oct 28th

Posted in Analysis, Database, Ecology, PostGIS, Security, SQL | Tagged: , , , , | Leave a Comment »

Postgis for breakfast: ST_Donut

Posted by smathermather on October 6, 2011

This post typed into my iPod as an homage. Assisted today by my collegue, J. Stein.

Moderate obfuscation of locations is an important technique for the protection of data, say something sensitive like the nesting locations of the very rare and strange fuzzy-bellied gnat catcher. We still want to display the data, but want to make it slightly wrong.

A naive approach would place it a random distance away, i.e. Location +- random()*500ft. Unfortunately, this could be a distance as small as 0 ft away, not an outcome we want.

So, instead we constrain our placement of random points to a minimum and maximum distance away. Enter ST_Donut. We need to construct a donut, and then place a random, ahem, sprinkle on it, and return a point:


CREATE OR REPLACE FUNCTION ST_Donut (
  geom Geometry, dough numeric, nut numeric, geom2 Geometry 
 )
 RETURNS Geometry
 AS $$
DECLARE

  donut Geometry;
  
BEGIN  
  donut = ST_SetSRID(ST_Difference(ST_Difference(ST_Buffer(geom, dough), ST_Buffer(geom, nut)), ST_SRID(geom)),geom2);

RETURN donut;
END;

$$ LANGUAGE plpgsql;

 

Thanks to sorokine:

 CREATE OR REPLACE FUNCTION RandomPoint ( geom Geometry ) RETURNS Geometry AS $$ DECLARE maxiter INTEGER := 1000; i INTEGER := 0; x0 DOUBLE PRECISION; dx DOUBLE PRECISION; y0 DOUBLE PRECISION; dy DOUBLE PRECISION; xp DOUBLE PRECISION; yp DOUBLE PRECISION; rpoint Geometry; BEGIN -- find envelope x0 = ST_XMin(geom); dx = (ST_XMax(geom) - x0); y0 = ST_YMin(geom); dy = (ST_YMax(geom) - y0); WHILE i maxiter THEN RAISE NOTICE 'number of interations exceeded max'; END IF; RETURN rpoint; END; $$ LANGUAGE plpgsql;

Mmmm, donut…

Edit: October 8, 11:06

The real function is:


CREATE OR REPLACE FUNCTION ST_Donut (
  geom Geometry, dough numeric, nut numeric, geom2 Geometry
 )
 RETURNS Geometry
 AS $$
DECLARE

  donut Geometry;

BEGIN
  donut = ST_SetSRID(ST_Difference(ST_Buffer(geom, dough), ST_Buffer(geom, nut)), ST_SRID(geom));

The code I had in the block at the top is the overloaded version. In this case it can take in two geometries; the second geometry is a limiting geometry– say a boundary outside of which you don’t want to place the randomized point. PostgreSQL let’s you overload functions, so if two functions have the same name, but different variable input, whether by type or number or both, it will run the function that matches the name and inputs. This allows us to create two functions with the same name, but slightly different purposes. BTW, this overdetermined function should probably check to see if the second geometry is a polygon, but it does not. Buyer beware… .

Posted in Analysis, Database, Ecology, PostGIS, Security, SQL | Tagged: , , , , | 3 Comments »

OGC Web Services and Security

Posted by smathermather on October 5, 2011

I’ve been starting to inform myself on authentication/authorization schemes for OGC Web Services (OWS). This is because, while I’m pretty pleased with most of the functionality basic mapping of our internal GeoExt/GeoServer/PostGIS stack, user editing is the next natural step. As it is now, users can access a variety of really detailed useful layers, print to PDF, and for the most part the interface is simple and intuitive. The cartography is looking pretty good too. Some additional thought might be put into controlling which layers are available with other layers to ensure great cartographic output at all times, but baring some additional event handlers, and thus a much better JavaScript writer than I am, this won’t happen soon.

So, I turn my attention to markup and layer editing. Authentication and authorization must precede this. In my searches, I found this summary document from CamptoCamp from FOSS4G 2011 2010, with some great schema on the different options. The basic breakdown as I read it is this: there are two categories of protection: integrated authentication, such as the GeoServer Security Subsystem, and proxied authentication, such as 52˚ North WSS, SecureOWS, or GeoShield. The proxied systems can be further subdivided into systems which create an https tunnel with separate client and server software to provide a decoding localhost to prevent packet sniffing (i.e. SecureOWS), a web security service (WSS) service layer (i.e. 52˚ North WSS), and GeoShield– which can either act as a proxy or a (soon to be released) plugin for GeoServer’s existing subsystem (if I understand things correctly– which by things I mean this document from FOSS4G 2011, as I missed the presentation itself).

The nice part for SecureOWS, as I see it, is that it creates a tunneled connection, so if you’re interested in preventing sniffing, man-in-the-middle attacks, etc., the extra complication of running a localhost decoder for SecureOWS might be worth it.  It’s a minor complication, but it is not as simple as HTTP BASIC authentication, which is what e.g. the GeoServer security sub-system does.  SecureOWS also should work with any client software that can access OWS services.  What I like about GeoShield is the ability to use Common Query Language (CQL) (and hopefully ECQL) to constrain almost every bit of behavior, from the extent returned, to the styles available, etc. etc., all that using a language construct common to GeoServer users, in addition to service level stuff like GetFeatureInfo, etc..  And finally, it seems that 52˚ North WSS (or WSS setups in general) are meant to handle end to end security, including encryption.  I don’t know if this level of complexity constrains potential client software, but it seems like it could.  This point might be moot, if the objective is to use a modern browser as the client, but could matter with legacy desktop applications (I’m now into the territory of suppositions and guesses, so please correct me if I’m wrong).  That said 52˚ North WSS also has fine control over geographic extent, service level, layers, etc., much as GeoShield.

What’s my conclusion?  I wish I knew.  I’m going to have to do some yak shaving tests.  GeoShield passed initial tests.  It seems, so far, to be easy to set up and maintain, and the Ext “Desktop” look and feel is downright cute.  GeoServer’s subsystem can authenticate against other services, such as LDAP, so I’ll be playing with that too.  We’ll see how far I get from there, and whether I test the encrypted options (SecureOWS and 52˚ North WSS) to ensure end-to-end security as well.

Posted in GeoServer, Other, Security | Tagged: , , | 4 Comments »