Tag Cloud
Currently Reading
Latest Book Reviews
- Certified Kubernetes Application Developer (CKAD) Study Guide, 2nd Edition Posted on January 11, 2025
- Rancher Deep Dive Posted on March 31, 2023
- Leveraging Kustomize for Kubernetes Manifests Posted on March 24, 2023
- Automating Workflows with GitHub Actions Posted on October 13, 2022
- Deep-Dive Terraform on Azure Posted on August 30, 2022 All Book Reviews
Latest Posts
- Annoying Ansible Gotcha Posted on April 14, 2018
- Working with Ruby obfuscated code: Finding all classes available in a module Posted on May 24, 2017
- aws cli AuthFailure gotcha Posted on January 30, 2017
- Using Python to Output Pretty Looking JSON Posted on December 18, 2016
- Hide Server and Web Application Information Posted on November 22, 2016
April 14, 2018
Annoying Ansible Gotcha
by Alpha01
Ansible is by far my favorite Configuration Management tool, however it certainly has it’s own unique quirks and annoyances. To start, I prefer the Ansible’s YAML/Jinja approach instead of Puppet and Chef’s own DSL custom configurations.
Today I ran into an interesting YAML parsing quirk. It turns out if you use colon ‘:’ character inside a string anywhere in your playbooks, Ansible will fail to properly parse it.
Example playbook:
---
- hosts: 127.0.0.1
tasks:
- lineinfile: dest=/etc/sudoers regexp='^testuser ALL=' state=present line="testuser ALL=(ALL) NOPASSWD: TEST_PROGRAM" state=present
Error
When running the playbook, triggers the following error:
ERROR! Syntax Error while loading YAML.
The error appears to have been in '/etc/ansible/one_off_playbooks/example.yml': line 4, column 104, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
tasks:
- lineinfile: dest=/etc/sudoers regexp='^testuser ALL=' state=present line="testuser ALL=(ALL) NOPASSWD: TEST_PROGRAM" state=present
^ here
Fix
This is a known issue https://github.com/ansible/ansible/issues/1341 and the easiest work around for this, is to force the colon ‘:’ character to be evaluated by the Jinja templating engine.
{{':'}}
The hilarious part of this, is that it doesn’t look like this stupid quirk is going to be fixed.
Tags: [ansible May 24, 2017
Working with Ruby obfuscated code: Finding all classes available in a module
by Alpha01
As a follow up to my HashiCorp Rocks! blog post. Up until now, I’ve never directly worked with any obfuscated code. HashiCorp obfuscates their VMware Fusion and Workstation commercial Vagrant plugins.
Like Vagrant, the plugins themselves are written in Ruby.
alpha03:lib tony$ file vagrant-vmware-fusion.rb
vagrant-vmware-fusion.rb: ASCII text, with very long lines, with CRLF, LF line terminators
However, if you try to read the source all you’ll see is a bunch of encoded text. Since my Vagrant plugin has some functionality that only works after a certain action gets executed by the proprietary plugins. This is why I needed to know the exact name of that particular action (class name) exactly how it’s defined inside the VMware Fusion and Workstation plugins. This was a serious problem because I can’t read their source code!
Luckily, this wasn’t as difficult as it seems. Finding the classes (or methods but in the case of mine I didn’t need too) available in Ruby is fairly simple process. To my luck somebody had already asked and answered this question in StackOverflow.
In my case, first step was needing to know the name of the actual module itself. I found the easiest way to get the name of the module that’s obfuscated, is to intentionally have it spit out an exception. In doing that, I found that the module names whose namespace I’ll be searching were HashiCorp::VagrantVMwarefusion and HashiCorp::VagrantVMwareworkstation.
Once I knew the modules’s name, I was able to use Ruby to view what additional modules I have within the particular module namespace. I was able to accomplish that using the following
t = HashiCorp::VagrantVMwareworkstation.constants.select {|c|
HashiCorp::VagrantVMwareworkstation.const_get(c).is_a? Module
}
puts t
The above sample code spit out a bunch of modules inside HashiCorp::VagrantVMwareworkstation, but since I know the Vagrant plugin API and it’s coding standards/practices. I was able to verify that the module I’m searching for is HashiCorp::VagrantVMwareworkstation::Action. Once again, looking at Plugin API and other examples, I knew that this is where the class is I’m looking is stored in. So I used the following to get the corresponding class name within HashiCorp::VagrantVMwareworkstation::Action.
p = HashiCorp::VagrantVMwareworkstation::Action.constants.select { |c|
HashiCorp::VagrantVMwareworkstation::Action.const_get(c).is_a? Class
}
puts p
I repeated the above tests for HashiCorp::VagrantVMwarefusion and I was also able to find the corresponding class name that it’s defined inside the obfuscated Ruby code.
In the end I was able to get the classes HashiCorp::VagrantVMwareworkstation::Action::Suspend and HashiCorp::VagrantVMwarefusion::Action::Suspend, and everything worked as expected.
Tags: [ruby vagrant January 30, 2017
aws cli AuthFailure gotcha
by Alpha01
It’s probably been about 5-6 years since the last time I’ve used the AWS command line tools. The other day I signed up for the AWS Free Tier to familiarize myself with the aws command-line tools once again. I created myself a test user and granted full access to my aws account. Easy and simple. Well not so fast, initially my user account failed to authenticate properly. I tried re-generating new API keys and even created other different accounts with different types of access, but the problem persisted.
Problem
I was getting the following error:
[root@bashninja ~]# aws ec2 describe-regions
An error occurred (AuthFailure) when calling the DescribeRegions operation: AWS was not able to validate the provided access credentials
I verified my AWS API credentials stored on ~/.aws/credentials to ensure everything was correct. Yet, the fucking problem persisted.
Fix
It turned out that the time on the system I was trying to use the aws cli tools in, had the time completely wrong! Once the time was fixed I was able to authenticate my account and use the aws cli tool.
Tags: [aws python December 18, 2016
Using Python to Output Pretty Looking JSON
by Alpha01
Every once and awhile, theirs occasions that I have a giant glob of JSON data that I want to easily read it’s data. Normally I opted to use http://jsonlint.com/. The problem is whenever I use http://jsonlint.com/, I always have to be sure the JSON data doesn’t include anything confidential. I was happy to learn that you can easily use the json library in Python to accomplish essentially the same thing.
For example:
alpha03:~ tony$ cat test.json
{"employees":[{"firstName":"John", "lastName":"Doe"},{"firstName":"Anna", "lastName":"Smith"},{"firstName":"Peter", "lastName":"Jones"}]}
alpha03:~ tony$ python -m json.tool < test.json
{
"employees": [
{
"firstName": "John",
"lastName": "Doe"
},
{
"firstName": "Anna",
"lastName": "Smith"
},
{
"firstName": "Peter",
"lastName": "Jones"
}
]
}
python November 22, 2016
Hide Server and Web Application Information
by Alpha01
First and foremost, this is security over obscurity. No relevant security improvement is gained by this, but rather just annoy or hopefully prevent automated bots or script kiddies from doing any future damage. By NO means it should be the only defensive mechanism for any site!
This site runs on Drupal. Drupal, by default returns Drupal specific http headers on every request. So I wanted to disabled this completely at the server level, in addition to the PHP and Apache information that is part of a typical stock LAMP configuration.
First, we start with PHP. The PHP X-Powered-By header can be disabled by disabling the expose_php option:
expose_php = Off
Next, is updating the default Server header set by Apache:
ServerTokens Prod
Finally, it’s time to remove the X-Generator and X-Drupal-Cache specific Drupal headers. Using Apache via mod_headers module:
<IfModule mod_headers.c>
Header unset X-Generator
Header unset X-Drupal-Cache
</IfModule>
Using Nginx via the headers more module:
more_clear_headers 'x-generator';
more_clear_headers 'x-drupal-cache';
Why stop here when I can set custom headers. So as a joke, I want to tell the world that my sites are powered by Unicors and I’m the hacker being it. Doing so is dead simple.
- Nginx
add_header X-Powered-By "Unicorns";
add_header X-hacker "Alpha01";
- Varnish (vcl_deliver)
set resp.http.X-Powered-By = "Unicorns";
set resp.http.X-hacker = "Alpha01";
View our changes
Now, let’s view my new http headers
alpha03:~ tony$ curl -I https://www.rubysecurity.org
HTTP/1.1 200 OK
Date: Thu, 24 Nov 2016 03:53:40 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Set-Cookie: __cfduid=d8fbf8e2a27fac74e782224db3fd3c86c1479959620; expires=Fri, 24-Nov-17 03:53:40 GMT; path=/; domain=.rubysecurity.org; HttpOnly
Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=300
X-Content-Type-Options: nosniff
Content-Language: en
X-Frame-Options: SAMEORIGIN
Last-Modified: Tue, 22 Nov 2016 06:55:27 GMT
Vary: Cookie,Accept-Encoding
Front-End-Https: on
X-Powered-By: Unicorns
X-hacker: Alpha01
Server: cloudflare-nginx
CF-RAY: 3069ea499a6320ba-LAX
Resources
- http://php.net/manual/en/ini.core.php#ini.expose-php
- http://httpd.apache.org/docs/2.4/mod/core.html#servertokens
- https://www.drupal.org/node/982034#comment-4719282
- http://nginx.org/en/docs/http/ngx_http_headers_module.html
php drupal nginx varnish apache security