I’m pleased to announce that dashboards are now available on train views.
Prior to the introduction of the dashboard, it was difficult to tell if a train was running, what route it was on, and what station it was at. This new dashboard makes use of the “latest” API endpoint described in the previous post to provide a snapshot of the current status of the train.
Work is sending me to a conference that just happens to be hosted in Las Vegas, a city where there are a few casinos. I’m not much for gambling, so I figured I should learn a little about it before I even think of doing such a thing. I read that craps is a fun game that has some pretty safe bets, so I decided to learn more about that. To that end, I wrote a craps simulator.
This one is kinda clever, that rather than a human using high-pressure tactics to get you to enter your credit card number, what you hear instead is a recorded message which asks you to “press 1 to get a lower interest rate”. Had I pressed 1, I suspect I’d be transferred to a nice sounding human operator who would try to coax me into giving them my credit card number.
There’s two takeaways from this:
Never give out your card card number to someone who calls you on the phone. (caller ID can be spoofed)
Strongly consider against picking up the phone when an unknown number calls you. Let it go to voicemail. If it’s someone trying to get a hold of you, you can listen to the voicemail right away (or use Google Voice, which does transcripts), and call the person back.
In general, the longer the password, and the more random it is, the more secure it is. This is because if a password file is stolen, the passwords are stored there are stored in encrypted format, where each password is encrypted with… itself. This means that in order to determine what an account
‘s password is, an attack must try encrypting every random possible string and see if it matches the encrypted password.
Naturally, this means that all possible 2-character strings can be tried quicker than 3-character strings, and 4 character strings will take even longer. Unfortunately, thanks to Moore’s Law, “longer” means “a few milliseconds”. 8 character passwords are usually the minimum, but by some estimates, even that is not sufficient. To make for an even bigger challenge, us humans tend to have a hard time remembering random letters and numbers. This leads to bad habits such as using the same password on multiple sites, and that can cause its own problems.
The Streisand Effect, for those not aware, is where an attempt to remove, hide, or censor a piece of information has the unintended consequence of publicizing that information more widely by way of drawing attention to it. It is named after Barbara Streisand, who once filed a lawsuit to have an arial image of her home removed from the Internet. In her case, it resulted in a flood of publicity and thousands of people viewing that image.
What happened here?
An individual took issue with a post that I wrote 8 years ago. The identity of the person and the content of the post aren’t relevant to this post, but what is important is that prior to this event, the post was sitting by itself, pretty much left alone except for for the occasional web crawler visiting it. The post would have stayed that way, except that the person who had an issue with my post decided to complain in a heavily trafficked forum. This resulted in the post receiving more traffic than the previous several months combined. Additionally, many more people were made aware of the contents of the post, which I’m fairly sure the person complaining did not want to see happen.
How about some numbers?
Here’s a graph of HTTP requests to that page over time:
Note the huge spike, when is when the post in question was mentioned. Approximately one thousand separate people visited the post in question during the spike in traffic.
As a service to the Philly tech community (and because folks asked), I took notes at tonight’s presentation, called “Security Practices for DevOps Teams”. It was presented by Chris Merrick, VP of Engineering at RJMetrics.
Security is a “cursed role”
…in the sense that if you’re doing a really good job as a security engineer, no one knows you exist.
It isn’t sexy
It’s hard to quantify
It’s never done
As DevOps engineers, we are all de facto security engineers
Some tips to avoid ending up like this [Picture of a dismembered C3PO]
Obscurity is not Security
“A secret endpoint on your website is not security”
“Don’t rely on randomness to secure things”
Do not give more privileges than are needed
If you talk to an insecure system, you’re at risk
Breaking into datacenters
Any vector that comes through an application you developed
Applications you didn’t write
Phishing, social engineering
Authentication is who you are
Authorization is what you can access
Don’t access production directory
Good news: this is our job anyways
Don’t spread private keys around
Don’t put in your Dropbox
Don’t let it leave the machine you generated it on
Use SSH agent forwarding
ssh -A you@remote
Don’t use shared accounts
Be able to revoke access quickly
Time yourself. Go.
We use Amazon OpsWorks to help us achieve these goals
Chef+AWS, with some neat tricks: simple autoscaling, application deployment, and SSH user management
“Logs are your lifeline”
When you get into a high pressure security investigation, you start with your logs
Capture all authentication events, privilege, escalations, and state changes.
From your Os and all running applications
Make sure you can trust your logs
Remember – they’re your lifeline
Have a retention policy
We keep 30 days “hot”, 90 days “cold”
Logging – ELK
We use ELK for hot log searching
Kibana creates logs and lets you monitor your application in real time
Keep unencrypted secrets out of code
Otherwise, a MongoLab exploit becomes your exploit
Don’t keep old code around
Make deployment and rollback easy
More good news: this is our job anyways
When dealing with a security issue, the last thing we need a “hard last step” in order to get the fix out
Don’t use your root account, ever.
Set a long password and lock it away
Set a strong password policy and require MFA
Don’t create API keys where API access isn’t needed
Same goes for a console password
Use Managed Policies
To make management easier
Use Roles to gran taccess to other systems
No need to deploy keys, auto-rotates
IAM Policy Pro Tips
Don’t use explicit DENY policies
Keep in mind that everything is denied by default
Don’t assume your custom policy is correct just because it saves – the interface only confirms the JSON is valid
Use the policy simulator
Know Thy Enemy
People are out there scanning for AWS keys – treat your private key like a private SSH key
Short URLs and the services that offer their creation have grown quite popular in recent years, as microblogging services such as Twitter limit you to 140 characters or less per message. In fact, some services such as Twitter offer their own URL shorteners built into the service for the benefit of their users.
The most popular of the URL shorteners is Bitly, so this post will be about setting up a custom short domain with Bitly.
In this post, I’m going to discuss how to create a GitHub repo and upload (or “push”) it to GitHub, a popular service for hosting Git repositories.
What is revision control and why do I need it?
The concept of revision control is a system which tracks changes to files. In programming, that is usually program code, but documents and text files can also be tracked. Using revision control will give the following benefits:
You will know what was changed, when it was changed, and who changed it
Multiple people can collaborate on a project without fear of overwriting each others’ changes.
Protection against accidentally deleting a critical file. (revision history is usually read-only)
In GitHub, we store revisions in “repositories” or “repos” for short. As of this writing, the #1 service for storing Git repositories is GitHub. They offer free hosting for Git repositories.
Earlier tonight, I had the pleasure of attending a presentation from Chris Munns of Amazon at the offices of First Round Capital about scaling your software on AWS past the first 10 million users. I already had some experience with AWS, but I learned quite a few new things about how to leverage AWS, so I decided to write up my notes in a blog post for future reference, and as a service to other members of the Philadelphia tech community.
Without further preamble, here are my notes from the presentation: