markofu’s blog

In case this might help someone-else, if when installing Maltego (or I guess any other application that requires Java) on MAC OS and you see the error below "LSOpenURLsWithRole() failed with error -10810 for the file" this is because you don't have Java installed. The "user docs" actually indicate that Java is required, however, as a male I didn't read them prior to installing because the site says "install as normal" :) Anyway, run something like java -version from the CLI and aut-magically software update will subsequently be launched. The latest version of Java will then be installed like magic :) You can then launch Maltego, woot :D

Receiving mails via LinkedIn is an interesting experience. For example, how many folk actually personalise "contact requests" - from what I see, less than 1%. I typically try to because I think it shows some thought has gone into the request and it's friendly, but then "manners" on the Internet is a very different thing to the real world, right ;-) Anyway, to the point of the blog post. In early November (2012), whilst I was preparing my Security Onion presentation for IrissCon  (why did I bother when my MBP died on-stage), I received a very interesting and personal email via LinkedIn. The email came from a "Senior International Belief Instigator" (let's call him the SIBI - to save me typing) at Riot Games and the email was literally awesome, it hit many of the key points that you'd hope for in a recruiter email but it also had a wonderful tone. In my ignorance, I knew of League of Legends but not Riot (yes, I am embarrassed by that). I r

Introduction Having answered numerous questions on the new and old authori(s|z)ation within MongoDB, I thought I'd write a short blog post explaining how things work as there seems to be some confusion. What's New Prior to version 2.4 , there was a very basic sense of "Role Based Access Controls" (RBAC) within MongoDB as there were only two roles - read readWrite which is quite limited. For example, if the user has "readWrite", that user is essentially "root" and the user can add/remove users as well as inserting data into the database, i.e. there is no role segregation. Version 2.4 added in the following 3 core roles - userAdmin dbAdmin clusterAdmin with a notable extension such that there are now 4 roles that apply across all databases - readAnyDatabase readWriteAnyDatabase userAdminAnyDatabase dbAdminAnyDatabase This increased RBAC is a significant improvement from a security perspective in MongoDB. It is imp

I'm just back from a superb (or in "American" : super exciting) MongoDB London conference. I've been told there were over 500 attendees and as you can see below, the venue was sweet :) I have uploaded my slides to SpeakerDeck, I'm no longer using Slideshare as a repository for my presentations (I just don't think it's as good visually or in terms of a usage experience). Using the MongoDB Monitoring Service (MMS) Securing your MongoDB Implementation Thankfully the two presentations went well and I received great feedback (hey @rozza, no yellow discs buddy - yellow discs indicated a sub-par presentation, blue = good and green = excellent :) ). More importantly, there was no "Black Screen of Death" on the MBP unlike at IrissCon ! Please have a look at the slides and if there are any questions or mistakes, please let me know. Thanks to the whole 10gen team (especially the community folk) for organising such an awesome event and more i

I became a little tired manually downloading pcaps from the various, freely available resources on the net so I added a repo to my very basic github repo so that I could simply `git clone` from wherever I am - assuming decent bandwidth and Github don't get to pissed at storing pcaps - as it's only 1.1gb at present, I doubt they will (/me hoping :) ). I'm not really sure what I plan to do with this repo, I guess I'll extend it and add more as I get around to it. My sole goal at the minute is to use the awesome functionality of Github to manage and modify the content, as well as making it easier for me to remember where the pcaps are ;-)

In my last post , I showed how you can set up MongoDB v2.2 to syslog its logs off to a remote syslog server. As my `tcpdump` snippets show, the syslog messages hit the syslog server tagged as "user.info", which means that they're assigned to the "user" facility with a severity level of "info". I've received a few questions regarding the possiblity of splitting out syslog messages by facility, however, as everything is currently sent to a "user.info" bucket, so-to-speak, this is not possibility. There is a current feature request for this capability and work will be done on this but if this is important for you, I'd strongly encourage you to vote for this feature. In the meantime, however, (whilst not ideal) you can still do some host filtering with rsyslog as outlined here .

As per the MongoDB 2.2 release notes , log output for MongoDB can now be redirected to a remote syslog server. Here is an example configuration. MongoDB Instance MongoDB is started as follows (note the extra `syslog` switch): $ mongod --dbpath=/data/db/syslog --fork --syslog The local "/etc/syslog.conf" file (i.e. on the `mongod` instance) is configured to send everything to the syslog server (10.7.100.20): @10.7.100.20:514 Syslog Server I ran my Syslog server on Ubuntu 12.04. There are a tonne of links out there describing how to install syslog on Ubuntu - see here . The syslog "facilities" are configured in the server's `/etc/syslog.conf` file (I left this as default): ################################################################################# # # First some standard logfiles.  Log by facility. # auth,authpriv.*            /var/log/auth.log *.*;auth,authpriv.none        -/var/log/syslog #cron.*                /var/log/cron.log daem