2019-01-11 21:06:00
So far I've built a few VMs in my homelab, to house my AD DS and AD CS services (the Directory Services and PKI respectively). There's also a few CentOS 7 boxen spinning up to house Graylog and ElasticSearch.
Up until this point, all these VMs were getting their IP addresses from our home's internal network infrastructure. Of course it's always a bad idea to mix production and dev/test environments, so I've set up segregation between the two. The easiest way to achieve this will also help me achieve one of my goals for 2019: get acquainted with the pfSense platform.
pfSense is a BSD-based, open source platform for routers/firewalls that can be run both as a VM or on minimalistic ARM-hardware. In my case, I've done a setup comparable to Garrett Mills' example on Medium.com. In short:
BAM! The dev/test VMs are now tucked away into their pocket universe, invisible to our home network.
EDIT:
The pfSense folks also provide nice documentation on setting up their product inside VMWare ESX.
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2019-01-10 21:47:00
For the past X years, I've ran my homelab on my Macbook Air. I've always been impressed with how much you can get away with, on this light portable, sporting an i5 and 8GB of RAM. It'll run two Win2012 VMs and a number of small Linux hosts, aside the MacOS host.
But there's the urge for more! I've been playing with so much cool stuff over the years! I wan't to emulate a whole corporate environment for my studies and tests!
Like the OpenSOC folks, I've been eyeing those Skull Canyon Intel NUCs. They're so sexy! Tiny footprint, combined with great performance! But they're also quite expensive and they don't have proper storage on board. My colleague Martin put me on the trail of local refurbishers and last week I hit gold.
Well... Fool's Gold, maybe. But still! It was shiny, it looked decent and the price was okay. I bought a refurbished Dell R410.
Quick specs:
Yes, it's pretty old already (generation 11 Dell hardware). Yes, it's power hungry. Yes, it's loud. But it was affordable and it's giving me a chance to work with enterprise hardware again, after being out of the server rooms for a long while.
After receiving the pizza box and inspecting it for damage, the first order of business was to setup its iDRAC6. iDRAC is Dell's solution to what vendors like HP call ILO: a tiny bit of embedded hardware that can be used across the network to manage the whole server's hardware.
The iDRAC configuration was tackled swiftly and the web interface was available immediately. It took a bit of digging in Dell's documentation, but I learned how to flash the iDRAC6 firmware so I could upgrade it to the latest (2.95) version. It really was as easy as downloading the "monolithic" iDRAC firmware, extracting the .D6 file and uploading it through the iDRAC web interface. Actually finding the upload/update button in the interface took more effort :p
Getting the iDRAC6 remote console working took a little more research. For version 6 of the hardware, the remote console relies upon a Java application, which you can call by clicking a button in the web interface. What this does is download a JNLP configuration file, which in turn downloads the actual JAR file for execution. This is a process that doesn't work reliably on modern MacOS due to all the restrictions put on Java. The good news is that Github user Nicola ("XBB") provides instructions on how to reliably and quickly start the remote console for any iDRAC6 on MacOS, Linux and Windows.
Last night I installed VMWare ESXi 6.5, which I've been told is the highest version that'll work on this box. No worries, it's good stuff! The installation worked well, installing onto a SanDisk Cruzer Fit mini USB-drive that's stuck into the front panel. I still have a lot of learning to do with VMWare :)
In the mean time, there's two VMs building and updating (Win2012 and CentOS7), so I can use them as the basis for my "corporate" environment.
My plans for the near future:
I'm having so much fun! :D
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2018-12-19 20:10:00
The excitement is palpable!
A number of past colleagues waxed lyrically about SANS trainings: in-depth, high-tech, wizardry, grueling pace and super-hard work! And at the same time one heck of a lot of fun! And I must admit that I've spent quite a few hours browsing their site, drooling at the courses and exams they offer. They certainly are a well known name in the InfoSec world, having a good reputation and being downright famous for their coin challenges and the high level of skill they both garner and require.
Unfortunately I could never get past the steep bill! Yes, they're very good! But each course rings in around $6000! And their Netwars and exams don't come cheap either! So I just sighed and closed the tab, only to revisit months later. But this year things changed! Somewhere in September I learned something that I should've known before! I don't even remember whether I read about it on Reddit, on Tweakers or on TechExams, but it was a great find nonetheless!
SANS offer what they call the Work/Study Program. To quote their own site:
"The Work Study Program is a popular and competitive method of SANS training which allows a selected applicant the opportunity to attend a live training event as a facilitator at a highly discounted tuition rate. SANS facilitators are cheerful, friendly, and ever-ready professionals who are selected to assist SANS staff and instructors in conducting a positive learning environment. Advantages of the SANS Work Study Program include:
- Attend and participate in a 4-6 day course
- Receive related courseware materials
- Work with Certified Instructors and SANS Staff
- Attend applicable Vendor Lunch & Learns, SANS@Night, and other Special Events
- Opportunities to network with security professionals
- Free corresponding GIAC certification exam attempt [if available], when lodging onsite at the host hotel
- Request early access to online OnDemand integrated slides and notes [if available]"
How great is that?! By helping out at the event and putting in a lot of hard work, you get a discount, plus a whole wad of extras to make sure you still get the full benefit of the training you signed up for! I decided then and there to apply for the role of Facilitator for the upcoming Amsterdam event, in January 2019.
I honestly did not think I stood much of a chance because, as SANS say, it's highly competitive and SANS often prefer past SANS-students or -facilitators and I am neither. On the upside, I do have a lot of organizational experience in running events, with many thanks to all those years of staffing and volunteering with AnimeCon.
I'd almost forgotten about my application, until a few weeks ago when the email above shows up! OMG! O_O I got accepted!
Now that all the paperwork has been settled I also have a better grasp of both my responsibilities and the perks I'll be receiving. I was assigned to SEC566 - Implementing and Auditing Critical Security Controls, a five-day course (the whole event actually last six days). My duties at the event are actually not disimilar to gophering at AnimeCon! I'll be assisting the course's trainer, basically not leaving their side unless they need something from outside. I'll also be responsible for the security of the assigned classroom and will act a sort-of guide and friendly face to the other students. Where "normal" students will have 0900-1700 days, mine will most likely be 0700-1900. That's gonna be tough! The Sunday before the event starts will also be a full workday, preparing the venue with all the cabling, networking, equipment and the book bags for students.
And that discount we're getting? When I signed up I had not fully understood what SANS wrote on their site:
"The Work Study tuition fee is USD 1,500 or EUR 1,300 plus any VAT depending on the event location. Should you be selected to facilitate a Summit presentation, the fee is $250 or 217 per day plus any VAT for European events. International Tax/VAT will apply for certain events."
A €1300 discount sounded pretty darn good to me, when combined with all those bonuses! Turns out I misunderstood. The final fee is €1300! So on a total value of >$8100, they're discounting me €6800. O_O
To say I'm stoked for SANS Amsterdam, would be severely understating my situation! I am very grateful for being given this opportunity and I'm going to work my ass off! I'll make sure SANS won't regret having accepted me!
kilala.nl tags: work,
View or add comments (curr. 0)
2018-11-28 16:49:00
Following up on my previous post on querying ADCS with certutil, I spent an hour digging around ADCS some more with a colleague. We were looking for ways to make our lives easier when performing certificate life cycle management, i.e. figuring out which certs need replacing soon.
Want to find all certs that expire before 0800 on January first 2022?
certutil –view –restrict “NotAfter<1/1/2022 08:00”
However, this also shows the revoked certificates, so lets focus on those that have the status "issued". Here's a list of the most interesting disposition values.
certutil –view –restrict “NotAfter<1/1/2022 08:00,Disposition=0x14”
Now that'll give us the full dump of those certs, so let's focus on just getting the relevant request IDs.
certutil –view –restrict “NotAfter<1/1/2022 08:00,Disposition=0x14” –out “RequestId”
Mind you, many certs can be setup to auto-enroll, which means we can automatically renew them through the ADCS GUI by going into Template Management and telling AD to tweak all currently registered holders, making them re-enroll. That's a neat trick!
Of course this leaves us with a wad of certificates that need manual replacement. It's easier to handle these on a per-template basis. To filter on these, we'll need to get the template ID. You can do this through the ADCS GUI, or you can query a known cert and output it's cert template ID.
certutil –view –restrict “requestid=3162” –out certificatetemplate
So our query now becomes:
certutil –view –restrict “NotAfter<1/1/2022 08:00,Disposition=0x14,certificatetemplate=1.3.6.1.4.1.311.21.8.7200461.8477407.14696588202437.5899189.95.14580585.6404328” –out “RequestId”
Sure, the output isn't easily used in a script unless you add some output parsing (there are white lines and all manner of kruft around the request IDs), but you get the picture. This will at least help you get a quick feeling for the amount of work you're up against.
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2018-11-22 19:35:00
I've been studying MongoDB recently, through the excellent Mongo University. I can heartily recommend their online courses! While not entirely self-paced, they allow you enough flexibility to finish each course within a certain timeframe. They combined video lectures with (ungraded) quizes, and graded labs and an exam. Good stuff!
I'm currently taking M310, the MongoDB Security course. One of the subjects covered is Kerberos authentication with MongoDB. In their lectures they show off a use-case with a Linux KDC, but I was more interested in copying the results with my Active Directory server. It took a little puzzling, a few good sources (linked below) and three hours of mucking with the final troubleshooting. But it works very nicely!
On the Active Directory side:
We'll have to make a normal user / service account first. I'll call it svc-mongo. This can easily be done in many ways; I used ADUC (AD Users and Computers).
Once svc-mongo exists, we'll connect it to a new Kerberos SPN: a Service Principal Name. This is how MongoDB will identify itself to Kerberos. We'll make the SPN, link it to svc-mongo and make the associated keytab (an authentication file, consider it the user's password) all in one blow:
ktpass /out m310.keytab /princ mongodb/database.m310.mongodb.university@CORP.BROEHAHA.NL /mapuser svc-mongo /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /pass Password2
This creates the m310.keytab file and maps the SPN "mongodb/database.m310.mongodb.university" to the svc-mongo account. The SPN is written in the format "service/fullhostname/domain". The password for the user is also changed and some settings are set pertaining to the used cryptography and Kerberos structures.
You can verify the SPN's existence with the setspn -Q command. For example:
PS C:usersThomasDocuments> setspn -Q mongodb/database.m310.mongodb.university
Checking domain DC=corp,DC=broehaha,DC=nl
CN=svc-mongo,CN=Users,DC=corp,DC=broehaha,DC=nl
mongodb/database.m310.mongodb.universityExisting SPN found!
The m310.keytab file is then copied to the MongoDB server (database.m310.mongodb.university). In my case I use SCP, because I run Mongo on Linux.
On the Linux side:
The m310.keytab file is placed into /etc/, with permissions set to 640 and ownership root:mongod. In order to use the keytab we can set an environment variable: KRB5_KTNAME="/etc/m310.keytab". This can be done in the profile of the user running MongoDB, or on RHEL-derivates in a sysconfig file.
We need to setup /etc/krb5.conf with the bare minimum, so the Kerberos client can find the domain:
[libdefaults]
default_realm = CORP.BROEHAHA.NL[realms]
CORP.BROEHAHA.NL = {
kdc = corp.broehaha.nl
admin_server = corp.broehaha.nl
}[domain_realm]
.corp.broehaha.nl = CORP.BROEHAHA.NL
corp.broehaha.nl = CORP.BROEHAHA.NL[logging]
default = FILE:/var/log/krb5.log
Speaking of finding the domain, there are a few crucial things that need to be setup correctly!
With that out of the way, we can start making sure that MongoDB knows about my personal user account. If the Mongo database does not yet have any user accounts setup, then we'll need to use the "localhost bypass" so we can setup a root user first. Once there is an administrative user, run MongoD in normal authorization-enabled mode. For example, again the barest of bare minimums:
mongod --auth --bind_ip database.m310.mongodb.university --dbpath /data/db
You can then connect as the administrative user so you can setup the Kerberos account(s):
mongo --host database.m310.mongodb.university:27017 --authenticationDatabase admin --user root --password
MongoDB> use $external
MongoDB> db.createUser({user:"tess@CORP.BROEHAHA.NL", roles:[{role:"root",database:"admin"}]})
And with that out of the way, now that we can actually use Kerberos-auth. We'll restart MongoD with Kerberos enabled, at the same time disabling the standard Mongo password authentication and thus lock out the root user we used above.
mongod --auth --bind_ip database.m310.mongodb.university --authenticationMechanisms=GSSAPI --dbpath /data/db
We can then request a Kerberos ticket for my own account, start a Mongo shell and authenticate inside Mongo as myself:
root@database:~# kinit tess@CORP.BROEHAHA.NL -V
Using default cache: /tmp/krb5cc_0
Using principal: tess@CORP.BROEHAHA.NL
Password for tess@CORP.BROEHAHA.NL:
Authenticated to Kerberos v5root@database:~# mongo --host database.m310.mongodb.university:27017
MongoDB shell version: 3.2.21
connecting to: database.m310.mongodb.university:27017/testMongoDB Enterprise > use $external
switched to db $externalMongoDB Enterprise > db.auth({mechanism:"GSSAPI", user:"tess@CORP.BROEHAHA.NL"})
1
HUZZAH! It worked!
Oh right!.. What was the thing that took me hours of troubleshooting? Initially I ran MongoD without the --bind_ip option to tie it to the external IP address and hostname. I was running it on localhost. :( And thus the MongoD process identified itself to the KDC as mongodb/localhost. It never showed that in any logging, so that's why I missed it. I had assumed that simply passing the keytab file was enough to authenticate.
Sources:
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2018-11-01 18:44:00
I think Microsoft's ADCS is quite a nice platform to work with, as far as PKI systems go. I've heard people say that it's one of the nicest out there, but given its spartan interface that kind of makes me worry for the competitors! One of the things I've fought with, was querying the database backend, to find certificates matching specific details. It took me a lot of Googling and messing around to come up with the following examples.
To get the details of a specific request:
certutil -view -restrict "requestid=381"
To show all certificate requests submitted by myself:
certutil -view -restrict "requestername=domain\t.sluijter"
To show all certificates that I requested, displaying the serial numbers, the requestor's name and the CN on the certificate. It'll even show some statistics at the bottom:
certutil -view -restrict "requestername=domain\t.sluijter" -out "serialnumber,requestername,commonname"
Show all certificates provided to TESTBOX001. The query language is so unwieldy that you'll have to ask for "hosts >testbox001 and <testbox002".
certutil -view -restrict "commonname>testbox001,commonname<testbox002" -out "serialnumber,requestername,commonname"
A certificate request's disposition will show you errors that occured during submission, but it'll also show other useful data. Issued certificates will show whom approved the issuance. The downside to this is that the approver's name will disappear once the certificate is revoked. So you'll need to retain the auditing logs for ADCS!
certutil -view -restrict "requestid=381" -out "commonname,requestername,disposition,dispositionmessage"
certutil -view -restrict "requestid=301" -out "commonname,requestername,disposition,dispositionmessage"
Would you like to find out which certificate requests I approved? Then we'll need to add a bit more Powershell.
certutil -view -out "serialnumber,dispositionmessage" | select-string "Resubmitted by DOMAIN\t.sluijter"
Or even better yet:
certutil -view -out "serialnumber,dispositionmessage" | ForEach {
if ($_ -match "^.*Serial Number:"){$serial = $_.Split('"')[1]}
if ($_ -match "^.*Request Disposition Message:.*Resubmitted by DOMAIN\t.sluijter"){ Write-Output "$serial" }
}
Or something very important: do you want to find certificates that I both request AND approved? That's a bad situation to be in...
certutil -view -restrict "requestername=domain\t.sluijter" -out "serialnumber,dispositionmessage" | ForEach {
if ($_ -match "^.*Serial Number:"){$serial = $_.Split('"')[1]}
if ($_ -match "^.*Request Disposition Message:.*Resubmitted by DOMAIN\t.sluijter"){ Write-Output "$serial" }
}
If you'd like to take a stab at the intended purpose for the certificate and its keypair, then you can take a gander at the template fields. While the template doesn't guarantee what the cert is for, it ought to give you an impression.
certutil -view -restrict "requestid=301" -out "commonname,requestername,certificatetemplate"
kilala.nl tags: work, pki, sysadmin,
View or add comments (curr. 0)
2018-10-05 21:07:00
I took the CompTIA Linux+ beta (XK1-004) today and I wasn't very impressed... It's "ok".
I have no recent experience with LPIC or with the previous version of Linux+, only with LPIC from ten years ago. Based on that I feel that the new Linux+ is less... exciting? thrilling? than what I'd expect from LPIC. It feels to me like a traditional Linux-junior exam with its odd fascination on TAR, but with modern subjects (like Git or virtualization) tacked on the side.
Personally I disliked one of the PBQ's, with a simulated terminal. This simulation would only accept the exact, literal command and parameter combinations that have been programmed into it. Anything else, any other permutation of flags, results in the same error message. Imagine my frustration when a command that I run almost daily to solve the question at hand is not accepted, because I'm not using the exact flags or the order thereof that they want me to type.
Anyway. I'm glad that I took the beta, simply to get more feeling of the (international) market place. Now at least I'll know what the cert entails, should I ever see it on an applicant's resumé. :)
kilala.nl tags: work, sysadmin,
View or add comments (curr. 0)
2018-07-31 21:29:00
A bit over three months ago, I took part in CompTIA's beta version of the PenTest+ exam. It was a fun and learning experience and despite having some experience, I didn't expect to pass.
Turns out, I did! I passed with an 821 out of 900 score :D
Now, I hope that some of the feedback I provided has been useful. That's the point of those beta exams, isn't it?
kilala.nl tags: work, sysadmin,
View or add comments (curr. 1)
All content, with exception of "borrowed" blogpost images, or unless otherwise indicated, is copyright of Tess Sluijter. The character Kilala the cat-demon is copyright of Rumiko Takahashi and used here without permission.