I.T. Security and Linux Administration

February 28, 2013  8:01 PM

Advise From the Admin Part 3: Make variables easy to find

Posted by: Eric Hansen

Software like Shorewall is awesome.  It makes managing software firewall easier than eating pie without a fork.  However, it has one issue: global variables.

A good example of this happened to a friend not too long ago.  In the config files existed some variables (we’ll call them SOME_NET and ANOTHER_NET).  However, they were never defined anywhere.  Not even doing my favorite grep -r -H “\$SOME_NET” . did any good.  As far as I know he still never found out where or what it was defined as, but the horrific troubleshooting still seemed too unfair.

Learn where variables are set, and please keep it there.

February 28, 2013  7:56 PM

Advise From the Admin Part 2: Make configuration easy

Posted by: Eric Hansen

When creating configuration files for software you’re writing, do not make it so difficult for the end user to edit them.

Naming a variable “window_x_pos” or “fullscreen” is easy to understand and know what it does.  Naming a variable “deep_dark_interesting_option1041239″ is like taking a sword and driving it through a table and hoping to make it go through…it doesn’t make sense.

February 28, 2013  7:51 PM

Advise From the Admin Part 1: Don’t try to do tricky things

Posted by: Eric Hansen

This will probably be short, but should still be addressed.  When you are configuring systems, don’t make the implementation convoluted.  It won’t fair well for you in the future when you have to troubleshoot.


When I had to reconfigure my servers due to data loss, I wanted the channels to be secure.  Well, making a long story short, I made it so ports 143/tcp and 25/tcp required SSL/TLS.  That’s fine, normally.  Small mis-hap in configuration but easy to handle.  Not when you have to spend 4 hours trying to get software like SquirrelMail to be able to connect to tls://mailserver.domain.tld:25.  Granted, the configuration for SM 1.4.x is annoying anyways, but none of it even made sense.

February 28, 2013  7:47 PM

Mobile Payment: Part 3 – Chirpify

Posted by: Eric Hansen

Swipe, founded by one of the founders of Twitter, I feel missed the bullet on one important service: Twitter.  Twitter is meant for microblogging, and socializing.  What better way to get the word out about a product than by social media, right?  That’s where Chirpify comes in.

Chirpify is a payment method based on Twitter, where you send out specially crafted tweets that are then fed to Chirpify, and it does the payment processing for you.  It also lets you sell things as well, which is nice.  Its like the new eBay, but also on a lower scale.

One of the best features about it is you don’t have to enter your card information when buying.  Instead, the information is entered on Chirpify’s website and is stored there.  So its kind of like paying for something on eBay with a PayPal account.  You give PayPal your card and/or bank info, and then when you go to pay for something, you just tell it what to use.  Similar to Chirpify, just less annoying (don’t have to log in to pay).

I feel this can really help improve businesses, but it would be difficult to implement in store.  What I would like to see is the ability to have a list of things that were bought by a phone number, and there be a dedicated employee who checks the user’s phone number against a database.  Any issues that arise can be solved by the user pulling up a screen on their phone showing what they paid for, how much, date and time.  Is this more work?  Yeah, but it is still a viable solution for the market.

February 28, 2013  7:38 PM

Mobile Payment: Part 2 – Swipe (and other payment processors)

Posted by: Eric Hansen

I’m sure you’ve heard of Swipe before.  A device you plug into your headphone jack to swipe cards and make payments.  It’s pretty flexible and intuitive, and is created by one of the founders of Twitter, even.  They’re also one of the most cost effective producers as well (they give their device for free, while most others you have to pay for it).

Its interesting to see where Swipe has taken taking payments.  They’re trying to revolutionize having to give the waiter/tress your card just for them to take it away to a register somewhere, swipe it and such.  Instead, they could do it right in front of you without issue.  Fun and awesome, right?

The problem is in security.  To make a long story short, Swipe doesn’t make the action secure, as it relies on the audio channel and just fetches the noise.  Audio in itself is insecure, so why would something using it be secure?

A better approach would be a USB-based device that did the same thing.  However, two issues with that:

1.  Costs more

2.  Android 4.0+ by default doesn’t like things plugged into the USB (tighter security)

So what is one to do?  They can always go with a different medium, and one that is actually pretty surprising.  In our next article!

February 28, 2013  7:33 PM

Mobile Payment: Part 1 – Why?

Posted by: Eric Hansen

Smartphones are a growing essence in the world of everyday use now.  Almost everywhere you look you see someone with a smartphone and they’re Facebooking, Tweeting, etc… on it.  Heck, the only person in my age group (mid 20′s) I know of that doesn’t have one is my fiance.  Though, she does have a tablet.

So, why aren’t stores picking up on this growing trend?  Most of it has to do with cost.

Think about it, they use point of sale (pos) systems.  Many very low-end machines that are tied to a mainframe or 10, which handles the transactions.  They have been in place since the beginning, and only in the last decade have really began accepting credit cards.  Look at the self-service scanners, and how long it took to become popular.  Even when I was a kid I thought we would’ve had such technology by 2000.  Where I live, it didn’t happen until around 2007.

I do remember, though, when I went to Maryland not too long ago.  I took a cab, and they accepted credit cards.  Now, before anything, the last time I experienced this, it was in Columbus, OH with the taxi driver having one of those card swiper things from the 80′s that imprinted your card on a receipt.  So, I figured that’s how it would be in Maryland…nope!  They used Swipe.  Boy I wish I knew that before hand, I wouldn’t have carried cash.  But, it was what it was.  It was also interesting to see how different places are taking technology.

Retailers should start really considering it as well.  They already accept payments online.  The trouble, as said, is that they would have to basically rebuild their entire infrastructure, which could cost millions if not billions.  Its had to weigh out the return on investment of something like this when there’s no data to go off of.  But its impossible to build up the data because everyone is afraid of doing it.

February 28, 2013  7:22 PM

Hacking the EU

Posted by: Eric Hansen


While stories like these tend to get old to me, this one is an exception, because it shows that a dog’s old tricks can still prove to be worth points.

Now, there’s two people at fault here, in my eyes:

1 – Adobe: The exploit’s been there since AcrobatPDF v9.  While not every bug will be found, I have a hard time believing it was safe for that many years (going on 5 years [2008-2013] now).

2 – The government agencies: I just have this increasingly sinking feeling that this is due to them still using v9, when v11 is out in the public as stable now.  Why?

The article also mentions the attack being found in America as well, but doesn’t do much to touch on it.  I guess which makes sense, since most of the attacks in the article are in the EU.  But, in the article, it states that the writers found a way to bypass sandboxing.  This isn’t new methodology, and in fact is quite old.  So, why haven’t these been fixed?  Heck, Adobe’s software has been under the gun quite a bit past few years due to countless number of attacks (think Java).  Every month there seems to be a new 0-day out for one of their products.  I feel moving to a different PDF reader, though, won’t fix the problem.  PDF is a pretty standardized format.  The issue should be addressed of the readers themselves detecting corrupted PDFs and not allowing them to load.

Is it that simple?  Knowing my luck, probably not.  But one can dream.

February 28, 2013  6:54 PM

China vs. USA – Hacking (part 2: outbound traffic)

Posted by: Eric Hansen

In a previous article, I wrote about how China is playing the wolf, and its not pretty.  Going over the inbound traffic to their “great firewall”, I outlined some fine points…and now, we will address outbound traffic.  This is something I also touched on in the previous article.

Outbound Traffic

I mentioned before about 0-days existing on their servers.  While it doesn’t always make sense to have the whole 9 years of security on a server (why have a virus scanner on a proxy server?), a firewall on these should always be installed and configured.

We’ll go back to Security 101.  While passive firewalls have a place, restrictive firewalls are typically the go-to, and should be mandatory in government networks.  You should only allow the traffic that needs to go through, and block out the rest.  This being said, it seems a little implausible, though do-able, that America had a company such as Apache, set up a mechanism to allow a back door on only Chinese machines.  Even more so due to Apache’s open source nature.

Yes, there is always the use of DoS attacks and the like, but governments everywhere (as far as I know) keep hush-hush about what actual attacks are done.  You can detect all the DoS attacks you want, but it won’t prove beneficial to anyone.

Truthfully, and I’m sure a lot of people will agree, the whole risk of China being attacked sounds more like them being a baby, when it’s also been widely reported China has whole divisions dedicated to hacking countries.  I’m sure America does too (NSA?), but we keep it more quiet as well.

February 28, 2013  6:47 PM

China vs. USA – Hacking (part 1: inbound traffic)

Posted by: Eric Hansen

Hacking in America has really gained a lot of attention this year already. February alone seems to be the month of hacking. There was an interesting article posted on Yahoo today though (http://finance.yahoo.com/news/china-says-u-routinely-hacks-130252420.html), basically saying that China is trying to play victim in their mind games.

I had a discussion with a friend earlier today on it, and here’s one thing that, as an outsider, I don’t understand: if China’s “Great Firewall” exists, why is it allowing all of these hacking attempts in to them to begin with? Lets think about this for a moment.

Inbound Traffic
Logically, most hacking attempts on the government, based on the article, is going to be with inbound traffic. Now there’s two scenarios that can be played out on this: 1) USA proxies attacks through other countries (possibly allies) and 2) USA doesn’t care and attacks them with little/no proxying.

We’ll make this a bit more difficult and go with #1, and for sake of ease we’ll assume USA uses Tor. There is still no real way that the attacks should be allowed through. Mind you, I’m thinking about this in similar manner to having a firewall on my home network and Billie Joe down the street is trying to hack. Proper configuration eliminates roughly 90-95% of the risks out there. One can then deduce that China’s firewall is not properly configured.

Throw in the possibility that a 0-day attack is used. Most well known software seems to be developed in America (Apache, IIS, mongoDB, MySQL, PostgreSQL, etc…) This would give America an advantage in that regard. This would mean that the risk now lies on the server where the software’s installed. Again, proper configuration eliminates a large chunk of attacks. It is then possible to come to a logical conclusion that China either knowingly or unknowingly is leaving holes in their network.

They’re basically baiting other people to hack into them.

Next article, we’ll focus on the outbound traffic and see if we can come to any other conclusions.

January 31, 2013  3:48 PM

How Have Security Practices Changed (2009-now)? Part 4

Posted by: Eric Hansen

Then: #16: Use A Centralized Authentication Service

Now: Same?

A “centralized authentication service” is only useful if it’s not a single point of failure. It’s an issue I think most people overlook, too.

It’s nice having LDAP installed and being able to authenticate against it, but if you only have one instance of it running, what happens when the server goes down? No one can authenticate.

Safest bet would be to prioritize authentication: LDAP server (for example) and then allow system login if that doesn’t work.

Then: #17: Logging and Auditing

Now: Same

There’s so many tools out there now to help with this. OSSEC is a good log and filesystem monitoring service, Nagios is de-facto system monitoring and alerting, and auditing is becoming such a huge field as well. This, inline with tighter security practices, will most likely be your move viable answer to staying secure.

Then: #18: Secure OpenSSH Server

Now: Redundant

The use of PAM, firewall configuration and protocol 2 will make this a piece of cake to accomplish.

Of course, adding in SSH keys is nice, too.

Then: #19: Install And Use Intrusion Detection System

Now: Debatable

I love IDS and IPS solutions, but not every instance needs one.

If you have a firewall placed before the Intranet, you already cut out a lot of the job. Continue that with proper auditing solutions and you have a pretty robust solution. Also, until something like OpenVAS for IDS/IPS comes along, I’m not sure how beneficial a free solution will be (its not always easy talking your CFO into buying a license for something they don’t understand).

Then: #20: Protecting Files, Directories and Email

Now: Same

Goes in line with the auditing and securing this and that, but again, addressing points.

Proper audit solutions and system management will make this a piece of cake.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: