It would be very helpful to be able to use Group Policy and SUS for maintaining those apps!
Once on a Linux desktop, you will not have tools such as SUS and Group Policy - as other Linux-based options, such as apt-get and Mozilla's lockPref() will replace them. Consider that you need to learn how to use your new administration tools, just as much as your users will need to learn how to use their new tools.
Like Netscape and Mozilla, nearly everything in firefox can be locked down (Google for "firefox lockpref").
Quick overview:
1) Open prefs.js
2) Where you want to lockdown something, replace user_pref() with lockPref(). Once done delete any lines which still have user_pref()
3) Byteshift (offset=13) the changed prefs.js file. This can be done via an online script. Or download a perl script to run locally. The resulting file should be called firefox.cfg
4) Put firefox.cfg in the root of the FireFox install folder, and a 1.js in prefs/default with the line:
pref("general.config.filename", "firefox.cfg");
We lock settings such as the proxy, homepage, cache, history, download locations, and weak security settings (saving passwords, SSLv2, etc...).
I believe it's also possible to point to a webserver which can feed the lockPref values dynamically (ie: based on authenticated username).
BTW: firefox.cfg can be called anything you want, just make the appropriate changes to the instructions above.
False. Be careful where you make such broad "...everything..." statements. Some spyware either is, or borders on, the definition of a rootkit. Rootkits can be detected, but there are a growing number which cannot be removed without an fdisk/format.
OMG! I never thought of the cameras! I mean I did disassemble my shredder to check there, but the fireplace?!? I wonder where I can get my hands on a wideband RF detector?
Strong passwords will be a necessary evil for the forseeable future. How many phones, public/coffee terminals, and home computers have biometric authentication gadgets? How many of these gimicks work together? My users need the ability to access nearly everything on our systems, from anywhere. This includes our WAP portal, email from their phone, our various web-apps, SSH/terminal servers, and their IMAP/SMTP email clients. How many of these systems could even possibly function with anything but passwords. Take the IMAP/SMTP system for example, how would you tie biometic authentication into standard SMTP AUTH? How about a web app - how is a fingerprint entered there? Or consider our WAP gateway, how are users going to enter a fingerprint on their phones?
We cant just mandate users access our systems from "approved" sources - that flys in the face of what management is asking for: A system accessible anywhere, with reasonable security percautions in effect.
Though centralized authentiation schemes like LDAP are working well for us, "legacy systems" (ie: accounting, payroll, and factory/inventory management) dont integrate with central authentication systems. Meaning that's yet another password to remember...
With users accessing our systems from so many sources, strong and frequently changed (90-180 days) passwords are a necessity. Though they need the ability to save them:
1) How important is the data in your wallet/purse. Why not just write the passwords down, store them in your wallet/purse, and then manage that. After-all, if your wallet/purse has been stolen or rumaged through, there's a good chance you'll know.
2) Consider this two-factor authentication system:
Something you have: cell phone
Something you know: password to program
How many folks now have MIDP/Java enabled phones. Why not provide them with an app to securely save their passwords on their phone? With a tool like FreeSafe They could not only store all their passwords on their cell phone, they can generate both random new passwords, and One Time Password hashes.
Now if FreeSafe could only store notes, and have some sort of backup capability (which the developer says he's working on)...
If some random client "...totally hosed the kernel source on BK's server...", then I would consider that a serious flaw in the software well worth discovering and fixing. Afterall, what's to say a malicious client isn't trying to do this very thing right now. Or how about some random layer 2 or 3 data corruption which exposes the same issues.
As we've well-learned, in watching cross-site-scripting, buffer overflows, and other attacks - you can never trust the connecting client.
I manage 29 domains through JumpDomain, and have encountered the SAME issues. I know someone else who manages about 10 through JumpDomain, encountering the same as well.
We've used FreeS/WAN (now OpenVPN) since 2001, with nary an issue. We currently have 12 connections ranging from 144KBit to 3Mbit (all business quality!) all connected together. The VPN/firewall hardware at each site is a Pentium 120Mhz w/ 32MB or RAM, two network cards, and nothing but a floppy disk booting/running LEAF's Bering-uCLib. We have Win2K/XP VPN clients connecting to these "LEAF" systems as well. In theory, OpenVPN can support many hundreds of VPN tunnels - though the highest we've pushed it was around 30 (ie: permeant tunnels plus the Win32 clients) - with about 600 users between all the sites.
When we stress-tested this hardware/software combo, we were able to push just over 7Mbit/sec, and only added about 5ms latency to the link!
This combo has been rock solid - not a single connection failure can be blamed on the VPN software - it has been either the last mile, a NIC failure, or a bad floppy disk. Administration is via SSH (with a web-based admin console in development), and the firewall code is Shorewall.
Bullshit. Frankly, if you were a system administrator working for me, I'd fire you outright right now as, on the basis of what you've said, you're clearly too arrogant and incompetent to do a capable job.
Ouch, terminating an employee for following company policy - now that's harsh. The fact is, for the two employers I've worked for in the last ten years this has been the standard department attitude and policy. Most users clearly don't and shouldn't need to administer their systems - not only do they usually not understand/remember how, nor have the time, IT'S NOT THEIR JOB! In both orgs the attitude and policy I noted was in place even before my time there. There has been energy to change the attitude from time to time - though in every pilot/test program we've run, where more and more control/administration was passed to the end-users (including the ones deemed more fluent than others), we've found consistent sweeping issues:
1) Hardware was damaged due to improper system settings.
2) The rate of system failures increased shaply as users tried to apply unecessary tweaks to their systems, and install unauthorized and uneeded software (ie: when asked to justify, they couldnt).
3) Virus updates failed - the users never notified IT, and systems were infected.
4) Patching routines failed - the users never notified IT, nor attempted to correct the issue theirselves.
5) Users tried to re-implement already existing aspects of the systems - when the underlying issue was that they didn't know about an existing implementation due either to their failure to take the recommend training courses, or to read the information distributed by the department. When the users did pay attention, and were educated, they were happy with what they had, and many times provided constructive feedback on additional features/functionality.
Further, I never advocated lying to everyone. To those employees here who are actively rude, who demand things work without being rational, like the article's original situation, that's sometimes necessary. You misinterpreted my original message (that could have very well have been my fault - that's what I get for composing a brief reply - expecting the blanks to fill themselves in). I've seen many Win32 desktops work very well in "locked down" states - yes it takes time to identify and work around bugs in the software - most folks are happy with that explanation and really don't care to hear how program X's XYZ HKLM/Software/bla/blabla needs to have Read/Write access granted to "all users". You tell them that, you accomplish two things: One, their eyes glaze over, and two, you make them feel like an idiot because they don't understand a word you're saying. It's like when my significant other speaks in one her foreign languages - she sounds great, but I feel like fool with a silly look on my face because I don't understand a word of what she says. If a reasonable user asks for more detail, we give it to them - otherwise it's a bug, end of story.
We live in a world in which a sizable proportion of the population have PCs, and administer them themselves, and know more than a little bit about computing.
Have you paid any attention to the Microsoft Worm/Virus issues plaguing the internet these last few years? The simple fact is, these systems and the procedures to maintain them are becoming increasingly complex, most folks just don't have the time to spare to learn about the newest virus scanning technique, newest firewall issues, or latest software patch available. Why should we expect them to anyway - their system should "just work" without them having to babysit it every-other day. In my book, if two programs don't co-exist together (ie: a spreadsheet and antivirus app), unless one program was sold/designed to break the other (like an antivirus going after a virus), it's a bug - period.
Indeed, there are many people capable of maintaining their own system
"...The problem is that many of the people who are asking for more administrative control over their own machines do, actually, know what they're doing..."
False. In both the academia and business worlds many of the folks who insist on this access are sales, customer service, support (business, admin assistants, etc), and administrative (again, business-related) staff who's "...home computer has never crashed...and never had any problems with full access...". In my experience, most of them where never able to present a valid case for access, and were rejected outright. For those who did, a few examples of their results:
1) The CIO managed to virus-infect every word document on the corp fileserver - as he insisted on full admin rights at the time. His full rights were then of-course revoked afterwards.
2) Unauthorized/pirated software was installed, and in one case was running services for a few users. After it was discovered, we found that the users were trying to re-implement (quite poorly) something already fully implemented - though they had never taken the available classes/training because they "knew enough"...
3) In three separate cases, employees were caught running separate competing businesses using their employer's systems.
For those very few remaining folks who show enough competency and can make a good case for the request. They are granted additional access. They understand that when what they have breaks, they get to keep both pieces - any repairs are going to be at the bottom for the priority list, and yes they do scream loudly when reminded of that fact. Though we maintain: Since they "know enough" and IT is already understaffed and overloaded, they're assisted but expected largely to resolve issues on their own. When it comes to only having enough resources to help the secretary resolve an issue vs the power-user trying to do something, the secretary wins hands down.
Welcome to the real world...
"...who finds their "security systems" get in the way, wants administrative privileges too..."
Security is by definition designed to get in the way - your job as a sysadmin is to minimize the impact that these barriers pose to legitimate uses of the system, and to manage the limited resources which an organization can afford.
Heck I'm the only Senior SysAdmin where I work and I haven't used the root password for any system in over 6 months. There's plenty of tools out there that I can quite effectively do my job without being "god".
"...My advice to the average central administrator is to find solutions to problems instead of lying about them or turning into a control freak. People generally want control over their own machines, so it's important to give them that control..."
Do you live in a dream world? In order to manage something you must be able to exert control over it. Now going overboard is possible - I've seen it done, but again a sysadmin's job is to find the balance between control and functionality, not to release the reigns. Lying? No, if the application does not work without full administrative/root privileges then it's flawed. That flaw/bug prevents you from securing the systems. The solution, as noted in my earlier example, is to remove the restriction that exploits the flaw/bug so people can function again, fix/secure the issue, and then move on.
"...Decentralize the network..."
In MOST orgs (ie: under 500 employees - not counting students in edu environments) - are you KIDDING?!? IT teams are usually small enough that there's no "team" to separate - it's one IT dept, one IT office, period. There's no resources to distribute - except for maybe your "tech" contact at a remote site - who's real job is very likely unrelated to IT.
The email example is great - that takes us back to item number 2 in my list of things which have occurred because a user was given too much access. Again, the functionality was already in the existing system - the user just didn't kno
Ahh, I see. You're talking about the typical developer vs sysadmin debate. On one hand an overzealos developer cannot make a good business case for a "need". Likely also developing services/tools without even consulting the sysadmins in regards to how it impacts the systems - because the devloper "knows what's he's doing". On the other hand the sysadmin is likely far too busy to babysit/handhold them through the process.
I've seen this issue solved quite quickly - make a good case to what you need, and make sure your sysadmin understands what you're doing. Also make sure you regularly communicate with the sysadmin in regards to how something you're doing impacts the systems. I'm not going to punch a hole in the firewall just becuase someone, anyone, wants me to. Make a good case for it - I'll listen and likely tell you how you can utilize an already existing option without futher lowering the systems security/stability/reliabilty.
You said it yourself - you go running to the sysadmin when you really f*** up your system - I'd bet good money you run to them far than an average user. Fine, you develop something - that's gonna happen - but remember you're increasing the sysadmins workload because you wanted that extra access...
Our developers involve the sysadmins regularly (hey, it's called teamwork) - they have all the access they need on their systems (yes, most of them have full admin rights). In-fact frequent requests to them for "anything else you need" frequently come back with "nope, doing great!".
Crude and simple networks huh? Explain... It sounds like you've never tried to develop security policies, nor provide any sort of support for endusers or in sysadmin enviroments. As your comments demonstrate a complete lack of understanding in regards to how difficult it was to get to the current state.
As for the security claim - I cant say I've ever seen that. I run around in the Novell and Unix circles and I've yet to run into anyone trying to make a good argument to use Win32 for anything. In-fact it's quite the opposite - Win32 is frequently the last choice when it comes to back-end systems - for a very good reason...
In a perfect world maybe - but in the real world, when you tell a user to keep both pieces of a broken computer they throw the pieces back at you, and then run screaming to their boss. Disclaimers/waivers be damned - you're fix their broken system, because damn-it you're IT and that's what you (or someone in the already resource-strained IT department) are paid to do.
Sometimes policy overides politics, but many times that's not the case. If your written policy supports the action, then start slowly locking the systems down.
Other than the small group who seeks a power-trip or "administrator badge", you'll find that the bulk of those requesting admin/root access to a system are those who feel the need to do something at that level. Maybe it's a broken Win32 app which requires a lot tweaking to run as a non-administrator, maybe the SysAdmin never setup sudo (properly?). In any case, the user is likely just seeking the access needed to do their job (or what they believe to be is their job).
Start by locking things down slowly. When something breaks, blame it on "a bug" and quietly back-off the restriction until you can figure out what/why something happened. Then either deturmine why/if its needed, fix it, lock it down, and move on. Make sure your IT group/boss supports this action - they love to play along with things like this, as it gives them more power to do their job, enfore policy, secure/stablize the systems, and at times to tell those arrogant users (usally in-front of their boss) "Computer working great? Good. Oh by the way, that access you said you needed, you havent had it for three months...". Oh god, I love to be in the room when we do that!
Intresting thing is, in the business world, the user insisting on the higher-level access is usally having issues elsewhere in their job. I've seen the bulk of employees leave/quit anywhere from a few weeks to a few months after completing this stunt.
Overall, this technique has worked great for me in public/education enviroments and still works very well in the business world.
I've had VoIP for quite some time, and am very happy with the quality and reliablity of the service. In-fact I'm using it from only a 144Kbit/sec (iDSL) line, something I half-expected to cause a number of issues in itself.
Why so Anonymous? I'd like to add you to my friends list.
Eh, too lazy to login at the time I suppose.
Knowing where I was when I started, and trying to talk some friends into going, that's the challenging part now. Heh, the look the faces of my family members when I told them I started dancing. Yet another priceless moment...
Re:Almost as silly as asking
on
SSH or IPSec?
·
· Score: 1
Actually one of my webservers handles 1Mbit without a sweat - but this is a very well designed and mostly static site, with little going on that is generated on the fly. I know someone who runs the systems for a DNS registar, and he claims to have servers that handle far more than that.
For the NICs, I was thinking gigabit IPSec NICs. Either way, my point was that IPSec enabled NICs were pennies compared to the monthly cost of say an OC12. Look at it this way; if you can save your company $30k+ on not having to purchase an IPSec capable OC12+ router, I'm sure it's a possiblity to talk them into shelling out a few thousand for a few spare IPSec cards, and payment to a FreeS/WAN developer to write the necessary code:-)
Heck, Cisco only does 440Mbit/sec IPSec in hardware (using the PIX 535 - please correct me if there's something better). That's not even halfway to gigabit.
I'm not sure I follow you on the asymmetric encryption though. My system handles far more than 100 operations per second.
Oh, and I did leave out something in my previous message - I also have compression enabled on all my IPSec tunnels - so that adds a little bit of overhead as well - but either way, it's still running well on a P166...
Re:Almost as silly as asking
on
SSH or IPSec?
·
· Score: 1
Maybe not interesting to you, but to most of the people out there - getting 1.5MBit on a low-end machine is far more than they could have asked for. Move up the ladder to a faster system, and you can push much more than that (for example. you can push 45Mbit/sec with a 1.2Ghz Pentium using FreeS/WAN - this is the equivalent of a fully loaded T3, or 28 fully loaded T1's). Could you get gigabit DES3 out of a 4 way xeon? Maybe...
Regarding a webserver only dealing with 1Mbit/sec of traffic - yes I believe this is all you need in many cases. You have to remember that many of the sites out there sit behind connections that run at or slower than T1's (which are 1.544Mbit/sec connections). If you have the money to pay a monthly bill that supports something at or faster than a T3, I'm sure you have the money to go out and either purchase a hardware crypto card (ballpark they run anywhere from $300 to $1000) that works with FreeS/WAN - or to just get your hands on a dedicated router that does all of the IPSEC for you. Afterall, T3's usually cost anywhere from $15,000 to $25,000 per month. If you start talking about gigabit (ie: OC48) - well, now you're looking at several hundred-thousand dollars a month. Overall, the cost of a crypto card is a drop in the bucket, even if you had to pay someone a few thousand to add the support to FreeS/WAN.
On a second note - why would a webserver be running IPSEC anyway? SSL is much better suited for the task.
Re:Almost as silly as asking
on
SSH or IPSec?
·
· Score: 5, Informative
FreeS/WAN may not be _The Best_, but it's darn good enough:
I have a system where 12 sizable offices come into a FreeS/WAN router via a 1.5Mbit link, and the VPN moves on average 1Mbit/sec between these offices (sometimes peaks to 1.5Mbit). The VPN router that all 12 networks point to is a Pentium 166 w/ 64MB of ram, the router's been up for over 6 months (an office move required a shutdown 6 months ago), and the VPN only adds around 5 to 10 ms of latency to the connection. Heck, I get better network performance out of this setup, than my old Cisco's did running point-to-point frame-relay.
The FreeS/WAN product can also offload the crypto tasks to hardware devices when really necessary.
I use LEAF, and have since they forked their code from the original "Cop Killer" Dave at linuxrouter.org. The Bering floppy and CD images are the best, with tools like GRSecurity (enhanced kernel security), Shorewall (great tool for configuring ipchains, for every possible setup), FreeS/WAN (IPSEC/VPN tools), and a 2.4 based kernel that works great on a 486. The best thing is the developers over at LEAF, keep their packages current.
At present, I have 6 offices, hanging off this setup, with each one running the VPN daemon as well. There are plans in place (installation stage) to get 6 more internet circuits for the rest of our offices, making making for a total of 12 offices running off this code. It's excellent code, with a very well integrated setup, using standard tools, and gobs of documentation.
The best thing; except for the main office (which uses a P166), everyone else will be running their firewall and VPNs on pentium 100's or 120's, with 24 or 32 megs of ram.
Intresting, the last time I downloaded unsupported developemnt code from Novell's developer site (it was perl) - it abended my server frequently - wheras the same perl scirpt using the older production-level version of perl did not abend the server. I dont know about you, but I'm not willing to run unsupported development binaries on my production servers, which frequently causes them to abend. Espically when NetWare has such poor process/memory isolation - ie: when an abend occurs, it's near impossible to get abended services back online without a restart of the entire server.
Slashdot Mirror
It would be very helpful to be able to use Group Policy and SUS for maintaining those apps!
Once on a Linux desktop, you will not have tools such as SUS and Group Policy - as other Linux-based options, such as apt-get and Mozilla's lockPref() will replace them. Consider that you need to learn how to use your new administration tools, just as much as your users will need to learn how to use their new tools.
Like Netscape and Mozilla, nearly everything in firefox can be locked down (Google for "firefox lockpref").
Quick overview:
1) Open prefs.js
2) Where you want to lockdown something, replace user_pref() with lockPref(). Once done delete any lines which still have user_pref()
3) Byteshift (offset=13) the changed prefs.js file. This can be done via an online script. Or download a perl script to run locally. The resulting file should be called firefox.cfg
4) Put firefox.cfg in the root of the FireFox install folder, and a 1.js in prefs/default with the line:
pref("general.config.filename", "firefox.cfg");
We lock settings such as the proxy, homepage, cache, history, download locations, and weak security settings (saving passwords, SSLv2, etc...).
I believe it's also possible to point to a webserver which can feed the lockPref values dynamically (ie: based on authenticated username).
BTW: firefox.cfg can be called anything you want, just make the appropriate changes to the instructions above.
False. Be careful where you make such broad "...everything..." statements.
Some spyware either is, or borders on, the definition of a rootkit. Rootkits can be detected, but there are a growing number which cannot be removed without an fdisk/format.
OMG! I never thought of the cameras! I mean I did disassemble my shredder to check there, but the fireplace?!? I wonder where I can get my hands on a wideband RF detector?
Strong passwords will be a necessary evil for the forseeable future. How many phones, public/coffee terminals, and home computers have biometric authentication gadgets? How many of these gimicks work together? My users need the ability to access nearly everything on our systems, from anywhere. This includes our WAP portal, email from their phone, our various web-apps, SSH/terminal servers, and their IMAP/SMTP email clients. How many of these systems could even possibly function with anything but passwords. Take the IMAP/SMTP system for example, how would you tie biometic authentication into standard SMTP AUTH? How about a web app - how is a fingerprint entered there? Or consider our WAP gateway, how are users going to enter a fingerprint on their phones?
We cant just mandate users access our systems from "approved" sources - that flys in the face of what management is asking for: A system accessible anywhere, with reasonable security percautions in effect.
Though centralized authentiation schemes like LDAP are working well for us, "legacy systems" (ie: accounting, payroll, and factory/inventory management) dont integrate with central authentication systems. Meaning that's yet another password to remember...
With users accessing our systems from so many sources, strong and frequently changed (90-180 days) passwords are a necessity. Though they need the ability to save them:
1) How important is the data in your wallet/purse. Why not just write the passwords down, store them in your wallet/purse, and then manage that. After-all, if your wallet/purse has been stolen or rumaged through, there's a good chance you'll know.
2) Consider this two-factor authentication system:
Something you have: cell phone
Something you know: password to program
How many folks now have MIDP/Java enabled phones. Why not provide them with an app to securely save their passwords on their phone? With a tool like FreeSafe They could not only store all their passwords on their cell phone, they can generate both random new passwords, and One Time Password hashes.
Now if FreeSafe could only store notes, and have some sort of backup capability (which the developer says he's working on)...
If some random client "...totally hosed the kernel source on BK's server...", then I would consider that a serious flaw in the software well worth discovering and fixing. Afterall, what's to say a malicious client isn't trying to do this very thing right now. Or how about some random layer 2 or 3 data corruption which exposes the same issues.
As we've well-learned, in watching cross-site-scripting, buffer overflows, and other attacks - you can never trust the connecting client.
I manage 29 domains through JumpDomain, and have encountered the SAME issues. I know someone else who manages about 10 through JumpDomain, encountering the same as well.
Ohh web! What browser was that? I wonder if it has Bluetooth CF support - I'd love to tie that into my GPRS phone!
I second OpenVPN was well.
We've used FreeS/WAN (now OpenVPN) since 2001, with nary an issue. We currently have 12 connections ranging from 144KBit to 3Mbit (all business quality!) all connected together. The VPN/firewall hardware at each site is a Pentium 120Mhz w/ 32MB or RAM, two network cards, and nothing but a floppy disk booting/running LEAF's Bering-uCLib. We have Win2K/XP VPN clients connecting to these "LEAF" systems as well. In theory, OpenVPN can support many hundreds of VPN tunnels - though the highest we've pushed it was around 30 (ie: permeant tunnels plus the Win32 clients) - with about 600 users between all the sites.
When we stress-tested this hardware/software combo, we were able to push just over 7Mbit/sec, and only added about 5ms latency to the link!
This combo has been rock solid - not a single connection failure can be blamed on the VPN software - it has been either the last mile, a NIC failure, or a bad floppy disk. Administration is via SSH (with a web-based admin console in development), and the firewall code is Shorewall.
Ouch, terminating an employee for following company policy - now that's harsh. The fact is, for the two employers I've worked for in the last ten years this has been the standard department attitude and policy. Most users clearly don't and shouldn't need to administer their systems - not only do they usually not understand/remember how, nor have the time, IT'S NOT THEIR JOB! In both orgs the attitude and policy I noted was in place even before my time there. There has been energy to change the attitude from time to time - though in every pilot/test program we've run, where more and more control/administration was passed to the end-users (including the ones deemed more fluent than others), we've found consistent sweeping issues:
1) Hardware was damaged due to improper system settings.
2) The rate of system failures increased shaply as users tried to apply unecessary tweaks to their systems, and install unauthorized and uneeded software (ie: when asked to justify, they couldnt).
3) Virus updates failed - the users never notified IT, and systems were infected.
4) Patching routines failed - the users never notified IT, nor attempted to correct the issue theirselves.
5) Users tried to re-implement already existing aspects of the systems - when the underlying issue was that they didn't know about an existing implementation due either to their failure to take the recommend training courses, or to read the information distributed by the department. When the users did pay attention, and were educated, they were happy with what they had, and many times provided constructive feedback on additional features/functionality.
Further, I never advocated lying to everyone. To those employees here who are actively rude, who demand things work without being rational, like the article's original situation, that's sometimes necessary. You misinterpreted my original message (that could have very well have been my fault - that's what I get for composing a brief reply - expecting the blanks to fill themselves in). I've seen many Win32 desktops work very well in "locked down" states - yes it takes time to identify and work around bugs in the software - most folks are happy with that explanation and really don't care to hear how program X's XYZ HKLM/Software/bla/blabla needs to have Read/Write access granted to "all users". You tell them that, you accomplish two things: One, their eyes glaze over, and two, you make them feel like an idiot because they don't understand a word you're saying. It's like when my significant other speaks in one her foreign languages - she sounds great, but I feel like fool with a silly look on my face because I don't understand a word of what she says. If a reasonable user asks for more detail, we give it to them - otherwise it's a bug, end of story.
Have you paid any attention to the Microsoft Worm/Virus issues plaguing the internet these last few years? The simple fact is, these systems and the procedures to maintain them are becoming increasingly complex, most folks just don't have the time to spare to learn about the newest virus scanning technique, newest firewall issues, or latest software patch available. Why should we expect them to anyway - their system should "just work" without them having to babysit it every-other day. In my book, if two programs don't co-exist together (ie: a spreadsheet and antivirus app), unless one program was sold/designed to break the other (like an antivirus going after a virus), it's a bug - period.
"...The problem is that many of the people who are asking for more administrative control over their own machines do, actually, know what they're doing..."
False. In both the academia and business worlds many of the folks who insist on this access are sales, customer service, support (business, admin assistants, etc), and administrative (again, business-related) staff who's "...home computer has never crashed...and never had any problems with full access...". In my experience, most of them where never able to present a valid case for access, and were rejected outright. For those who did, a few examples of their results:
1) The CIO managed to virus-infect every word document on the corp fileserver - as he insisted on full admin rights at the time. His full rights were then of-course revoked afterwards.
2) Unauthorized/pirated software was installed, and in one case was running services for a few users. After it was discovered, we found that the users were trying to re-implement (quite poorly) something already fully implemented - though they had never taken the available classes/training because they "knew enough"...
3) In three separate cases, employees were caught running separate competing businesses using their employer's systems.
For those very few remaining folks who show enough competency and can make a good case for the request. They are granted additional access. They understand that when what they have breaks, they get to keep both pieces - any repairs are going to be at the bottom for the priority list, and yes they do scream loudly when reminded of that fact. Though we maintain: Since they "know enough" and IT is already understaffed and overloaded, they're assisted but expected largely to resolve issues on their own. When it comes to only having enough resources to help the secretary resolve an issue vs the power-user trying to do something, the secretary wins hands down.
Welcome to the real world...
"...who finds their "security systems" get in the way, wants administrative privileges too..."
Security is by definition designed to get in the way - your job as a sysadmin is to minimize the impact that these barriers pose to legitimate uses of the system, and to manage the limited resources which an organization can afford.
Heck I'm the only Senior SysAdmin where I work and I haven't used the root password for any system in over 6 months. There's plenty of tools out there that I can quite effectively do my job without being "god".
"...My advice to the average central administrator is to find solutions to problems instead of lying about them or turning into a control freak. People generally want control over their own machines, so it's important to give them that control..."
Do you live in a dream world? In order to manage something you must be able to exert control over it. Now going overboard is possible - I've seen it done, but again a sysadmin's job is to find the balance between control and functionality, not to release the reigns. Lying? No, if the application does not work without full administrative/root privileges then it's flawed. That flaw/bug prevents you from securing the systems. The solution, as noted in my earlier example, is to remove the restriction that exploits the flaw/bug so people can function again, fix/secure the issue, and then move on.
"...Decentralize the network..."
In MOST orgs (ie: under 500 employees - not counting students in edu environments) - are you KIDDING?!? IT teams are usually small enough that there's no "team" to separate - it's one IT dept, one IT office, period. There's no resources to distribute - except for maybe your "tech" contact at a remote site - who's real job is very likely unrelated to IT.
The email example is great - that takes us back to item number 2 in my list of things which have occurred because a user was given too much access. Again, the functionality was already in the existing system - the user just didn't kno
Ahh, I see. You're talking about the typical developer vs sysadmin debate. On one hand an overzealos developer cannot make a good business case for a "need". Likely also developing services/tools without even consulting the sysadmins in regards to how it impacts the systems - because the devloper "knows what's he's doing". On the other hand the sysadmin is likely far too busy to babysit/handhold them through the process.
I've seen this issue solved quite quickly - make a good case to what you need, and make sure your sysadmin understands what you're doing. Also make sure you regularly communicate with the sysadmin in regards to how something you're doing impacts the systems. I'm not going to punch a hole in the firewall just becuase someone, anyone, wants me to. Make a good case for it - I'll listen and likely tell you how you can utilize an already existing option without futher lowering the systems security/stability/reliabilty.
You said it yourself - you go running to the sysadmin when you really f*** up your system - I'd bet good money you run to them far than an average user. Fine, you develop something - that's gonna happen - but remember you're increasing the sysadmins workload because you wanted that extra access...
Our developers involve the sysadmins regularly (hey, it's called teamwork) - they have all the access they need on their systems (yes, most of them have full admin rights). In-fact frequent requests to them for "anything else you need" frequently come back with "nope, doing great!".
Crude and simple networks huh? Explain... It sounds like you've never tried to develop security policies, nor provide any sort of support for endusers or in sysadmin enviroments. As your comments demonstrate a complete lack of understanding in regards to how difficult it was to get to the current state.
As for the security claim - I cant say I've ever seen that. I run around in the Novell and Unix circles and I've yet to run into anyone trying to make a good argument to use Win32 for anything. In-fact it's quite the opposite - Win32 is frequently the last choice when it comes to back-end systems - for a very good reason...
In a perfect world maybe - but in the real world, when you tell a user to keep both pieces of a broken computer they throw the pieces back at you, and then run screaming to their boss. Disclaimers/waivers be damned - you're fix their broken system, because damn-it you're IT and that's what you (or someone in the already resource-strained IT department) are paid to do.
Politics suck...
Sometimes policy overides politics, but many times that's not the case. If your written policy supports the action, then start slowly locking the systems down.
Other than the small group who seeks a power-trip or "administrator badge", you'll find that the bulk of those requesting admin/root access to a system are those who feel the need to do something at that level. Maybe it's a broken Win32 app which requires a lot tweaking to run as a non-administrator, maybe the SysAdmin never setup sudo (properly?). In any case, the user is likely just seeking the access needed to do their job (or what they believe to be is their job).
Start by locking things down slowly. When something breaks, blame it on "a bug" and quietly back-off the restriction until you can figure out what/why something happened. Then either deturmine why/if its needed, fix it, lock it down, and move on. Make sure your IT group/boss supports this action - they love to play along with things like this, as it gives them more power to do their job, enfore policy, secure/stablize the systems, and at times to tell those arrogant users (usally in-front of their boss) "Computer working great? Good. Oh by the way, that access you said you needed, you havent had it for three months...". Oh god, I love to be in the room when we do that!
Intresting thing is, in the business world, the user insisting on the higher-level access is usally having issues elsewhere in their job. I've seen the bulk of employees leave/quit anywhere from a few weeks to a few months after completing this stunt.
Overall, this technique has worked great for me in public/education enviroments and still works very well in the business world.
I've had VoIP for quite some time, and am very happy with the quality and reliablity of the service. In-fact I'm using it from only a 144Kbit/sec (iDSL) line, something I half-expected to cause a number of issues in itself.
Why so Anonymous? I'd like to add you to my friends list.
Eh, too lazy to login at the time I suppose.
Knowing where I was when I started, and trying to talk some friends into going, that's the challenging part now. Heh, the look the faces of my family members when I told them I started dancing. Yet another priceless moment...
If you electric car panseys were smart, you'd start promoting EV dragraces. You're sure to get BillyBob onboard when an EV starts winning at "NASCAR".
You mean like the National Electric Drag Racing Association?
SSH2: http://www.mochasoft.dk/palm.html
Actually one of my webservers handles 1Mbit without a sweat - but this is a very well designed and mostly static site, with little going on that is generated on the fly. I know someone who runs the systems for a DNS registar, and he claims to have servers that handle far more than that.
:-)
For the NICs, I was thinking gigabit IPSec NICs. Either way, my point was that IPSec enabled NICs were pennies compared to the monthly cost of say an OC12. Look at it this way; if you can save your company $30k+ on not having to purchase an IPSec capable OC12+ router, I'm sure it's a possiblity to talk them into shelling out a few thousand for a few spare IPSec cards, and payment to a FreeS/WAN developer to write the necessary code
Heck, Cisco only does 440Mbit/sec IPSec in hardware (using the PIX 535 - please correct me if there's something better). That's not even halfway to gigabit.
I'm not sure I follow you on the asymmetric encryption though. My system handles far more than 100 operations per second.
Oh, and I did leave out something in my previous message - I also have compression enabled on all my IPSec tunnels - so that adds a little bit of overhead as well - but either way, it's still running well on a P166...
Maybe not interesting to you, but to most of the people out there - getting 1.5MBit on a low-end machine is far more than they could have asked for. Move up the ladder to a faster system, and you can push much more than that (for example. you can push 45Mbit/sec with a 1.2Ghz Pentium using FreeS/WAN - this is the equivalent of a fully loaded T3, or 28 fully loaded T1's). Could you get gigabit DES3 out of a 4 way xeon? Maybe...
Regarding a webserver only dealing with 1Mbit/sec of traffic - yes I believe this is all you need in many cases. You have to remember that many of the sites out there sit behind connections that run at or slower than T1's (which are 1.544Mbit/sec connections). If you have the money to pay a monthly bill that supports something at or faster than a T3, I'm sure you have the money to go out and either purchase a hardware crypto card (ballpark they run anywhere from $300 to $1000) that works with FreeS/WAN - or to just get your hands on a dedicated router that does all of the IPSEC for you. Afterall, T3's usually cost anywhere from $15,000 to $25,000 per month. If you start talking about gigabit (ie: OC48) - well, now you're looking at several hundred-thousand dollars a month. Overall, the cost of a crypto card is a drop in the bucket, even if you had to pay someone a few thousand to add the support to FreeS/WAN.
On a second note - why would a webserver be running IPSEC anyway? SSL is much better suited for the task.
FreeS/WAN may not be _The Best_, but it's darn good enough:
I have a system where 12 sizable offices come into a FreeS/WAN router via a 1.5Mbit link, and the VPN moves on average 1Mbit/sec between these offices (sometimes peaks to 1.5Mbit). The VPN router that all 12 networks point to is a Pentium 166 w/ 64MB of ram, the router's been up for over 6 months (an office move required a shutdown 6 months ago), and the VPN only adds around 5 to 10 ms of latency to the connection. Heck, I get better network performance out of this setup, than my old Cisco's did running point-to-point frame-relay.
The FreeS/WAN product can also offload the crypto tasks to hardware devices when really necessary.
I use LEAF, and have since they forked their code from the original "Cop Killer" Dave at linuxrouter.org. The Bering floppy and CD images are the best, with tools like GRSecurity (enhanced kernel security), Shorewall (great tool for configuring ipchains, for every possible setup), FreeS/WAN (IPSEC/VPN tools), and a 2.4 based kernel that works great on a 486. The best thing is the developers over at LEAF, keep their packages current.
At present, I have 6 offices, hanging off this setup, with each one running the VPN daemon as well. There are plans in place (installation stage) to get 6 more internet circuits for the rest of our offices, making making for a total of 12 offices running off this code. It's excellent code, with a very well integrated setup, using standard tools, and gobs of documentation.
The best thing; except for the main office (which uses a P166), everyone else will be running their firewall and VPNs on pentium 100's or 120's, with 24 or 32 megs of ram.
If you want to get picky. :-) In 1942 the American Supreme Court decided that Tesla discovered Radio, not Marconi.
Intresting, the last time I downloaded unsupported developemnt code from Novell's developer site (it was perl) - it abended my server frequently - wheras the same perl scirpt using the older production-level version of perl did not abend the server. I dont know about you, but I'm not willing to run unsupported development binaries on my production servers, which frequently causes them to abend. Espically when NetWare has such poor process/memory isolation - ie: when an abend occurs, it's near impossible to get abended services back online without a restart of the entire server.
I'd say it's hell for the admins, more-so than the users. See the discussion here: http://slashdot.org/comments.pl?sid=38496&cid=4128 927