IN both cases, if it's sucking the life out of you, then you aren't using the right tools..... and perhaps not identifying what the real problems are.
Sure, someone can fuck up infrastructure..... and you can put things in place to enforce infrastructure and prevent fuckups.... that's your job, right?
That's overly drastic - but you could always find the tools that you need and/or the policies you need to enact in order to make your and everyone elses job easier, write a proper proposal, and give that to your boss..... that might get you some traction.
Part of the problem, especially with homegrown sysadmins, even the most talented ones on technical merits, is that they don't know how to operate within a company. They overreact..... they get hammer syndrome. They want everyone to switch OS's just because nobody has taken the time to find a decent AV vendor and an Active Directory book or two, and learn how to manage their windows network somewhat properly. Note: That doesn't mean I wouldn't LOVE to switch lots of networks to all-linux, but in the business world, good-enough is often the solution you can sell, not the ideal.
At one point I would have been in the same camp as you guys - then I gained enlightenment and learned that the job of being a sysadmin was more than just playing around with computers. It's also about managing corporate expectations, resources, budgets, and all kinds of stuff.... and if you do it right, it's still just as fun as it used to be.
If you've been doing sysadmin for 10 years and you are still fixing people's workstations then of course you hate it - you aren't moving up in the world - you're doing a job that someone fresh out of school should be doing.
Exactly the right thing to do - and not only does it cover your ass, it also demonstrates a level of professionalism to those letting you go that they may not have ever considered before.
And you know what? If I forgot to hand over a password, because I just couldn't think of it at the time - even if I'm pissed at the situation and the company, I'll give it up as long as I'm sure the person calling is allowed to have it - and if I'm not sure, I'll call up my old boss and give it to him. Even if he's the one who's being a dick. Even when my former co-admin calls me up a month later to ask if I remember the password to X because we all forgot about it - I'll try to help him out.
The very last thing you want on you reputation is that you can't be trusted.
Perhaps... but you know what? This shit happens in the sysadmin world. All those corporate policies about passwords and stuff? Relatively new in the grand scheme of things. A good sysadmin doesn't go batshit nuts and do anything to even make it LOOK like you are holding a resource hostage. A good sysadmin goes out of his way to ensure that he's not seen as a threat, even though he could be - remember, most people have absolutely no idea the unprecedented level of access their sysadmins really have.
Sysadmins can be quirky and weird - but the one thing you don't want your references saying is that you were ever dishonest, thieving, or held a resource hostage. If you're going to defy a higher up's request for something, you document very clearly what and why you are doing it, and you include that higher-up in those communications. That tends to earn you respect from all sides.
He acted wrongly in several ways, it seems to me, even if technically correct on paper.
That said - his *manager* should have had the skills to assess and diffuse the situation and set things back in order. They could have retained a possibly valuable asset rather than ended up in this expensive godawful mess. They let the guy get that deep into the "it's mine" hole..... that's a natural direction to head. you have to help him dig out, too.
You handle it gracefully and politely, while covering your ass. You point out that the current policy says you'll get fired for just giving out the passwords - so you ask your boss for some guidance on how to resolve the situation properly - their need for access and your concern about policy (or whatever). You work together... not against each other with policy as a hammer.
"When either a direct-line supervisor or someone as high up the food chain as you are supposing here asks for something you pretty much give it to them. Or get fired on the spot with good cause"
I've been at jobs where I have several master passwords which I am not allowed to give to *anyone* - the only other person who has them is the owner of the company. There is a manager or two in between us in the organization, but those particular passwords and policies were very clear.
Line-managers of various sorts in between me and said owner did ask for access to things on occasion, as well as directors and whatnot from completely other departments - and in such situations, rather than be combative, I would explain the situation delicately and respectfully, and then we would handle the situation however we saw fit - whether that meant we both went to see the decision maker, whether that mean they would raise it on their own, or whether they wanted me to raise it for them....
I'm a sysadmin. I am a facilitator, and a protector of someone else's assets - not a power-hungry dictator.
Even if the owner of the company walks in and asks for access to "everything", to which of course he is entirely entitled, I will try to find out what's up and what he really needs. I might explain why, while of course it's his stuff and I will give it to him on his insistence without question, there are some risks he's exposing his organization to by doing this. This has, so far, universally led to a "Huh, those are great points, I hadn't thought of that, nevermind.... all I really need is X.
Not commenting on the case - but I can attest to having been in situations where I had passwords that neither my boss nor his boss were permitted access to - the only other person with access was the owner.... and that policy came from the owner.
It's not common, it's not normal - but it happens, and has to do with domain expertise and risk mitigation.
I would say that the situation you've just written, taken at face value, would very likely be some form of extortion and illegal in any number of ways, though probably not related to intellectual property.
Then the company should have had a policy that those passwords be recorded somewhere. If the people in IT failed to enact such a policy, they failed to do their job properly.
I'm a sysadmin - trust and reputation are everything, and I would never *screw* an ex-employer, for any reason, but seriously - if I came in one day and found out I was fired and treated like shit (this has nothing to do with the case at hand - just an thought exercise) - I'd probably think twice before handing everything over.... then I'd hand it over.
In reality, though, if I was fired, I'd suggest to management, even providing a list, of all my accounts and insist that all my passwords were revoked and/or changed, with written confirmation from the company, as soon as possible, just so that I could not be later blamed for someone else's screwup from that point onwards.
I would NOT use any *access* passwords that only existed in my head (which I avoid anyway) as leverage for anything else. That's morally wrong.
$200 is quite affordable - so for $200 I can drop in one of these, use it as my system drive, and get a massive speed improvement, subjectively, for my $2500 computer.
1) Users cannot have administrative privileges. 2) You need up to date antivirus and host IDS (I hate SEP, but it works). 3) Critical user data needs to be backed up somewhere safe. 4) User segments should have outgoing traffic restricted, and all traffic should go through proxies unless exceptions must be made. Those proxies must do something to help as well - blacklists, antivirus, depends on your budget. 5) Edge firewall should not allow direct connections from user workstations to the outside unless very specific and required for the task at hand. 6) You need to be able to cleanly and quickly re-deploy infected workstations in a clean environment, with minimal delay - because at some point, you will get hit hard, and this will help ease the pain. This is where imaging and backups come in. 7) Understand that regardless of what you do - things will happen - so see #6 again:)
I've thought about that angle... and there is one thing that sticks out as a potential legal puddle.
When I write some code from scratch, I can license it however I want, to whoever I want, in as many ways as I want. It's *MINE*. If I make it an "OSS PROJECT" but require the submitters to assign copyright to me if they want me to keep things in my main project.... I retain that privilege. I can't take away what I've already licensed.. but I still *OWN* the code, and can re-license it.
Now - with BSD licensed stuff - I can still basically own it... modify it however I want, take back any changes anyone publicly gives, and even though I must retain copyright for them, and can still own MY tree, including contributions others CHOOSE to make
With GPL... If I release it under GPL, and someone else releases a patch somewhere, but doesn't assign copyright to me,I no longer own the code.. and should I also be implmenting the same feature, and be dual-licensing it, a nasty battle could ensue.
"Also, the BSD developer may feel that even though the license doesn't require that you release changes, the spirit of the BSD community says you morally should if you're a free software project (and BSD is considered free software by the FSF)."
I've never heard this before - in fact the BSD license crowd are quite fond of the fact that they are choosing to release their code pretty much restriction free, and don't care what people do with it, and there may be the implication that they would also respect others who do the same.. but they don't expect anything back.
And the moment you distribute it you have to give the code to anybody you distributed to who asks
No you don't. You just have to give it to the people that you give binaries to.
Those two statements are the same... and you can eliminate the need for waiting for people to "ask" by simply offering equivalent access at the same time. eg: A src tarball available over HTTP in the same location as hte binaries. Even if the use chooses not to download, it was available. You only have to give hte "written offer" and then maintain those copies under certain circumstances.
But again - the GPL has nothing to do with forcing people to contribute back to projects - it only requires that if you want to redistribute code, modified or not, you must also distribute the source to those changes in a reasonably useful format. You owe no allegiance whatsoever to the "project" that started it.
So if we're talking online poker here....... my argument to your argument would be, who cares? Cheaters aren't stealing from the house, they are stealing from other players at the table.
The poker room operator, online or off, doesn't care about collusion itself, he cares about the perception by his potential and current customers that his system provides a fair game. As long as nobody is taking their business elsewhere because of the perception that the table is full of cheaters, it has no impact on their bottom line.
I avoid all the parts where anyone evangelizes any part of it being "open source" or has any sense of entitlement.
I'll work on my project, or contribute to someone else's if I feel the itch, and that's about it. If I make my project open source, that's that.
I dislike OSS nazis who have this hippie "give back" attitude. I've released software. Some of it is open-source. I couldn't give a rat's ass if anyone "gives back" - I only expect that if you use the software *I* wrote, you abide by the terms I released it under.... whatever those terms are.
I don't do a project for the sake of being open-source - I do it because it's interesting, and if I make it open-source, it's because I want to share. I don't appreciate anyone reading any more than that into it.
The deep knowledge is still there - the well is just a LOT deeper, and more complex.
In the days of the C64 - it was reasonable for a skilled and/or curious programmer to get to the bottom of things and learn how everything worked, exactly. It was also potentially USEFUL for him to do this.... it was the only direction you could go, short of inventing a new language.
So - today we still find deep knowledge out there - but it just not be as useful for even a very good programmer to go ALL the way down.
Yes, a Java programmer should know more than just the surface - and more than just the patterns. He could also go deeper and understand the JVM implementation, and to a degree how it uses actual machine resources - but to suggest he needs to all the way down the rabbit hole is taking it a bit far.
My point, I guess, is that there is no need to pine for the old days - nobody says you can't learn more and go deep, and those who do, tend to prosper.
The 1541 drives were purposefully slowed down to maintain compatibility with some other Commodore hardware (I forget at the moment exactly which)..... so they weren't so much fast-loaders as they were "doing it the way the engineers designed it to work, not the way the boss made them change it so he could claim compatibility.
First - need to know what your motivation is here - is it just to type faster, to type the way a textbook says you should, or because you are concerned about your hands cramping up and/or future medical conditions?
80-110wpm, if that's accurate, is respectably way above average and up in the range of us "fast typists"... you probably type faster than just about everyone you meet.
If you are concerned about technique from textbooks and matching that - don't do anything other than give it a try - I'm a classical touch-typist, but I certainly don't follow all the rules, and I've adapted to what works for me. The teacher back in high school might have called it wrong, but finishing the 1 hour final exam in 8 minutes and leaving spoke for itself.
If it's speed and/or medical - go for layout, position, - I can use my Model-M clone, to the annoyance of half my co-workers (the other half also have them). and find I can type longer without getting tired - but it's noisy. I'd like to give Dvorak a crack one month when I have the free time.
I also find I can type quite well on those new little apple chicklet keyboards - much to my surprise, I thought I would hate them.
ETAOIN SHRDLU - you'll find them printed in weird spots in old books too, as filler. They represent the lefhand two column of a linotype - for setting letters in hot lead for print... and that was because they were the most commonly used letters in the english alphabet. (Typing in hot molten lead... now that's typing!)
I've never heard that they were directly used in the design of the qwerty keyboard though.. can you cite a source? The ones I come up with never make a direct connection.
As for qwerty - it was actually designed to be as fast as possible for the typist while preventing jamming... so, yes, slowed down, but as fast as it could possibly be given the equipment at the time.
First..... 1 million password *failures* is not a security problem by itself. They're supposed to fail if they don't have the right password.
So - moving this to a more obscure port will definitely cut down on the automated scanning.. but it's not really the heart of the issue.
The heart of the issue is that it took you so long to realize someone was even doing this. That probably boils down to your running a business requiring sysadmin work without a sysadmin.
There are lots and lots of ways to approach this, some of which people have touched on already.
1) You need awareness of what's going on - daily log analysis. OSSEC is neat, give it a shot. 2) Moving SSH to a weird port is something some people do - I don't prefer that - it buys some obscurity and cuts down on some scanning, but doesn't address any real security issues. 3) OSSEC in active mode with a whitelist so you don't block out legitimate users - works pretty well. 4) Hire someone to deal with security/deployment/backups/recovery/service providers (sysadmin?)
Slashdot Mirror
If you don't want your company to be exposed to such influences, stay out of the public stock exchanges - nothing forces you to go there.....
IN both cases, if it's sucking the life out of you, then you aren't using the right tools..... and perhaps not identifying what the real problems are.
Sure, someone can fuck up infrastructure..... and you can put things in place to enforce infrastructure and prevent fuckups.... that's your job, right?
That's overly drastic - but you could always find the tools that you need and/or the policies you need to enact in order to make your and everyone elses job easier, write a proper proposal, and give that to your boss..... that might get you some traction.
Part of the problem, especially with homegrown sysadmins, even the most talented ones on technical merits, is that they don't know how to operate within a company. They overreact..... they get hammer syndrome. They want everyone to switch OS's just because nobody has taken the time to find a decent AV vendor and an Active Directory book or two, and learn how to manage their windows network somewhat properly. Note: That doesn't mean I wouldn't LOVE to switch lots of networks to all-linux, but in the business world, good-enough is often the solution you can sell, not the ideal.
At one point I would have been in the same camp as you guys - then I gained enlightenment and learned that the job of being a sysadmin was more than just playing around with computers. It's also about managing corporate expectations, resources, budgets, and all kinds of stuff.... and if you do it right, it's still just as fun as it used to be.
If you've been doing sysadmin for 10 years and you are still fixing people's workstations then of course you hate it - you aren't moving up in the world - you're doing a job that someone fresh out of school should be doing.
Exactly the right thing to do - and not only does it cover your ass, it also demonstrates a level of professionalism to those letting you go that they may not have ever considered before.
And you know what? If I forgot to hand over a password, because I just couldn't think of it at the time - even if I'm pissed at the situation and the company, I'll give it up as long as I'm sure the person calling is allowed to have it - and if I'm not sure, I'll call up my old boss and give it to him. Even if he's the one who's being a dick.
Even when my former co-admin calls me up a month later to ask if I remember the password to X because we all forgot about it - I'll try to help him out.
The very last thing you want on you reputation is that you can't be trusted.
Perhaps... but you know what? This shit happens in the sysadmin world. All those corporate policies about passwords and stuff? Relatively new in the grand scheme of things. A good sysadmin doesn't go batshit nuts and do anything to even make it LOOK like you are holding a resource hostage. A good sysadmin goes out of his way to ensure that he's not seen as a threat, even though he could be - remember, most people have absolutely no idea the unprecedented level of access their sysadmins really have.
Sysadmins can be quirky and weird - but the one thing you don't want your references saying is that you were ever dishonest, thieving, or held a resource hostage. If you're going to defy a higher up's request for something, you document very clearly what and why you are doing it, and you include that higher-up in those communications. That tends to earn you respect from all sides.
He acted wrongly in several ways, it seems to me, even if technically correct on paper.
That said - his *manager* should have had the skills to assess and diffuse the situation and set things back in order. They could have retained a possibly valuable asset rather than ended up in this expensive godawful mess. They let the guy get that deep into the "it's mine" hole..... that's a natural direction to head. you have to help him dig out, too.
You handle it gracefully and politely, while covering your ass. You point out that the current policy says you'll get fired for just giving out the passwords - so you ask your boss for some guidance on how to resolve the situation properly - their need for access and your concern about policy (or whatever). You work together... not against each other with policy as a hammer.
"When either a direct-line supervisor or someone as high up the food chain as you are supposing here asks for something you pretty much give it to them. Or get fired on the spot with good cause"
I've been at jobs where I have several master passwords which I am not allowed to give to *anyone* - the only other person who has them is the owner of the company. There is a manager or two in between us in the organization, but those particular passwords and policies were very clear.
Line-managers of various sorts in between me and said owner did ask for access to things on occasion, as well as directors and whatnot from completely other departments - and in such situations, rather than be combative, I would explain the situation delicately and respectfully, and then we would handle the situation however we saw fit - whether that meant we both went to see the decision maker, whether that mean they would raise it on their own, or whether they wanted me to raise it for them....
I'm a sysadmin. I am a facilitator, and a protector of someone else's assets - not a power-hungry dictator.
Even if the owner of the company walks in and asks for access to "everything", to which of course he is entirely entitled, I will try to find out what's up and what he really needs. I might explain why, while of course it's his stuff and I will give it to him on his insistence without question, there are some risks he's exposing his organization to by doing this. This has, so far, universally led to a "Huh, those are great points, I hadn't thought of that, nevermind.... all I really need is X.
Not commenting on the case - but I can attest to having been in situations where I had passwords that neither my boss nor his boss were permitted access to - the only other person with access was the owner.... and that policy came from the owner.
It's not common, it's not normal - but it happens, and has to do with domain expertise and risk mitigation.
I would say that the situation you've just written, taken at face value, would very likely be some form of extortion and illegal in any number of ways, though probably not related to intellectual property.
Then the company should have had a policy that those passwords be recorded somewhere. If the people in IT failed to enact such a policy, they failed to do their job properly.
I'm a sysadmin - trust and reputation are everything, and I would never *screw* an ex-employer, for any reason, but seriously - if I came in one day and found out I was fired and treated like shit (this has nothing to do with the case at hand - just an thought exercise) - I'd probably think twice before handing everything over.... then I'd hand it over.
In reality, though, if I was fired, I'd suggest to management, even providing a list, of all my accounts and insist that all my passwords were revoked and/or changed, with written confirmation from the company, as soon as possible, just so that I could not be later blamed for someone else's screwup from that point onwards.
I would NOT use any *access* passwords that only existed in my head (which I avoid anyway) as leverage for anything else. That's morally wrong.
The SSD will still win on seek time.
$200 is quite affordable - so for $200 I can drop in one of these, use it as my system drive, and get a massive speed improvement, subjectively, for my $2500 computer.
Sounds like a great deal to me.
High-school algebra - no harder than any other technology decision regarding performance upgrades.
There is no perfect answer.... but...
1) Users cannot have administrative privileges. :)
2) You need up to date antivirus and host IDS (I hate SEP, but it works).
3) Critical user data needs to be backed up somewhere safe.
4) User segments should have outgoing traffic restricted, and all traffic should go through proxies unless exceptions must be made. Those proxies must do something to help as well - blacklists, antivirus, depends on your budget.
5) Edge firewall should not allow direct connections from user workstations to the outside unless very specific and required for the task at hand.
6) You need to be able to cleanly and quickly re-deploy infected workstations in a clean environment, with minimal delay - because at some point, you will get hit hard, and this will help ease the pain. This is where imaging and backups come in.
7) Understand that regardless of what you do - things will happen - so see #6 again
I've thought about that angle... and there is one thing that sticks out as a potential legal puddle.
When I write some code from scratch, I can license it however I want, to whoever I want, in as many ways as I want. It's *MINE*. If I make it an "OSS PROJECT" but require the submitters to assign copyright to me if they want me to keep things in my main project.... I retain that privilege. I can't take away what I've already licensed.. but I still *OWN* the code, and can re-license it.
Now - with BSD licensed stuff - I can still basically own it... modify it however I want, take back any changes anyone publicly gives, and even though I must retain copyright for them, and can still own MY tree, including contributions others CHOOSE to make
With GPL... If I release it under GPL, and someone else releases a patch somewhere, but doesn't assign copyright to me,I no longer own the code.. and should I also be implmenting the same feature, and be dual-licensing it, a nasty battle could ensue.
"Also, the BSD developer may feel that even though the license doesn't require that you release changes, the spirit of the BSD community says you morally should if you're a free software project (and BSD is considered free software by the FSF)."
I've never heard this before - in fact the BSD license crowd are quite fond of the fact that they are choosing to release their code pretty much restriction free, and don't care what people do with it, and there may be the implication that they would also respect others who do the same.. but they don't expect anything back.
And the moment you distribute it you have to give the code to anybody you distributed to who asks
No you don't. You just have to give it to the people that you give binaries to.
Those two statements are the same... and you can eliminate the need for waiting for people to "ask" by simply offering equivalent access at the same time. eg: A src tarball available over HTTP in the same location as hte binaries. Even if the use chooses not to download, it was available. You only have to give hte "written offer" and then maintain those copies under certain circumstances.
But again - the GPL has nothing to do with forcing people to contribute back to projects - it only requires that if you want to redistribute code, modified or not, you must also distribute the source to those changes in a reasonably useful format. You owe no allegiance whatsoever to the "project" that started it.
So if we're talking online poker here....... my argument to your argument would be, who cares? Cheaters aren't stealing from the house, they are stealing from other players at the table.
The poker room operator, online or off, doesn't care about collusion itself, he cares about the perception by his potential and current customers that his system provides a fair game. As long as nobody is taking their business elsewhere because of the perception that the table is full of cheaters, it has no impact on their bottom line.
I avoid all the parts where anyone evangelizes any part of it being "open source" or has any sense of entitlement.
I'll work on my project, or contribute to someone else's if I feel the itch, and that's about it. If I make my project open source, that's that.
I dislike OSS nazis who have this hippie "give back" attitude. I've released software. Some of it is open-source. I couldn't give a rat's ass if anyone "gives back" - I only expect that if you use the software *I* wrote, you abide by the terms I released it under.... whatever those terms are.
I don't do a project for the sake of being open-source - I do it because it's interesting, and if I make it open-source, it's because I want to share. I don't appreciate anyone reading any more than that into it.
The deep knowledge is still there - the well is just a LOT deeper, and more complex.
In the days of the C64 - it was reasonable for a skilled and/or curious programmer to get to the bottom of things and learn how everything worked, exactly. It was also potentially USEFUL for him to do this.... it was the only direction you could go, short of inventing a new language.
So - today we still find deep knowledge out there - but it just not be as useful for even a very good programmer to go ALL the way down.
Yes, a Java programmer should know more than just the surface - and more than just the patterns. He could also go deeper and understand the JVM implementation, and to a degree how it uses actual machine resources - but to suggest he needs to all the way down the rabbit hole is taking it a bit far.
My point, I guess, is that there is no need to pine for the old days - nobody says you can't learn more and go deep, and those who do, tend to prosper.
The 1541 drives were purposefully slowed down to maintain compatibility with some other Commodore hardware (I forget at the moment exactly which)..... so they weren't so much fast-loaders as they were "doing it the way the engineers designed it to work, not the way the boss made them change it so he could claim compatibility.
First - need to know what your motivation is here - is it just to type faster, to type the way a textbook says you should, or because you are concerned about your hands cramping up and/or future medical conditions?
80-110wpm, if that's accurate, is respectably way above average and up in the range of us "fast typists"... you probably type faster than just about everyone you meet.
If you are concerned about technique from textbooks and matching that - don't do anything other than give it a try - I'm a classical touch-typist, but I certainly don't follow all the rules, and I've adapted to what works for me. The teacher back in high school might have called it wrong, but finishing the 1 hour final exam in 8 minutes and leaving spoke for itself.
If it's speed and/or medical - go for layout, position, - I can use my Model-M clone, to the annoyance of half my co-workers (the other half also have them). and find I can type longer without getting tired - but it's noisy. I'd like to give Dvorak a crack one month when I have the free time.
I also find I can type quite well on those new little apple chicklet keyboards - much to my surprise, I thought I would hate them.
ETAOIN SHRDLU - you'll find them printed in weird spots in old books too, as filler. They represent the lefhand two column of a linotype - for setting letters in hot lead for print... and that was because they were the most commonly used letters in the english alphabet. (Typing in hot molten lead... now that's typing!)
I've never heard that they were directly used in the design of the qwerty keyboard though.. can you cite a source? The ones I come up with never make a direct connection.
As for qwerty - it was actually designed to be as fast as possible for the typist while preventing jamming... so, yes, slowed down, but as fast as it could possibly be given the equipment at the time.
First..... 1 million password *failures* is not a security problem by itself. They're supposed to fail if they don't have the right password.
So - moving this to a more obscure port will definitely cut down on the automated scanning.. but it's not really the heart of the issue.
The heart of the issue is that it took you so long to realize someone was even doing this. That probably boils down to your running a business requiring sysadmin work without a sysadmin.
There are lots and lots of ways to approach this, some of which people have touched on already.
1) You need awareness of what's going on - daily log analysis. OSSEC is neat, give it a shot.
2) Moving SSH to a weird port is something some people do - I don't prefer that - it buys some obscurity and cuts down on some scanning, but doesn't address any real security issues.
3) OSSEC in active mode with a whitelist so you don't block out legitimate users - works pretty well.
4) Hire someone to deal with security/deployment/backups/recovery/service providers (sysadmin?)