Cloud Security

Secure your Virtual Machines in the cloud by doing the following:

  1. Reduce your open ports to as few as possible.
  2. Do NOT allow any process serving as a TCP/IP listener to run as root.
  3. Change your SSH port from 22 to something other than 22.
    1. Change this every day if you are paranoid.
    2. Change this every hour if your are crazy paranoid.
  4. Use only Public Key Encryption for SSH access.
    1. Change your Public Keys every day if you are paranoid.
    2. Change your Public Keys every hour if you are crazy paranoid.
    3. Use only 2048 bit keys whether paranoid or not.
  5. Deny root level access for all users other than via the console and ensure the console requires physical access in a secure building.
    1. Deny root level access completely if paranoid.
  6. Encrypt your disks – this keeps those who may steal your VM Image from being able to use it.

Hackers will exploit those details you have neglected !!!

Leave too many ports open with root level access and YOU will be hacked !!!

Make things too convenient for your own use and YOU will be hacked !!!

Remain ignorant of how hackers work and YOU will be hacked !!!

Be lazy and stupid and YOU will be hacked !!!

 

 

 

Advertisements

Bash 101 – Making a complex logical test much simpler…

Bash 101 – Making a complex logical test much simpler…

Yeah, I do Bash Shell Scripts !!!

Yeah, I do Bash Shell Scripts !!! 

Why does “crappy” code not perform worse than it seems to ?

I like good code like the next person however I am wondering why people spend so much time focusing on “crappy” code patterns that don’t seem to perform worse than expected ?!?

Here’s a thought:  If you want to complain about “crappy” code then why not fix all the crappy code you become aware of including all that stuff you cannot seem to understand !!!

Or maybe just realize the fact that your idea of “crappy” code may be another man’s treasure !!!   Oh wait, someone already thought of this when the following was coined, “…one man’s trash is another man’s treasure…”. Circa. 1570’s !!!

Or to put this another way…   those who feel some coding patterns may be “crappy” might just be limiting their own ability to perceive really useful code they would surely have overlooked !!!

I am NOT in favor of truly crappy code !!!

But, I am also NOT in favor of being so close-minded that I cannot see how useful alternative coding styles may be.

Single instances of “crappy” code cannot be crappy !!!

If you have to produce 1000’s or 1,000,000’s of iterations to see a performance problem from a single use chunk of code then there is very little reason to think about any such performance problem !!!

I might be impressed with those who rail against “crappy” code who also make darned sure all the code they can see in their field of vision is not also “crappy” code !!!

Scenario #1

For instance, consider the following pattern that was recently classified as being “crappy” by an intrepid band of hearty Python coders in an company we dare not name here…

This is “crappy” !

toks = ‘one two three four five six seven eight nine ten’.split()

This is not !

toks = [‘one’, ‘two’, ‘three’, ‘four’, ‘five’, ‘six’, ‘seven’, ‘eight’, ‘nine’, ‘ten’]

The crappy version was said to be “crappy” because the split was seen as being unnecessary because the non-crappy version was said to be the desired effect.

Those who said the crappy version was crappy have probably never had to load a list from a comma delimited jungle of data they may have had to spend several days entering manually by hand otherwise they may have gotten themselves some useful experience as to why the crappy version might be somewhat less crappy after-all.

Scenario #1 Benchmarks

I like benchmarks.  I like to know when code may perform badly at run-time at scale.

The crappy version for Scenario #1 runs 5x slower than the non-crappy version for 1,000 iterations.

The crappy version for Scenario #1 runs 7.6x slower than the non-crappy version for 10,000 iterations.

The crappy version for Scenario #1 runs 7.65x slower than the non-crappy version for 100,000 iterations.

The crappy version for Scenario #1 runs 7.66x slower than the non-crappy version for 1,000,000 iterations.

Um, if you turn-off the Python GC the performance issues seem to disappear for a while !!!  Just a thought…

Scenario #1 Analysis

The real question is this:  “Was the crappy code being used enough for the comments this code pattern elicited ?”  Probably not !!!

The justification for call the crappy version truly crappy was the performance concerns and there are some rather glaring performance concerns to be sure but ONLY when the crappy version was being used 1000 times more than it actually was being used.

Those who claimed the crappy version was “crappy” had to magnify the usage pattern by a minimum of 1000 times before the crappy version’s performance data might be measurable.

I agree the crappy version would be truly crappy if it were the actual source of some kind of measurable performance issue related to the loss of revenues or some other demonstrable effect that was actually causing some kind of problem.

The problem, as I saw it, had nothing to do with how crappy the code pattern may have been because let’s face it this is crappy code if it were to be used often enough for a problem to exist.

The problem, as I saw it, was a group of people all agreeing there was a problem where no problem really existed at-all simply because in their minds they were magnifying the problem by 1000 times just to be able to catch a glimpse of some kind of problem when there was no real problem at-all.

This piece of crappy code may have a real-world non-crappy use case that could have saved someone a lot of time, given the right set of circumstances related to having to maintain a huge data set by hand that had to be loaded into a list at run-time.  The desire to make this crappy-looking code non-crappy in a use case that could NEVER be actually measured as being crappy is the problem !!!  Far more time could have been spent entering all those commas and quote marks just to make the code less crappy than the effort would have been worth.

Why any person or group of people who are supposed to be intelligent talented software engineers would claim a harmless chunk of code was harmful given the actual use-case that existed in the actual source of the context for the original question which was related to a single use of the crappy version is well beyond my ability to comprehend in real terms.

The person who raised the issue was supposed to have more than 20+ yrs programming experience !!!  He found a single reference to the crappy version in a source file that was probably being used exactly once per iteration of some larger program.  WOW !!!  Talk about yelling “FIRE” in a crowded room !!!

The people who agreed with him were even more of a mystery because these people are supposed to be among the best and the brightest at this particular unnamed company and they went along with the idea that was raised by the one guy who should have known better than to yell “FIRE” in a crowded room.

It is interesting to note, these same people who were able to inflate a potentially crappy use-case beyond the original scope are the same people who are seemingly okay with all the following truly crappy coding patterns they seem to wish to do nothing about:

  • An Eager-loading ORM that maintains and uses exactly 1 Database Cursor per Session !!!
    • Why was this NEVER changed ???

I will stop here with the analysis because I think this one point bears further analysis.

How in the world do these crappy detecting software engineers allow an Eager-loading ORM to exist in the first place ???   And the company wants this sort of thing corrected !!!

I have to wonder about the skills these crappy detecting software engineers actually possess when they cannot find a way to remove the Eager-loading ORM in the first place !!!!

Removal of the Eager-loading ORM would be easy enough, for me to accomplish, but then I can tell the difference between crappy code that is really crappy versus crappy code that only seems to be crappy.

Well You See Timmy…

Now for the moral of this tale…

People who live in glass houses always seem overly eager to throw stones when their own houses have cracks in the walls so wide everyone knows there are problems.

I have no issues with people who can see imagined problems that don’t exist so long as they have their own houses in order but this was not the case in this instance.

These very same people, who seemed more than willing to detect crappy code patterns where there was no crappy code use case are the very same people who seem unwilling or unable to resolve glaring performance issues in a huge pile of code.

The rest of the issues these people could focus on are as follows:

  • mod_python rather than wsgi
  • Django not being used-all but then there is no discernible web framework being used at-all.
  • Eager-loading ORM – easy to resolve with Django.
  • Non-scalable Web App – because mod_python is being used rather than wsgi, for instance.
  • Development environment issues – all developers share a single instance of the run-time – each developer gets a different virtual host but all development being done in a single Linux instance.
    • Okay, this one truly baffles me !!!
    • How difficult can it be to get each developer their own Linux instance at a moment in time when everyone has a Cloud-based solution for doing this ?!?

Look, all these issues can be easily handled but none of them are being handled at-all.  Why ???

The reason(s) all these glaring issues are not being handled is easy… lack of experience and lack of skill in the developer community.

Nobody wants to make any real changes or nobody is able to make any real changes.

Dragging along ancient code from the deep past and then being either afraid to update it or unwilling to update it is more than ridiculous !!!

Solutions !!!

The solution for all this is also easy but very difficult to implement !!!

Rewrite your code every 18 months !!!

Better tools are being churned-out all the time.

Django is a proven Web Framework !!!

Wsgi is a proven technology stack !!!

Python+Django+tornado+wsgi+nginx equals a scalable Web App that scales as easy as you can build an automated process for spinning-up one more Linux Virtual Machine in the Cloud !!!

Or let’s put this another way…

Python+Django+tornado+wsgi+nginx was easy enough for me to handle all by my self – not that I might not have wanted to do this with a team of others – there just weren’t that many others I might have done this with.

The moment I achieved my first stable installation of Python+Django+tornado+wsgi+nginx I knew it was the way to go !!!

Python+Django runs as a separate wsgi web server with performance comparable to what you get from the Google App Engine, oddly enough, and “yes” I have run benchmarks that tell me this based on the data.

Tornado is a stand-alone Python-based Web Server with very good performance characteristics.

Tornado talks to an instance of a Python+Django web app via wsgi.

Nginx talks to an instance of Tornado that talks to an instance of a Python+Django web app via wsgi.

Why so many web servers in this stack ???

Why use Tornado at-all ???

I happen to know a little something I call Latency Decoupling that tends to make web pages serve much faster the more layers of web servers you use.

Nginx connected to many Tornado servers each connected to one or more wsgi Web Apps is far more efficient serving web content than Nginx connected directly to that very same wsgi web app.

Latency Decoupling kicks-in and your end-users have happy faces.

Ability to Scale the Web App also increases !!!

Many instance of the Web App within each Tornado instance !!!

Many Tornado instances within each Nginx instance !!!

Deployment gets easier !!!

Now with a single Python or Ant script you can spin-up yet another Amazon EC2 instance – connect-up the Nginx instances using a Load Balancer of some kind (nginx also does Load Balancing) and before you know it you have architected a really cool Django Cloud Solution that nobody else seems to have just yet.

Build a slick Control Panel for your Django Cloud Users and bingo you have the ability to grow a Web App from a single instance to any number just by clicking a button on a web page !!!

The only other detail would be how you monetize all this into something you can use to generate revenue.

All of this was easy enough to build when you have all the parts.

All of this should be easy enough for any company to use, if only they had I.T. staffers who had played around with these kinds of solutions but alas that seems to be lacking in most companies except for a few.

Too bad most would-be skilled programmers would tend to scoff at most of what’s written in this article as being some form of “crazy”… but then once upon a time the notion of generating electricity was also seen as being “crazy” along with the notion of gravity and quantum physics.  I can live with what others wish to say… so long as I get to build something really cool along the way.

String splits versus lists for static data ?!?

Every so often someone will ask a really interesting Python question, this is not one of those however the data seems to disagree with the opinions.

In some python code, I see this:

switch_fields = “id switch_model ip”.split()

which is surely the same as this:

switch_fields = [‘id’, ‘switch_model’, ‘ip’]

Since the intent is clearly to create a list of three items, why would someone create a string instead and invoke a string method to create a list?

My preference is for the “say what you want” side; I don’t consider myself to be a “Python Programmer”, though.

Some responses from various Python programmers…

I agree with saying what you want. I’d probably ask the author if they would ever be inclined to do the reverse, i.e. switch_field_str = ‘ ‘.join([‘id’, ‘switch_model’, ‘ip’]) to prove a point about how confusing/silly that can be.

 

     I agree, there is no logical or practical reason to have a static string that has a split performed on it every time the code is run. It is a waste of computational time.

Now for my response…

I was curious…

I had to run over 100,000 iterations to see a measurable difference…

Apart from the run-time differences one might find it easier to maintain code with static arrays loaded from string splits especially if one had to sit and type a lot of quote marks and commas… or maybe I have had far too many late night coding sessions in my past.

Thought I would share the attachment.

Seems the data does not really seem to support the opinions if the concern is computational time and performance… unless you wanted to do the string splits to list thing something close to 1,000,000 times; even 100,000 iterations is nothing you can measure let alone notice.

Eh, such is life.

Built-In Unit Test !!!

This code has a built-in Unit Test

You know what…  I think this means I know how to write Unit Tests !!!

Well I wrote this one anyway – this is my story and I am sticking to it… LOL

Total Domination Nuclear Strategy Survival Guide #1

Total Domination Nuclear Strategy Survival Guide #1

This is my own perspective on this rather fun game from the viewpoint of a software engineer who has made a living reverse-engineering software from the outside looking in… See also: The Game.

The one part of this game that is weaker than the rest is the combat system for the following reasons:

  • You always know when an attack is coming.
    • You don’t get to know how much force is coming but you know exactly when it is coming.
  • You can easily keep your forces safe from attack.
    • Place troops in-transit from your base (Sector) to that of an Ally or Clan-mate – troops in-transit are immutable while in-transit.
    • Troops can be moved as-required to avoid attack.
    • Move your troops to a different friendly base every day to lessen the chances of being attached with not online.
  • There is no way for an attacker to know where you have moved your troops.
    • Other games have handled this problem however this is not the case with this game.
      • Other games ensure no players can ever remain completely safe for long however it is possible to evade attackers until they find you.

 

Surprise attacks will come from your neighbors !

Your closest neighbors will give you between 20 mins and 1 hour advance notice before they can attack… All others will give you far more time to act.

Drones, Drones and even more Drones

Build or buy drones.  The more the better.  Use drones in packs of 20 escorted by a Prototype Drone from the Black Market.

Raise your Intelligence Defense Bonus to the highest level possible.

Raise your Sector Defense Bonus to the highest level possible.

Buy Troops from the Black Market

Cannot say this often enough.  If you don’t have sufficient force you cannot Raid to collect income.  He who pays the most becomes stronger than those that don’t.

Weaken your Neighbors !!!

Raid them often and hard.

Build your Clan !!!

The world is filled with those who won’t want to do what this game requires, which is to spend money, but they will be drawn to the game nonetheless.  These are the people who are bulding wealth for you in this game.

Raid them and then offer to let them into your Clan or make them one of your Allies.  Allies cannot raid and they cannot invade.

Play Smart !!!

You don’t have to lose units to those who Raid or Invade.

Units you place in-transit are immutable.

Pick one of your Allies where you can Garrison your troops.

The ideal scenario is to somehow make a member of another Clan one of your Allies… if the attacker is somehow able to figure-out your strategy and your troops are attacked when in the Base of one of your Allies who is in another Clan it will be the 2nd Clan who will defend your troops from Attack.

Place your valuable troops in-transit with less than one hour before the attack.

Game mechanics favor those who are lazy or stupid.

Sending Reinforcements takes about 60 minutes regardless of the destination.

This generally limits the window of opportunity for those who may be smart enough to schedule a coordinated attack against you and all your Clan-mates (unlikely).

Your units will be completely safe !!!

Immutable troops are safe.  Nothing can attack troops that are in-transit.  There are no game mechanics that can reveal where you have Garrisoned your troops.

Garrison your Troops whenever you will be away from the game !!!

Your Ally will feel the love and your troops will enjoy being alive.

Recall your Troops and continue playing the game… at your leisure.

Leave a small force in your Sector to make the enemy feel as though they won the attack against a super-small force – this just might make the person on the other end feel as-though you are not even playing any more and this may be enough to keep that person from making more attempts.

Make as many alts and you can…

Alts are great for making resources for you…

Use them and abuse them, they won’t mind…

Each alt will boost your resource production based on your level of effort.  This is an inherent weakness of Free to Play games like this one, Alts that can be used to feed resources will give you an advantage.

Build Troops right before the attack.

Use your Resources or lose some of them… it’s up to you !!!

Use Crystals to Boost your Builds… gotta spend money to play this game, might as well get over it right away…

There is no requirement to lose Troops in this game !!!

The only people who will lose anything in this game are those who fail to understand how they can avoid losing troops in this game.

Buildings are immutable.

Resources are somewhat protected – Raiders are limited to what they can take.

Invaders get nothing but a raised Invasion Score.

Invaders can be over-thrown when you recall your Troops from where you sent them once you knew there would be an attack.

Let your Enemy give you more information than you give them.  He who commits forces first loses !!!  He who commits forces first becomes weaker !!!

Leverage what your opponent cannot possibly know about your sector !!!   There a ton of information those who attack cannot possibly know about you.  Your Allies being one of the most effective counter-measures you can use.

Have fun !!!  And be safe !!!

%d bloggers like this: