Docker - Intro Cheatsheet

Docker is hot 🔥 right now so I just did the introduction to docker course by Andrew Tork Baker on O’Reily Media and I absolutely loved it. I can already see its usefulness and how integrating Docker in my projects will be helpful. Look for a short cheatsheet of Docker commands further down.

What Is It?

Simply put, Docker provides the isolation power of traditional VMs but without the overhead of running separate guest operating systems. Instead, the docker-engine is the containerization engine and allows the individual applications to potentially share resources, like reused libraries, for better efficiency. Super portable & lightweight!

Dockerfiles define what your container will.. well, contain 💡… and what commands it should run on startup. It’s important to always optimize your Dockerfile to reduce its size and reuse layers from other images in your repository. You first specify your base image, install any dependencies, then you finally add a RUN command.

Build the image from your Dockerfile with docker build . from the location of the file (docker will look for a file named ‘Dockerfile’ in this directory). Then use the docker run command to create a container from that image.

I found myself reusing many of the same commands over and over again when playing around with Docker, so for reference here’s a short cheat sheet of useful Docker commands. Hope it helps 😊. (Words between curly braces are variables)

CHEATSHEET:


docker run -it {image} : Launch the container in interactive mode (attach to terminal).


docker run -d {image} : Launch the container in detached mode (in the background).


docker run -p 8000:80 {image} : Map port 80 from the container to port 8000 on the host machine.


docker ps : List active containers.


docker ps -a : List all containers (including stopped containers).


docker ps -l : List latest container.


docker start/stop/pause {container} : Self-explanatory.


docker rm {container} : Delete a stopped container.


docker rm -f {container} : Force remove a container (even if its running).


docker logs {container} : Display the container’s logs.


docker logs -f {container} : Follow the logs in real-time as they come.


docker attach {container} : Attach the container to the terminal. This is basically like running docker run -it except on an already running container. But be careful, it will also listen to your input so if you exit attached mode the container will shut down.


docker diff {container} : Displays the diff of files that have been changed since container was created.


docker cp {container}:{container_filepath} {destination} : Copy files from container to host machine.


docker inspect {container} : View all the detailed information about your container.


Note: I’m currently running Docker on my Windows 7 machine (with VirtualBox & no native hypervisor).

WannaCry reeking havoc

Sending shockwaves through the world, WannaCry has been spreading inside corporate networks over the last couple of days. WannaCry seems to be a variation of the EternalBlue exploit which was stolen from the NSA. It exploits a vulnerability in version 1 of Microsoft’s SMB protocol (protocol used in Windows for interprocess communication), which allows an attacker to execute arbitrary code on the target machine by sending special packets that SMBv1 fails to handle.

In classic ransomware fashion, WannaCry encrypts all files into .wncry files (which is how it got it’s name) and asks the victim to pay a ransom via Bitcoin.

Once the victim pays the ransom, they have to contact the attackers to confirm the payment and to request the decryption key. At this point we don’t know if the attackers are honouring this, but based on the activity in the bitcoin wallets, hundreds of victims have already payed the fee.

When the malware runs, it tries to connect to some kill switch domains. If the connection succeeds, it doesn’t run. So it only encrypts the files and continues to spread if the connection fails. One problem is that it isn’t proxy-aware, so if a corporate network forces outbound connections to go through a proxy, the connection will fail and the malware will always run 😨. So one thing that can help stop this is to run an internal DNS sinkhole that points the kill switch domains to an internal web server. The danger now is that other variants of WannaCry are starting to appear, with slight modifications to the kill switch, like different domains or using registry checks instead.

So remember, always patch your systems. If you can’t, turn off SMBv1 on vulnerable systems while you work on updating your systems.

UPDATE:

It has now been over a week since WannaCry started doing damage and things have gotten better.

The domain names the malware tries to connect to have been registered, which has helped curb the spread, but unfortunately they’re currently under consistent DDOS.

Some decryption tools have been released to help recover encrypted files. Turns out that the random seeds that create the private key are left in memory, so it is possible to recover them. Of course if your machine was reset / shutdown, or the memory was reallocated / erased by a seperate process, you’re out of luck, but nonetheless there should be some hope for many of the victims.

Bitcoin Full Node; What & Why?

The purpose of Bitcoin is to be decentralized, but it’s also one of its core challenges.

What:

A full node is essentially the complete Bitcoin blockchain running on a computer, ensuring that the laws of the Bitcoin protocol are followed and rejecting any fraudulent blocks. Running a full node requires a couple of things: storage and an internet connection. It takes a lot of data and a few days to download & sync the whole node in the first place (depending on internet speed & hardware being used) and as long as your computer is connected to the internet, you’ll be part of the Bitcoin network.

Why:

So why would you want to set up a full node? 🤔🤔

First of all: privacy. If you’re not using a full node, you have to connect to a remote server to make transactions. This means that you are trusting a third-party with your transaction information. If you value privacy when making Bitcoin payments, you want to be able to control your transactions and post them through your own trusted full node. You trust yourself, right? 😅 Privacy is one of the coolest things about Bitcoin in the first place.

But more importantly, by using a full node you are helping further decentralize the Bitcoin network. Your node will be validating incoming blocks and relaying valid ones to the rest of the network, thus securing and making the network faster. The more independent nodes, the more decentralized (stronger) the network becomes.

It’s not necessary to run a full node in order to make Bitcoin transactions, and sure you may have to leave your computer open all the time, but if you do a lot of transactions and you want to contribute to the overall Bitcoin ecosystem, it’s worth it 😉.