Be Excellent To Each Other

Had the misfortune of being on a conference call with an IT Consultant today. We'd been put on to him to help us with an SSL query we had but the conversation went onto hosting, Apache, MySQL and basically anything else he thought he could sell us. I try not to be too critical of people, but this chap came across as an utter tool and I hope we don't end up dealing with him.

However, one bit of the conversation did leave me wondering.. we're hosting a simple HR system (just basic employee data and absence) and as we're trialling it with a few clients, we're looking into securing it. When he asked whether or not the MySQL tables were encrypted and we told him they weren't, he was utterly horrified (his exact words were "Oh.... my.... God" with plenty of dramatic pausing)

Now I must admit, still being pretty new to all this, I've not looked into encrypting mysql databases. In fact, with the tables being human-readable, it's handy for spotting problems, but is this something I should be taking more seriously? As long as the server and the app is secure, then is that not enough? I couldn't be sure if he was just scaremongering us into listening to what he had to say or not.


p.s. Another thing he said was .. "You're using Apache? It's a test server then?" Umm.. is there something wrong with using Apache for a live system?

If the server and app are secure, that is certainly enough. Just how sure are you that they are secure, though?

Multiple layers of security are a good thing.

And there's nowt wrong with Apache. What was he suggesting, IIS?

He's a dick.
As long as the tables are secure, there's no real need for them to be encrypted.

We're no security experts so we don't host the site ourselves so the server is only as secure as the hosts make it, but I'd like to think they had an idea as to what they are doing. The app wasn't written by us either but has been in development a while so hopefully that's secure too.

I did wonder if he was going to come across as a MS fanboy or something, but when we mentioned we were implementing CRM, he said 'I hope you bought Sugar CRM' and was puzzled as to why we'd want Microsoft CRM.

It's nice to have it confirmed that he was being a bit of an arse at least - although I wouldn't be surprised if parts of the conversation are filtered back to us via someone else.. "He said your tables aren't encrypted.. what are you thinking?!"

He phoned my boss back last night. "It's all about SQL Injections. By changing the URL I am able to drop a table" (we gave him a basic login to the app). Tempting to just to say "Ok, give it your best shot". Coincidentally, he's got a price for some hosting with friends of his... handy that.

Dick. Encrypted tables would do absolutely nothing about SQL Injections if you were vulnerable to them, anyway.

Sounds like this guy is just spouting a few things he's heard to make himself look clever, when he actually knows nothing.

You'll be required to encrypt the data in the table if you store credit card data, or maybe other financial data of that type, but as a general HR type system you're probably fine.

And Craster's right - encrypting data isn't going to make you any less vulnerable to SQL injection dropping tables.

I agree with Squirt. If there's any financials in there, you'd have to encrypt, because you can't control access to the host itself so the on-disk files would have to be locked up under PCIDSS. And yes, he's a dick.

Do so, but create a new table and him to drop that one, just in case.

The chances of him being able to do so are, I'd imagine, slim. As others have rightly said, encryption has fuck all to do with SQL injection. He's just dropping buzzwords.

Will do. I'm hoping we don't have to speak to him now. I don't think my boss was too impressed to get the phone call back at 7:30pm.

No financials stored though, so that makes life it a bit easier. In fact, the only thing of any interest to anybody is salary figures and I'd say that was debatable.

He's clearly a dick.

Hmm. If it's HR, you do store names, addresses, bank account details (presumably). I don't know what PII rules apply to whatever industry you're in, but we most certainly have to encrypt that stuff at rest and in transit.

I don't think HR usually hold bank details, that would be Accounts / payroll dept, no?

Depends how big the firm is.

True.
In a small company there'd be some argument for just writing that down in a book and keeping it in a locked drawer though

If you're using PHP, then it should be virtually impossible to drop a table using SQL injection anyway as (unless your app uses a custom MySQL wrapper or has enabled client multi-statements) PHP only executes one MySQL query, any other queries inserted using injection (or normal code) are ignored.

Guy's just being a colossal dick.

The guy is a total tool...
Ive been doing MySQL, PHP stuff for 5 years now, and the guy is definately a tool.
Around 2/3rds of live websites use Apache these days I think.

Anyway.. SQL injections...
The way they tend to work is this...
If you pass parameters to the webpage from a form, and then use them to look up stuff in the database, then they can be vulnerable.
For example...

is a typical URL for a page with a parameter.
The PHP then does something like
db->sql_query( 'SELECT stuff FROM table WHERE name='. $_name );

SO, to bugger things up, you then do stuff like:

If the web page was written by a complete moron, then this would do:
SELECT stuff FROM table WHERE name=bob;
DROP TABLE users;
(%20 is a space, %3B is a semi-colon)
which would try to run a query on the database, and then drop (delete) the table 'users'.
You could in theory add any old stuff to the end, and it would get passed into MySQL, so you can get it to output table contents, look through stuff, so you could basically browse & edit the database at your leisure.

However, recent versions of PHP will ignore anything after the first full statement (up to the first semi colon), and besides, all input should go through a function like this:

$_name = mysql_escape_string( $_GET['name'] );

which 'sanitises' the input and makes sure any non-standard characters won't cause it to do weird things with the database. This has been in since PHP 4.03 (released October 2000!), so any site that is still vulnerable to this sort of injection has been coded by a gibbon, or is over 10 years old. Oh - and if this was a problem, encrypted tables wouldn't help you either

You could of turn around to this guy and act all incredulous that he thinks your site is written by a complete moron, and you in fact find it insulting that he would consider you vulnerable to such a schoolboy error
Or you could just advise your boss that the guy is a moron and deserves no more of your time.

Now that's what I call a proper internet slapdown

Oh, and encrypted tables...
Ok, these are purely a disk-based security. If you are using MySQLAdmin, or accessing the data through a query in PHP, you will get unencrypted data (unless you have your own super-secret encryption in PHP-side).
MySQL will store the database data in huge great files on your disk somewhere, in a standard format. Anyone who can get full access to your server can in theory read/copy these files, and then just looking through the data (a simple hex editor is sufficient), and read out the credit card details, addresses etc. If they are encrypted, you can't!

The upshot of all this is that IF your server is vulnerable to someone getting in (which on a well-managed Linux server with strong passwords and minimal open ports, this would be nigh-on impossible), then you have to assume they can read all the data you store on it. With encrypted tables, it is harder. Tho I would personally just take a dump of the website code too, and find the bit in there that performs the initial database login, and add my own PHP page using the same header to access the database and dump the credit card details straight out in the unencrypted form anyway.

Basically, any hacker gaining root access to the server will get all the details, encrypted or not.
The only way to defend against that is to ensure the web side is not on the same server as the database, so the hacker has to crack two separate systems to get at the data instead of just the one.
Or, don't store sensitive data on anything that is publicly accessible.

There is an aside to this... If you take regular backups of the server (offsite DVD disk images I would hope), then the databases are on those DVD's, and anyone who gets the DVD can read the contents of unencrypted tables.

So - just think about the data. Names & addresses - they dont usually count as being that sensitive (they are on the electoral roll for starters). Even bank account & sort code is not that sensitive. CC details, and the 3 digit code do need ot be encrypted, but anything else... meh.

Most regulators would disagree with you, however.

Also, send the guy an email copying your boss that says something like "It appears you don't understand SQL Injection. Maybe this will help you".



"Note the reference to sanitising input, not encrypting data".

It's now been recommended that we urgently move the app away from our current VPS to a dedicated server.



Now I'm guessing the last bit is garbage?

Christ knows why we're being recommended 1TB minimum of bandwidth too.. our entire web traffic is less than 10gb a month.

He's utterly blatantly now just shilling for his mate's firm. And yes, the last line is nonsense.

HAHAHAHAHAHAHAHAHAHAHAHA!

I missed this thread - very entertaining!

Strong Firewall (stop plenty bad voodoo magic!)

The man's a grade 'A' bozo.

Get with the lingo man.

He's a Strong Bozo.

I'm glad that comes across from the little bit I've quoted. The rest of the email is full of similar stuff, basically painting us as idiots and this consultant as the saviour of the planet.

Got to say, it's pretty bloody advanced for a Nigerian 419 scammer!

If you turn him down he will put a Strong Curse on you and DEAD you.

So, in order
1) Assuming that the word 'strong' means 'fast', well, yes.
2) RAIDED isn't a thing. Just "RAID" is better, although I'd be staggered if you didn't have that already.
3) Durr
4) Now he's talking shit. Backups should be to media which is taken off-site or to a remote server. If you want a server that can support failure you want to stick it in with your current one and run both with a load balancer.
5) How fucking much? 1TB/Min is some hardcore fucking bandwidth. A 1GB network card running at full pelt can only shift 0.6TB per minute, and that's assuming you have fast enough hard drives (and a fast enough box) to give the data out, which you won't. 1TB/min is fucking fairy land.
6) As discussed above.

This bloke is a cunt, and if he actually has any clue about these things at all then he's trying to defraud your company.

Umm.. I think the '1TB min' means 'minimum'.

Well thank fuck.
But it's still far too much.

Put him on the phone to me on Monday.

Quick question: what is the reason for the application being hosted off-site?

We don't host anything internally besides our exchange server. If we use external hosting, we don't have to worry about security and updates and all that stuff.

UNTIL NOW!

He didn't mention anything about cooling fans and LEDs did he?

Hmm.. that's a point.. a dedicated server had better mean dedicated LEDs.

Um... Unless you have a fucking hardcore managed solution that's probably not true.

Which bit? All of it?

Wouldn't hosts look after updates to the OS though? And look after the general security of their server?

Only when you pay more for that.

Hmm.. well the server is using CentOS 4.8 which according to the CentOS site was announced in August 09. We certainly didn't do that, so I wonder if CPanel/WHM sorts all that out?

It's possible, but managed hosting on that level is going to be pretty spendy.

They probably set the server up to be secure (unless you set it up yourselves) and they'll be a firewall in place, probably configured to stop various types of attacks. But as for other security stuff like checking the logs to see if anyone has been trying to force their way in, or keeping things up to date - well, I'd be pretty surprised.

CentOS is now on version 5.5, for instance.

1) Strong?
If you are only doing around 10gb a month, then Ireally doubt processor will be a limiting factor in any way shape or form.

2) Raid.. meh. Tbh, not needed. if you are on a virtual private server (which is what I use too), it probably is, but even so - if it is a simple PHP/HTML web server system (no custom daemons doing stuff for you) then its relatively easy to set up again afterwards, especially if you make a good backup after initial installation.

3) Daily backups - you can add a simple cron batch job to do disk backups, and even one so that a weekly backup is encrypted & emails to someone responsible at your company - that's all you should need. In the worst case (i.e. the datacenter explodes), you lose up to a weeks worth of updates.

4) same as 33 really. Backups are not hard, they just require the discipline for someone once a week to get em, or for someone to spend an hour with the cron & MySQL manuals working out how to set em up to be automatic. An hour. & that is for a complete noob to set it up. Any pro should be able to do it in under 10 minutes.

5) BOLLOX!!!
This is big flashing 'Snake Oil Salesman' line. You don't need the bandwidth, and that sort of bandwidth is hideously expensive. There are so many companies that try to flog you this crud.

6) A decent firewall should be a standard for most hosts (tho does not replace hardening the server properly - i.e. turn off everything except the bare minimum you need to do the job)

We use a virtual server for our website, we get around 10k visitors per day, monthly bandwidth around 200Gb, and it costs £30 + VAT. For a small HR server with the bandwidth you have, you would not need anything costing over £15 - £20 a month. Any more than that, & its a ripoff.

What Grim... said. Who doesn't use RAID?!

I learnt by my mistakes. No ant nests for me anymore.

I have only ever had 1 HD go titsup on me in 15 odd years, maybe I'm just lucky (and a skinflint!)
Anyway, is it even possible to get a web server without RAID?*

*especially a virtual private one?

It'll all be shared storage. If it's NAS it'll be raided, if it's SAN, it won't matter. I don't imagine there are many hosting firms that offer machines with local storage.

Nah, smaller dedicated solutions will use local storage.

That surprises me. It's not like networked storage is expensive.

Then again, I have a slightly skewed view of IT expenditure and scale.

Bozo McBozo of STRONG MAGIC fame didn't actually specify what sort of RAID. Given the quality of his advice so far, probably RAID 0 for its sql injection attack prevention...

Sorry.. that's the kind of stuff I meant. I'll look after the various things that I use the server for, but I'd rather not be looking after the server itself.

As the MD has been sent the email containing all these guys' rubbish, I'll probably try and come up with a counter-email over the weekend or we'll end up with these clowns taking over everything.

I notice that our current VPS already has RAID, but it's RAID 1.. that any good?

RAID1 is perfect. It means all content is mirrored across two drives, so if one fails, you replace it and the server keeps going.

Sure, but they would likely have done that once, when you first got your server.

I could be completely and utterly wrong, as I'm only going by what you said, but it might be worth you making sure that someone is checking the security setup every now and then. As far as hardware support goes, you probably want to ask about that, too. Will they do a hard-reboot if it hangs up badly? Will they replace a blown power supply? Are they doing backups? Etc.