Simple Message Bus

The Simple Message Bus exists to resolve the problems one might encounter in building and deploying a complex system distributed among many Virtual Machines (aka. Cloud) where individual VMs may be online or offline at various times.  In this model, whenever one is using a REST Web Service Architecture one may find a target web service offline, for instance, and when this happens communications breaks down.

The Simple Message Bus provides a layer of persistence, for Windows-based applications in which the messages are stored locally in a directory until delivered to a remote computer where messages are once again stored persistently until consumed.

You can get the source code from here.

You can clone and modify to meet your specific needs such as making it work with Linux.

Enjoy.

Simple Message Bus

Advertisements

Decorated multi-threaded static methods

Decorated multi-threaded static methods

 

web.py and Django ORM together at-last !!!

web.py and Django ORM together at-last !!!

Django through the Firewall

Once upon a time, in a galaxy far far away… Yeah you probably heard that one before too…  Still developing a Django App behind a Firewall that has to interact with Amazon RDS and Amazon Elasticache might encounter a problem or two unless you read this post.

See also: SSH Tunnel Magic

The Problem

Developing behind a Firewall.

Cannot reach services like mailgun which can be used to send emails.

The Solution

Make Django Server communicate through a Proxy that happens to be attached to a Putty SSH Tunnel.

See also: PySocks

Adjust your Django App Startup as follows:

3-1-2013 1-58-45 PM

Your actual mileage may vary… some assembly required…  Obviously I tend to make modifications where few dare to tread but then I also get the results I want.

The Test

Ran the Django App and clicked the link to send an email via mailgun and bingo !!!  It Worked !!!

 

 

 

Can we stop Credit Card Fraud Forever Now Please ?!?

Simplest and most effective way to stop credit card fraud dead in its tracks would be to…

Make every Credit/Debit Card Holder buy a cheap ($9.95) security dongle that issues a 6 digit number – Corporations use these to secure their networks and this works !!!  Security dongle make a Bluetooth connection with your Credit/Debit card (obviously must be some kind of smart card…) which means any time your security dongle is not within 30 feet of your Credit/Debit Card your bank cancels your card for you automatically along with your security dongle and they reissue both as a paired set.  This allows the Security Dongle to automatically issue the 6 digit number for you when making a purchase at a merchant (gotta make sure the data is encrypted however – banks really suck at using encryption for this purpose…).

Every time you want to use your Credit/Debit Card you have to press a button on your security dongle to get a new 6 digit code that you enter when making a purchase.

Even if someone does manage to get your credit card number and zip code they won’t have your security dongle unless they steal it from you.

Done – no more credit card fraud !!!

Very little cost to banks other than development of a smart card and Bluetooth security dongle.  Banks could even use your Android of iOS smart phones in-place of a smart credit/debit card but then this has always been an option for the last 3-4 years.

Why banks don’t go this route is the amazingly stupid thing in my humble mind but then I am just the boob whose credit/debit card was recently hijacked which I don’t mind saying is what got me thinking about this problem in the first place.  I really seriously doubt anyone would ever both trying to hijack anyone’s credit/debit cards once this level of security was in-place and widely used.

Dual-Key or Public-Private key security has been around for many years.  It would not be difficult to create a very secure system at very little cost using Android/iOS Smart Phones with the ability for the customer to recreate a new Key-pair before or after each purchase in a safe and secure manner such that credit/debit card fraud could be eliminated completely.

Oh yeah, if Smart Phones could be used in-place of credit/debit cards I as a customer would be able to limit who can use my card to only those who fall within a very small geographic area simply by geotagging purchases, but again this just makes perfect sense.

Just my 2 cents now that I have to visit my local banking branch just to get the ability to use my own money now that my credit/debit card was cancelled and is in the process of being replaced for me simply because my stupid bank was too lazy or too stupid to figure-out how to ensure my money is as safe as it would be were it sitting in my own mattress at home.

Rant ends.

P.S. You all can thank me later when your credit/debit cards can also never be hijacked again !!!

SSH Tunnel Magic

SSH Tunnels can be quite useful for those of us who use them to craft our own very secure yet very simple VPNs.

Consider the following diagram:

2-24-2013 10-23-46 AM

 

Laptop sitting behind a Corporate Firewall connects with an EC2 Instance via SSH forming a secure Tunnel.

EC2 Instance #1 forms an SSH Tunnel to EC2 Instance #2.

Laptop is then able to Tunnel directly to EC2 #2 thus allowing access to an RDS Cluster and a Memcache Cluster directly as though they were connected directly to the laptop.

Why do all this ?

Very simply one can more readily develop a Web App meant to run in an EC2 Instance that use RDS and Memcache hosted at Amazon when the development environment is able to use both RDS and Memcache during development.  Deployment becomes quite trivial.

The Real Deal

The real point for all this should be rather obvious… Port 22 was the only port allowed through the Firewall however Port 2222 is the port EC2 #2 uses for SSH… obviously it was not possible to use Port 2222 directly from the Laptop.  SSH Tunnel resolves this and many other problems without having to make any changes to the Firewall.

 

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 !!!

 

 

 

%d bloggers like this: