I have really mixed feelings about your thoughts because "It's too hard" is a very slippery slope, one that leads to complacency far too easily. In turn, complacency leads to compromise (in both senses of the word).
Given the rise of distributed DOS attacks, the practice of using compromised systems as gateways to further mayhem, and other common tactics, I really don't think it's unreasonable to make things a little harder than they need to be in order to add basic and reasonable precuations.
(I'm reasonably certain that you're aware of this, but I'm trying to point out that many hacks are executed through very common and easily fixed vunerabilities.)
Yes, of course there's a balance, but I would argue that you need to draw the line a little farther from the knife edge.
Users will complain about being forced to change their passwords and to mix case, add numbers, and so on. But they eventually learn and adapt.
They will not do it on their own; you (the admin) must educate them. Given the number of excellent sources and the publicity surrounding certain hacks, this doesn't need to be overly time consuming.
Your boss wants you to code? Fine, get him to let you code decent starting places for your users. If they're using FormMail, give them a more secure version. Give them packages of convenient, easy-to-use routines designed to be safer.
Let them use their FTP clients...on realms isolated from data. Don't let them play in a sandbox on the same machine as the one running your database.
I think part of tilly's warning is that there are far too many basic, easy, and well-known things you can do to prevent most problems. Be sure you use them.
Do you really want modern versions of Al Capone running through your systems?
Also, try to get your boss to allow you two hours a day for research to be spent on non-billable projects. Explain to him the benefit of having a more educated admin/programmer. Show him that this is an investment that will pay off over time.
Yes, there's a balance between total security and reasonable access. Take the time to make sure you've drawn that line as carefully as possible. If you don't know where it is, you will learn...one way or the other.
(Not trying to flame you or anything. Just trying to make it perfectly clear that it's far too easy to be complacent. Ignorance must be resisted as strongly as possible.)
"It's too hard" is not a valid excuse in my book. "Acceptable Losses" may be a better term.
Update: In response:
I think we're arguing the same thing viewpoint from different angles. I do agree that 100% security is difficult, expensive, and restrictive. I was really trying to say be very, very careful with your compromises.
"security is easy, you only have to do simple things to secure your machine"
I agree and if that's how I came across, that is not what I meant. I meant, don't let your compromises prevent you from doing the easy stuff.
the recipes are known but they are impractical in real use.
I would rather say "they can be impractical." I have seen far too many cases where people have taken this idea to the extreme of "Never mind. We'll take that chance." Those extremes are what prompted my reply.
Yes, of course, take the basic precautions and figure out the balance you're talking about. Again, I'm not disagreeing with you...I'm arguing against the extreme conclusions that I've seen others make, conclusions generally starting with thoughts very similar to yours. You appear to be drawing a good balance.
Tell me how do you easily fix production servers which must be runinng 24/24h 7/7j
(with of course some applications incompatible with the new secure version of other applications)?
This is true. There's not an easy answer. Or, perhaps more accurately, I don't know how secure sites do this. I know it's done and hope that a monk more versed in Adminsitration matters can offer some hints or a link.
OK, but they want the same password for telnet and ftp, anyone with a sniffer on my subnet now has a local access on my box.
Which is why I suggested using a different realm or box. I would not knowingly advocate dangerous practices. I'm sorry I wasn't more clear on that point.
I will now have another box to secure...
Then that's a risk you find acceptable, one I assume you'll fix when or if you have the opportunity. As I understand it though, my recommendation is considered safest.
Again, I am not criticizing your choices, just trying to call attention to a couple of ideas that I've come across. It's free advice. Ignore it if you wish.
(It IS a huge error if you think in long term effect, but my boss tend to be short sighted...)
I don't envy your position. You're clearly dealing with several conflicting desires/choices/factors. The presence of a PHB doesn't help.
As I mentioned earlier, you're doing the best you can and that's all anyone can ask.
However, that doesn't mean you should give up. Try to socially engineer him. If you're not allowed to experiment, then how can you predict that new changes won't adversely affect production data?
I'm sure that far wiser and more experience monks can offer other ideas and suggestions.
I hope you won't take it as irony or personal attack, but this is MY REALITY, and probably the one a of a lot of sysadmin...
No, I don't take it as a personal attack, in part because my reality is, in many ways, similar. I freely admit that I'm a programmer, not an admin. but, I have compromises to live with in my work as well.
However, that doesn't stop me from trying to improve that reality through education, discussion, experimentation, and so on. It doesn't prevent me from trying to help my boss get over some of her pointiness. It doesn't stop me from trying to help others make their professional lives better.
I know I am not perfect. I continue to try to make a difference. I will not accept my reality as set in stone. I believe I can affect and improve it.
I'm sure you are doing the same and are as frequently frustrated as I am.
Be security aware, especially because you CAN'T reach true security, and try to make things as secure AND easy AS YOU CAN.
I agree. I also think it's important to try to do better, even after making certain choices. Put another way, a compromise is fine, as long as it's knowingly made. However, it should not remain set in stone. "We can't do that" should be "We can't do that now." This leads to "What needs to happen so we can," which in turn often leads to a solution and a plan for implementing it.
Again, this is friendly discussion that's not intended to inflame. I'm trying to solve problems, not criticize anyone's decisions, work, or choices. Most of us care enough about our work to keep poking at it after it's "done." That's the attitude that I'm trying to encourage. Do the best you can at the moment, accept your limitations, and try to improve when and where you can--even if that's the next project.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||