Today we’re launching the Northern California Linux User Group. As far as I can tell, the closest LUG to Redding is the Sacramento LUG, and that’s just too far away! This LUG will be based in Redding, of course, and for now we plan on holding monthly meetings when the group achieves a large enough membership base.
For now, visit the site and sign up for the mailing lists! We’re still in the early phases, so be sure to suggest ideas and comments for the focus of the group.
Can someone take this weather back to Detroit where it belongs please?
It is pretty rare, but once in a while you can catch EXT3 at work; in the midst of removing a file, for instance. I just ran into one this morning:
I’ll be off at the liquor store buying lottery tickets!
Anyone that’s followed my blog for a while or knows me personally has probably deduced something curious: I’m a odd set of contradictions.
One side of the coin, I’m an avid technologist. I own an obscene number of computers, both Mac and PC. I’ve got an iPhone, and owned one of each generation. I cancelled my cable nearly a year ago and stream Netflix and local channels via Windows Media Center on a computer hooked up to my television. I don’t own a landline; all my telephone service is wireless or VoIP. Even my business is completely done on the web with Quickbooks Online and Google Sites, Gmail, and Docs.
Now flip that coin over: I have three, yes three, apps on my iPhone. I don’t use LinkedIn, Twitter, or Facebook. I have no desire whatsoever for a tablet PC or an iPad. I’m seriously considering purchasing an older (pre-1975) car to re-build as a daily driver and dumping my 2007 Aveo. I still write checks, fill out forms with a ball point pen, and do my bills via snail mail. I’ll call someone instead of texting them.
So what gives? Why the dual personalities?
I’ve been wondering that myself lately, and started keeping track of why I tend to do things a certain way versus another. For instance, I’ll not think twice in allowing Quickbooks Online (which is great, by the way) automatically post transactions in our business account directly from Chase, but minutes later I’ll be writing a check and affixing postage to an envelope addressed to the office insurance company. Insanity perhaps?
Well, no, as a matter of fact. You see my moment of clarification resulted from an airbag light and an accelerator pump. Let’s back up six months, and put our gearhead hat (or welding visor, for you true hardcore grease monkeys) on for a few moments.
I’ve had a lingering problem with the Camaro that anyone with old-car experience has probably felt before. When dropping the gas pedal to the floor, the car would stutter and hesitate for a moment (kind of embarassing in a muscle car!) and then finally pick up steam and roar ahead. The reason for this is due to the carburetor’s throttle plates suddenly opening all the way, and all the vacuum in the engine’s intake system disappearing for a moment while the engine’s RPMs spool up. For those not-quite-car-savvy readers out there, vacuum in the engine is what pulls the gas/air mix in and allows it to go ‘vroom’! No vacuum, no vroom.
Over the decades carburetor designers figured out that if a small syringe-like pump–called an accelerator pump–was physically hooked up to the cabling coming from the gas pedal, they could preempt this pause with a small squirt of straight gasoline into the throat of the engine. This provided some temporary “oomph” for a few seconds while the vacuum caught up with the driver’s right foot. Clever thinking, to be sure.
Now, let’s fast forward back to modern-day. My 2007 Aveo has an Airbag light on. Much to my chagrin, it is completely undiagnosable sitting in my garage. You must take it to a service center with the appropriate code scanners to even know what’s wrong.
So here comes my epiphany.
As an engineer and a tinkerer, I want control. However, I’m also lazy. What I’ve found is that if something just works, I’m willing to allow it to work behind a set of curtains–even if that means raising an eyebrow and surrendering a bit of control. However, if something is problematic nothing angers me more than not being able to fix it myself. In fact, I’ll even stop using it or throw it away.
I own the 2007 Aveo. I have the title, and it is lien-free. However, I couldn’t even obtain the specifications on how to diagnose the airbag system on the car even if I wanted to. Chevrolet doesn’t make them available, I’m sure because they’re afraid someone will set the airbags off by accident. So the question is, do I really own it? I’m still subservient to the manufacturer, even though I’ve paid for the product.
I also own my Camaro, and last weekend I finally fixed the hesitation problem by bending a piece of wire on the carburetor with a pair of pliers.
I’ve realized that this same disparity lack of control and trust is my issue with software and technology in general. As software is getting more and more complex, and nearly everything is online 100% of the time, quality and control is seemingly going south along with it. I doubt this is intentional by software developers; more likely its just the vast task of maintaining and QA’ing gigantic amount of source code. I’ve recently noted that when software or a piece of digital tech fails me, I get very bitter and don’t often go back and use it again. The same thing is happening with my 2007 Aveo, and I’m once again behaving irrationally about it.
So for all you software developers out there: Take a lesson from the carburetor designers of an era past. It’s cute to be clever, but simplicity and reliability are true genius. It seems software is going the wrong direction–placing features higher in importance over function and reliably.
Get back to to basics, and just write damn tight code. Your user base will thank you.
I’ll keep the Haynes manual handy, if you need to borrow it.
Almost 24 hours per day, The Linux Fix is inundated with FTP and SSH brute force attempts to our server farm. This has compromised a few our our customer’s accounts from time to time, and I decided it was time to come up with a solution.
The problem is tricky–we must leave FTP and SSH open to the entire world, but at the same time be selective on what we black list. How do you make that determination? Strictly on bad login credentials?
We could, but that would mean that we’d inadvertently lock out real users. A better solution we found has to do with timing connection attempts. With IPTables, we can keep a counter based upon source IP–and track how many new socket attempts are made within a certain span of time. For instance, if we detect the IP address 1.2.3.4 making 5 connection attempts within 60 seconds, there is a darn good chance it isn’t someone mistyping a password.
Here is how we did it, based upon another script we found out in the Internets:
#!/bin/bash /sbin/iptables -N SSH /sbin/iptables -N SSH_BLACKLIST /sbin/iptables -A SSH_BLACKLIST -m recent --name SSH_COUNTER --set -j LOG --log-level warn --log-prefix "Blocked: " /sbin/iptables -A SSH_BLACKLIST -j REJECT /sbin/iptables -A SSH -m recent --name SSH_COUNTER --update --seconds 300 -j REJECT /sbin/iptables -A SSH -m recent --name SSH --rcheck --seconds 60 --hitcount 5 -j SSH_BLACKLIST /sbin/iptables -A SSH -m recent --name SSH --rcheck --seconds 2 -j LOG --log-level warn --log-prefix "Added: " /sbin/iptables -A SSH -m recent --name SSH --update --seconds 2 -j REJECT /sbin/iptables -A SSH -m recent --name SSH_COUNTER --remove -j LOG --log-level warn --log-prefix "Removed: " /sbin/iptables -A SSH -m recent --name SSH --set -j ACCEPT /sbin/iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j SSH
This creates two new tables, SSH and SSH_BLACKLIST. Upon the intial connection attempt, the IP is added to the SSH_COUNTER counter. If the same IP address is seen again within 60 seconds, it is duly noted–however no action is taken until the hitcount reaches 5. In that case, the rules jump to the SSH_BLACKLIST table, it is logged, and subsequent connections from that IP are dropped for 5 minutes until things calm down. In order to do this for FTP, just rename the targets as appropriate and change the target port to 21 on the last line.
The nice thing about this set up is that it is auto-cleaning. After 5 minutes of no activity, the counter forgets about the IP address and things return to normal. We’ve found that this is just enough protection to drastically reduce bruteforce attempts, yet not get in the way of normal usage by our customers. Over time, this has become our favorite technique and we’ve begun to implement it on any Internet-facing machine with open SSH ports.
Written by 
Recent Comments