markofu’s blog

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/lo...

So if you're unlucky enough to follow me on Twitter, you'll have seen that I had a conundrum with my presentation at IrissCon :) After a little work yesterday morning, during IrissCon, I tweaked the presentation and reduced the number of slides and successfully tested my "Security Onion in EC2" demo over the hotel wifi. I even managed to show a few others what I was going to do and received good feedback :) To add to my preparation, during lunch I hooked up my laptop to the main screen in the conference and everything looked sweet, even the "live" demo ( @BrianHonan took some nice pictures also). I was so relaxed this year in comparison to previous years (I only had a 30 minute talk to do, right). Looking at Jason and the Honeyn3t lads (organisers of the CTF this year) , I recognised the bloodshot eyes and I could see the amount of stunning work that they had done (the world map of domination was simply awesome).  My relaxation was commented upon...