Comment Conversly, why always blame the sysadmin? (Score 4, Interesting) 480
I can empathize with students wanting freedom on a computer network, or even wanting to just play around with the system to see what they can do. Heck, when I was in high school, I was one of those guys who would bump his print jobs up in the queue using pconsole, or discovering all the accounts that had access through the Squid proxy to the Internet.
On the other hand, I was a network/system administrator at a high school after college, and I can understand the challenges administrators have to deal with in terms of high school students. Administrators don't just decide that they want to lock students down; heck, some schools don't WANT their students to have restrictions placed upon them. When I started, the school had upgraded from Windows 2000 to Server 2003 the year before, and the security that was implemented was essentially Windows 2000 security. They made some stupid mistakes; all passwords stored in LM format, weak ACLs on systems, no BIOS passwords, few if any group policies. On the other hand, they had their VLANs designed properly, the servers all had fairly strong passwords, and they weren't running unnecessary services. The security that was implemented was essentially designed to protect users from malware and keep outsiders from poking around. ...Naturally, students decided they wanted to push the envelope. Kids started remotely shutting down one another's laptops and trying to steal one another's passwords. Eventually, a student guessed a faculty member's password, found a user account created by my predecessor long before I started on a faculty server, rdp'd into a server, and tried running a password cracking application...that contained a root kit.
An administrator's job is to, in effect, install and maintain technology that reflects the mission of an organization. Some schools have a pedagogy that encourages open exploration; other schools want strict rules and regulations. The school I worked at fit somewhere in between. When kids decided they wanted to try and cheat on exams, down using p2p applications, and attempt to change their grades, they put me in a position (mind you, just months after I started working there, and hardly after enough time to complete a full security audit and redesign) where I couldn't just trust them to be responsible in an open system. So, the next semester, they were irritated to find out that their accounts were running as local users; that group policies had been designed using strict Software Restriction Policies creating a whitelist of applications they could run; that their laptops and desktops all had BIOS passwords; that the only route out to the Internet was through an ISA server that connected directly to a filtering application, and then into a Packet Shaper; that their Flash plugin was disabled; that their ability to run Java applications was limited; that their exam account couldn't do anything EXCEPT run the exam application; that their ability to create and log onto local accounts was eliminated, etc.
Were there things on that list that should have been implemented earlier? Absolutely! Any organization should ALWAYS have BIOS passwords set on their machines, which should change every year. LM passwords should NEVER be enabled. Having some type of proxy is also a must, as are strong ACLs on switches and routers. Some type of bandwidth management device should be implemented, as there are more than three people using the network at a school. The school DEFINITELY should have set up WSUS to keep their Windows systems updated.
I'll admit that, when I have the authority, I'm active in creating (from the start) a secure environment, but you're not helping out an administrator when you just start poking holes in the network and not give them the chance to fix the holes. Schools don't have huge budgets, and the IT department is often required to play the role of help desk, admin, developer, engineer, etc, rather than just one niche. In my case, I was lucky; I had a good relationship with the people at the high school (including the faculty administrators and the members of the board), so I wasn't in any risk of losing my job, but in a lot of cases, an administrator may want to make changes for the better, but may not be granted the time or authority to do so. How is it going to improve security if all you end up doing is getting a bright junior or mid-level admin fired?
The flipside to that whole rant is that a student who finds security holes at a school can create a strong rapport with the admins if he or she approaches the problem the right way. If you find a hole, tell the admin. Don't continue to exploit the hole. Don't tell a bunch of other students. Definitely don't spread the hole throughout the hole school, especially if that choice is made prior to informing the admin. Ask the admins to teach you something. Request that your school create a program like Hacker High School. Join (or help create) a computer club for your school. In other words, don't be a pain in the ass.
On the other hand, I was a network/system administrator at a high school after college, and I can understand the challenges administrators have to deal with in terms of high school students. Administrators don't just decide that they want to lock students down; heck, some schools don't WANT their students to have restrictions placed upon them. When I started, the school had upgraded from Windows 2000 to Server 2003 the year before, and the security that was implemented was essentially Windows 2000 security. They made some stupid mistakes; all passwords stored in LM format, weak ACLs on systems, no BIOS passwords, few if any group policies. On the other hand, they had their VLANs designed properly, the servers all had fairly strong passwords, and they weren't running unnecessary services. The security that was implemented was essentially designed to protect users from malware and keep outsiders from poking around.
An administrator's job is to, in effect, install and maintain technology that reflects the mission of an organization. Some schools have a pedagogy that encourages open exploration; other schools want strict rules and regulations. The school I worked at fit somewhere in between. When kids decided they wanted to try and cheat on exams, down using p2p applications, and attempt to change their grades, they put me in a position (mind you, just months after I started working there, and hardly after enough time to complete a full security audit and redesign) where I couldn't just trust them to be responsible in an open system. So, the next semester, they were irritated to find out that their accounts were running as local users; that group policies had been designed using strict Software Restriction Policies creating a whitelist of applications they could run; that their laptops and desktops all had BIOS passwords; that the only route out to the Internet was through an ISA server that connected directly to a filtering application, and then into a Packet Shaper; that their Flash plugin was disabled; that their ability to run Java applications was limited; that their exam account couldn't do anything EXCEPT run the exam application; that their ability to create and log onto local accounts was eliminated, etc.
Were there things on that list that should have been implemented earlier? Absolutely! Any organization should ALWAYS have BIOS passwords set on their machines, which should change every year. LM passwords should NEVER be enabled. Having some type of proxy is also a must, as are strong ACLs on switches and routers. Some type of bandwidth management device should be implemented, as there are more than three people using the network at a school. The school DEFINITELY should have set up WSUS to keep their Windows systems updated.
I'll admit that, when I have the authority, I'm active in creating (from the start) a secure environment, but you're not helping out an administrator when you just start poking holes in the network and not give them the chance to fix the holes. Schools don't have huge budgets, and the IT department is often required to play the role of help desk, admin, developer, engineer, etc, rather than just one niche. In my case, I was lucky; I had a good relationship with the people at the high school (including the faculty administrators and the members of the board), so I wasn't in any risk of losing my job, but in a lot of cases, an administrator may want to make changes for the better, but may not be granted the time or authority to do so. How is it going to improve security if all you end up doing is getting a bright junior or mid-level admin fired?
The flipside to that whole rant is that a student who finds security holes at a school can create a strong rapport with the admins if he or she approaches the problem the right way. If you find a hole, tell the admin. Don't continue to exploit the hole. Don't tell a bunch of other students. Definitely don't spread the hole throughout the hole school, especially if that choice is made prior to informing the admin. Ask the admins to teach you something. Request that your school create a program like Hacker High School. Join (or help create) a computer club for your school. In other words, don't be a pain in the ass.
