1,000 lines of Python

Did I ever think I'd intentionally write 1000 lines of python code?   Not really.   But I'm getting up there.

Python is pretty good for parsing through XML files and gathering the data.  From there, it can be used to compare that data to expected results.  Auditing.  

When I first thought of the idea of auditing Verifone Commander configurations, I never contemplated what it would take in time, code, and labor.   It's been a lot of all of.  But now I'm almost up to 1,000 lines of code to audit a Verifone Commander system.  

I wish Verifone would make their equipment scale better.  Enterprise level management would be awesome.  Then I wouldn't have to cobble tools together using Python, Powershell, and AutoIt.  

So how does all this work?   AutoIt is used to automatically backup every single site.   Once the backups are complete, the audit script will run over the files to examine what the settings are in comparison to what they should be.   

So at the point of originally writing this, the code was just barely reaching 1,000 lines.   It has since broken into numerous modules and is closer to 4,000 lines.  And I've still got about a dozen files to go.

Maybe I need to spend more time researching better Python coding.  Or a way to organize libraries better.  But going through 1 file that's more than a 1,000 lines of code is a pain.  So it's easier to break the things into separate modules. 


I guess the other part of this....  is it worth it spending probably 40 hours writing an estimated 6,000 lines of code to audit a system? 

Yes, yes it is.

Baby dos and don'ts

This one is going to be long way off from anything I've discussed recently, but that's okay.  It's my blog and I'll post what I want to...

Baby Do's and Don'ts.

First: I'm not a medical doctor.  I don't play one on TV.  This from my experience.

This is going to be more of a cheat sheet than anything else... 

Do: get a swing.   Let the baby sleep in the swing.   

As a parent, you will get better sleep faster.

Why?  As a mom walks around, she sways back and forth constantly, rocking the baby to sleep.  So the baby is used to getting rocked to sleep.  After birth, we expect them to instantly fall asleep on their backs (which they haven't been laying on for the last 9 months) on a stationary object.   That's a recipe for disaster. 

Just try and change the way you sleep.  Go ahead.  I'll wait. 

And for the record, I've done this before.  Even minor sleeping changes are a pain.

Do: ignore the schedule the hospital gave you.   

Yes, you should feed the baby.  Yes, you should verify the baby is peeing and pooping enough.    But mechanical feeding every 4 hours?   Get real.  Since when do you do that?  If the baby is hungry, it will tell you.  By yelling at you and crying. 

Don't: pay super strict attention to the schedule the hospital gave Mom.

What?  You mean you don't want Mom blocked in sunless room devoid of exercise for the first two weeks?    No. I don't. 

Sunlight and light exercise (walking.   Just walking)  are the best things to stop post partum depression before it starts.  Depending on the delivery, and how your body feels go for walks and gets some sunlight. 

If those two things are normally linked to getting rid of depression, then you should probably do them. 



That is all for this round. 
And yes, I do have kids.   4 of them, now. 

The Brilliance of Companies

I've worked for various companies over the years, and I've realized a few things.

The most important one is this: the crowd is not smarter than you.

Perfect example of this kind of logic: we don't like situation X because of the way we did this.

Let's go build another one with the same problem as X.


I wish I could be more specific, but it's an ah-ha moment when it happens.  It's the smartest people in the room complaining for 20 straight minutes about a design they created, then refusing to fix it in the next new design.

People: this happens everywhere.   The Abilene Paradox is still alive and well.

Network Security on the Cheap, part 2: Graylog

So, I've spent the last couple of weeks setting up GrayLog in a cluster.

Giant pain in the butt.

My build was Ubuntu 16.04.  And that works fine.

Lots of stuff that is not mentioned, or even thought about.

A few things I had to solve...

1) Elasticsearch needs to be on the same version
2) Mongodb needs to be at least version 3 or higher.
3) The web URI information is badly documented.
4) A cluster won't form until you are using the same database for all servers.

I set up a router in front of my setup, resulting in a NAT'd public IP address and the cluster behind.  Gives plenty of room for growth without ever readdressing anything externally.

Based on recommendations, I changed the listening port to 12900.   Not sure the implications or reasoning of that.  But it seems to work for me.

So, private IP is IP of the server.
Public IP is the NAT'd IP of the server. 

rest_listen_uri =  private ip/api/

web_listen_uri = private ip

web_endpoint_uri = public ip/api/

rest_transport_uri = private ip/api

forgetting the /api/ on the web_endpoint_uri causes a specific issue

It's the cannot POST issue.

Don't forget the /api/ setting.

Once that is done

I also load balanced the web interface using HAProxy.

Final thing about Graylog, and one I wondered about...

Once I've got the cluster up and working, do I need to load balance my UDP syslog traffic?

Short answer: probably not.

Though it doesn't look like the other servers in the cluster are doing anything, they are.  Easy way to tell is look at the number of messages waiting and processing.  With 2 servers in my cluster, my waiting and processing at 4,000 messages per minute sits in the dozens.  There's never a queue.

So, with two low power computers and a whopping total of 14 GB of RAM, I process 4,000 messages a minute with zero wait.  That includes bursts of up to 6,000 messages per minute.

I'm not saying you won't need to load balance the UDP traffic.  I'm saying you need to base it off your scenario.  And figure out how many messages per minute you are getting.

Generally, UDP is low overhead network traffic anyways.  The general problem is not that you can't receive enough data.  It's that the data takes too long to process, resulting in a queue.  That's the purpose of building a cluster.

Total cost at this point?  3 cast off computers that aren't good for much else.  One of my computers runs 6 GB of RAM and runs 100% CPU usage.   Yet it still handles enough to reduce the load of the primary computer.

Network and Security on the cheap

Networking security and monitoring on the cheap

Building a complex network scheme requires a lot of knowledge and experience.  It also requires a bit of insight and guesswork into what can and should be used.  Trying to do all this without budget is even worse.  You basically don't have any chance to do it correctly.  

Or do you....   

See, part of the problem is not knowing the tools are there in the first place.  And because the Internet is big into open source, you've got plenty of options once you become aware of what they are.  So that's what I'm going to try to deal with here.  Trying to build a defensible architecture based off spending the least amount of money as possible.  Saving the money on these tools allows you to spend that money else where.  Like in good firewall. 

Love them or hate them, here's my recommendations.  

Network monitoring - Paessler PRTG

Log Management - GrayLog

SIEM - OSSIM

Firewall -  Palo Alto

Patch Management - WSUS

Now, before I get yelled at...  

1) I don't deal with much of a web presence, so I don't have to fight with Web Application Firewalls.   I mostly deal with brick and mortar.  If you've got a web front end to deal with, I can't really help you.  

2) Palo Alto is expensive.  But it is awesome.  Money spent there is well worth the spend.   

3) PRTG is only free for 100 sensors.  100 is better than 0, which is probably what you are monitoring now.   And running a ping here and there is not monitoring.   Don't even pretend.   

Sure, many of these platforms are free.  But you will spend a lot of time in sweat equity.  Don't expect an easy time with setup and tuning.  Expect to spend a lot of time beating your head on the wall, trying to figure something out. 

The other part of this is do what everyone says to do, but no one does: document.  

Documentation is the untold glue that holds all these train wrecks together.  Spend a lot more time documenting than you think you should.  Because that first time you have to rewrite a script to get your Graylog server to accept traffic on the correct port, you'll wish you had.  Because you'll forget about that script, and reboot.  And because you didn't write it down, you'll have to figure it out again.  No fun.

Or when your Graylog setup script gets overwritten due to an upgrade.  Fun times.  Fun times.

Han Solo was right

Han Solo was right.

Short-circuiting your thinking

Seems like I've spent a lot of time thinking about my thinking.  Strange and interesting to say the least.  Anyways, I came across an interesting thought. 

Instead of trying to short circuit your thinking in the moment, come up with something to short circuit your thinking that has already been prepared.  It seemed like a simple idea. 

Because I couldn't stop the train wreck of thoughts going through my head during the process.  Without a lot of practice, it's almost impossible.  Especially if you've been conditioned to think in the wrong manner.  And most of my thinking has been in the wrong manner.  It's hard to say that, but yeah.  Most of my thinking has been flat out wrong.  And has been wrong for years. 

To say it's wrong is to have some sort of argument with the knowledge that I know the right way.  Which is completely untrue.  I spent years being conditioned to think incorrectly.  It was probably me that caused a bunch of it.  But I never stopped it.  To say growing up sucked was an understatement.  But that crap conditioned me to think incorrectly.

So how in the world am I going to solve this problem?  I'm going to try something new.  And if it doesn't work, I'm going to try something else.  If that doesn't work, I'll try again.  Because what I have been doing hasn't been working.  There's just too much mental baggage to get my brain going in the correct direction without a prepared answer.  Too many years of not believing I was worth a damn. 

But what you can do is right down what you want to believe.  And listen to it frequently.  Listen to it? 

Here's the cheating part.  Because it's so damn easy. 

Come up with your script.  Come up with what you want to be. 
Write it down.
And record it in your own voice. 
And then, play it back frequently. 

Try it for a month.  See what happens.

See, because you don't rise to the occasion.  You fall to the level of your training.  So you have to develop a new form of training. 

And the easiest way to train yourself is auto-program responses.

Try it for a week or two.  I'm pretty sure you'll love the results.