If you know anything about LulzSec it's that its members are (or were until recently) 4chan users, probably of the /b/ variety. Everything from their namesake to their cause to their speech and online habits pretty much says /b/tard.
I know /b/tards. Some of them are nice people (though most are dead inside). I basically get why they are on there, looking at posts of dead people and stupid unfunny cartoons and fag jokes and the inevitable hentai bestiality incest child rape porn. It's because they're bored. They're bored and so they go on the internet to find something to entertain them. And they find lots of other really bored people who like to look at shocking things and basically be idiots. That's the whole reason for 4chan. People are just horrible, and that's why that's there.
Not that i'm complaining. I grew up on the internet. I've looked at and read every horrible despicable thing the human imagination can think up. So i'm not harboring any grudge or ill will against these people. But I think i've gotten to the point where i'm sick of looking at boring, mindless, stupid shit. Unfortunately I can't completely ignore it because of LulzSec and Anonymous.
Why is the media giving so much attention to whatever crap LulzSec decides to announce? Today on Google News one of the top stories was the same story I had read on Hacker News: LulzSec decides to go on some "new mission" wherein they will attempt to deface government websites. Do you realize how completely boring that is? Do you know how much of a fucking loser you have to be to dedicate your valuable time to erasing a web page? The fact that just this announcement was news worthy makes one thing clear: people are fascinated and afraid of LulzSec.
The attacks carried out in their name have been many and they have infiltrated some very large and incredibly, stupidly insecure sites. The subsequent release of information from these sites has been absurdly large. On top of that, they command a sizeable botnet with which they DDoS whoever the fuck they feel like at the moment.
Are these attacks 'sophisticated'? No. There are many freely available tools which can be used to automate looking for and exploiting holes in public web applications and network services. Botnets are also not very hard to 'get'; most botnet owners don't properly secure their botnets and many can simply be social engineered to hand over control of the botnet. Most security researchers i've talked to don't find much difficulty in acquiring tens of thousands of nodes.
However, these tools are effective. Clearly there are many large sites with old holes waiting to be taken advantage of, and a DDoS is a very effective means of taking a host offline if you don't have the skill to penetrate it. Thus they can and do cause quite a bit of mischief. But why are we getting a news bulletin every time they do some damage?
Ultimately we are playing into their media-whoring hands. A couple of kids who are really bored are finding lots of attention (both positive and negative) in creating havoc on the internet. With each site taken down and subsequent press release they get more infamous and thus the next attack or announcement gets even more press. Online businesses cower in fear waiting for the next attack, and when it affects users directly (like the many gamers affected by their DDoSing) they are sucked into a whirlpool of hate directed at LulzSec - who, being 4chan trolls, revel in the fact that they could make such a large user base 'mad'.
Where do we go from here? Do we attempt to ignore the internet bullies in the hopes that they'll go away? Do we attack back and start a ridiculous arms race of morons flinging poo at each other? Should the media stop giving them a loudspeaker, or should it try instead to exercise some investigative journalism instead of parroting their exploits?
The truth is that people are simple. LulzSec will keep this up for a little longer, looking for big targets to attack to remain media darlings. We'll keep eating it up because people like celebrity gossip. But for the most part, everything will be the same as it always has been.
The difference is that now there's an 800lb gorilla in the room exposing the horribly lax security practices some of us know to be standard fair in the corporate IT world. Perhaps we'll get some tough new laws and a prison sentence to try to discourage this type of behavior in the future. If there's a positive effect of this whole episode it's that we can use LulzSec as bogey men to scare developers and sysadmins into doing their due diligence to keep their systems secure.
But then, when the lights go down and the circus is over, everything will go back to the way it was, and we'll sleep soundly until another bunch of bored teens decide to DDoS or exploit another service. Hopefully we can prevent this kind of thing from happening again by just not playing into the trolls' hands.
Monday, June 20, 2011
Wednesday, June 1, 2011
devops/deveng is still a bad idea
I'm sure in 10 years people will eventually get just why it's a crappy idea to reinvent the wheel in Operations departments. Maybe somebody will finally standardize on a set of software configurations to deploy to manage an enterprise network. Could just be wishful thinking, but you never know.
Right now I work at a large non-profit as a small cog that's part of some big wheels. There's lots of people on my team that all basically do one or two specific jobs. In terms of how we go about accomplishing tasks it's incredibly inefficient. But that's the nature of big non-profits, I assume.
One example of how this "devops" idea fails came up recently. Somebody wanted a tool that rotates logs passed via standard-in. This is an old problem: you've got to keep processing logs but you can't afford the downtime of moving the log and restarting the service. So you open a pipe to a program which handles the juggling of logs for you. The easy choice is cronolog, a very old, stable open source tool.
When I asked if we could install it on all our RHEL boxes, I was told there was too much red tape involved with just getting a 'yum install' done, so I should just compile and install the software locally. (Yeah, i'm serious.) So after doing this I modify the script we need to use cronolog, test it, and it works great as expected.
Once i'm ready to push this out everywhere i'm told to hold off, that we need a better solution. Better than 'its done and working'? It turns out, if you use 3rd party software like this in our environment, three things happen:
1. Since we don't pay for the software there's no support contract. If there's no support, apparently it's too much trouble to find somebody who knows C in a building full of developers to support the software.
2. As a side-effect of #1, the security team can't get updates from a vendor and thus might not allow us to use the software as it might have unknown security holes.
3. We have to change our build standard to include the new software.
Now keep in mind, cronolog is shipped with RHEL. It just isn't installed on the machines. So getting it installed brings all sorts of red tape questions. What's their solution? Write something from scratch in-house. This of course is a lovely paradox, because:
1. We have to support the in-house solution now.
2. Nobody is going to audit the in-house solution for security holes.
Of course we don't have to change our build standard and it isn't a security conflict for one simple reason: Everyone ignores in-house software. That's right: the loophole to the regulation is to simply completely ignore auditing for internal tools. And there's an interesting point about devops/engops.
If you had actually paid for a product instead of developing it in-house or getting an open source solution, you would have assurance of both the attention to and patching for security holes, and you would just use it - there's no custom scripting or in-house wrapping required. Not only does it speed up your work to pay for it but it makes it more secure (in a fashion) and prevents you from having to spend development cycles.
The next time you decide to hire a 'devop' or 'deveng', consider how much money and time you'd save if you just spent a couple hundred or grand on completed, supported tools. (And as an aside, try not to allow gaping loopholes in logic like the ones pointed out above)
Edit: my mistake, cronolog is not shipped with RHEL (why I do not know). I ended up writing my own as it's much simpler than I originally thought. However, getting them to support 'logrotate' on solaris is looking like a bigger challenge...
Right now I work at a large non-profit as a small cog that's part of some big wheels. There's lots of people on my team that all basically do one or two specific jobs. In terms of how we go about accomplishing tasks it's incredibly inefficient. But that's the nature of big non-profits, I assume.
One example of how this "devops" idea fails came up recently. Somebody wanted a tool that rotates logs passed via standard-in. This is an old problem: you've got to keep processing logs but you can't afford the downtime of moving the log and restarting the service. So you open a pipe to a program which handles the juggling of logs for you. The easy choice is cronolog, a very old, stable open source tool.
When I asked if we could install it on all our RHEL boxes, I was told there was too much red tape involved with just getting a 'yum install' done, so I should just compile and install the software locally. (Yeah, i'm serious.) So after doing this I modify the script we need to use cronolog, test it, and it works great as expected.
Once i'm ready to push this out everywhere i'm told to hold off, that we need a better solution. Better than 'its done and working'? It turns out, if you use 3rd party software like this in our environment, three things happen:
1. Since we don't pay for the software there's no support contract. If there's no support, apparently it's too much trouble to find somebody who knows C in a building full of developers to support the software.
2. As a side-effect of #1, the security team can't get updates from a vendor and thus might not allow us to use the software as it might have unknown security holes.
3. We have to change our build standard to include the new software.
Now keep in mind, cronolog is shipped with RHEL. It just isn't installed on the machines. So getting it installed brings all sorts of red tape questions. What's their solution? Write something from scratch in-house. This of course is a lovely paradox, because:
1. We have to support the in-house solution now.
2. Nobody is going to audit the in-house solution for security holes.
Of course we don't have to change our build standard and it isn't a security conflict for one simple reason: Everyone ignores in-house software. That's right: the loophole to the regulation is to simply completely ignore auditing for internal tools. And there's an interesting point about devops/engops.
If you had actually paid for a product instead of developing it in-house or getting an open source solution, you would have assurance of both the attention to and patching for security holes, and you would just use it - there's no custom scripting or in-house wrapping required. Not only does it speed up your work to pay for it but it makes it more secure (in a fashion) and prevents you from having to spend development cycles.
The next time you decide to hire a 'devop' or 'deveng', consider how much money and time you'd save if you just spent a couple hundred or grand on completed, supported tools. (And as an aside, try not to allow gaping loopholes in logic like the ones pointed out above)
Edit: my mistake, cronolog is not shipped with RHEL (why I do not know). I ended up writing my own as it's much simpler than I originally thought. However, getting them to support 'logrotate' on solaris is looking like a bigger challenge...
Subscribe to:
Posts (Atom)