Following up on my Bandit post, OverTheWire Natas teaches the basics of serverside web-security. These are quick notes for my solutions to level 0-10. I’ll be doing these in preperation for the OSCP pentesting course I plan on taking.
The password to this level is listed on the natas game description:
Username: natas0
Password: natas0
URL: http://natas0.natas.labs.overthewire.org
OverTheWire Bandit is a capture the flag (CTF) game for beginners. I’ve recently regained interest in security and found this a fun way to get back into what originally led me to learn programming. These are quick notes for my solutions on level 0-27.
The password for the next level is stored in a file called readme located in the home directory. Use this password to log into bandit1 using SSH. Whenever you find a password for a level, use SSH (on port 2220) to log into that level and continue the game.
Note: These are my findings after working with Docker, Jenkins, and AWS for only 2-3 months. This post details my thought process for the workflow I have set up with Docker and was written to document my progress. However, it might be useful for other beginners who are interested in setting up a better workflow for development with Node.js and Docker.
Our development team occasionally has to switch between different projects. Each project has its own set of dependencies requiring a specific version of Node.js, npm, and/or Ruby to be run. Using nvm and rvm can mitigate the issue, but constantly switching between versions is a hassle and it is easy to lose track of which version you’re currently using. Time is also wasted on debugging environment inconsistencies between local development machines, and even more time is lost solving cross-platform issues when deploying to the dev/qa/prod servers (OSX to Linux). Many hours were lost for both the development and system administration teams debugging these issues; hours that could instead be spent improving the current project or working on other projects.
I’ve been hearing good things about Docker ever since I started working professionally as a web developer. However, a lot of the deployment process was abstracted from me. The projects I worked on were mature and had an established workflow. The code I pushed up to Github will end up magically working on the staging server and then to production. A few weeks ago I was given the opportunity see a new project grow through its infancy. I saw a lot of problems with getting a project working locally to work on production. Something would break every few pushes and time would be wasted getting the devleopers and system administrators together to figure out a solution. After hearing so many good things about Docker and how it aims to solve the problems we were having in production, I suggested that we use Docker to develop our application and ship it to production.
Knowing absolutely nothing about Docker, these are the problems I faced and the references I used to figure out a workflow for our developers. This is yet another blog post where I jot down my thoughts and decision making, and not really walking through anything.
Here are some notes I took on how I set up my Jenkins server and deployed my application to Elastic Beanstalk on every git push.
After using Docker to deploy last month, I’ve decided to try deploying using Capistrano and nginx for my current project.
Helpful links: http://robmclarty.com/blog/how-to-deploy-a-rails-4-app-with-git-and-capistrano