Slashdot Mirror
Ask Slashdot: Securing Systems you don't Manage
A verbose member of Clan Anonymous Coward asks this
difficult question: "My university has a problem.
We have lots of autonomous departments managing their own
computing infrastructure, lots of autonomous
users managing their own computers and a very
large network population (in excess of 20k people). Of the
systems which are not managed by "professionals" about 10%
are linux. How should the university tackle the problem of
people keeping their boxes up-to-date whenever
it has little control on the box owners? Using
tools to identify problems (e.g. nmap, satan,
etc) is the easy part. How do we then get
hundreds of different computer owners to update their systems when they didn't know what they
were doing in the first place? How to we do
this in a climate where the resources are
not available to employ herds of new computer
support staff to assist these people?"
Our anonymous submittor continues...
"Many of us recognise linux as being a good thing (tm) and indeed many of us use linux to provide high availability and robust services. Unfortunately, many of the "non-professionals" who install linux tend not to know what they are doing. They get their system installed and bring it up on the network (easy now compared to what it used to be!) and then leave the system to look after itself. All fine so far, except that most of these boxes are running the plethora of services that come enabled by default on popular linux distributions (e.g. imap, www, etc.).
The problem comes in like this: there is a high rate of publication of exploits for linux systems and, unless users are very careful to keep up-to-date with patches, they are compromising the entire computing infrastructure for everyone."
This sounds like a Network Policy Issue. Most networks have rules that state the acceptable uses for the resource and the conditions that must be satisfied for it's continued use. It seems something like this would be appropriate here. The larger problem however, is its enforcement. What do you all think?
"Many of us recognise linux as being a good thing (tm) and indeed many of us use linux to provide high availability and robust services. Unfortunately, many of the "non-professionals" who install linux tend not to know what they are doing. They get their system installed and bring it up on the network (easy now compared to what it used to be!) and then leave the system to look after itself. All fine so far, except that most of these boxes are running the plethora of services that come enabled by default on popular linux distributions (e.g. imap, www, etc.).
The problem comes in like this: there is a high rate of publication of exploits for linux systems and, unless users are very careful to keep up-to-date with patches, they are compromising the entire computing infrastructure for everyone."
This sounds like a Network Policy Issue. Most networks have rules that state the acceptable uses for the resource and the conditions that must be satisfied for it's continued use. It seems something like this would be appropriate here. The larger problem however, is its enforcement. What do you all think?
The way I see it there are a few things you can do to minimize your risk.
.edu kiddies are discovering packet sniffers for the first time.
First and foremost, allow NO trust between your systems and systems you don't manage. If someone manages to crack one of those linux boxes, the last thing you want is to have them then able to rsh to one of your systems. Disable your R* services on all your machines, don't allow them to NFS mount your systems, etc.
Second, you may consider refusing connection to all ports on the systems in question from outside campus. Perhaps put machines where the admin can demonstrate the system is secure on a different subnet and allow them to accept inbound connections.
You may want to do routine security audits with the various penetration testing tools out there and notify administrators of systems with security issues by E-mail (You may want to do this for your windows guys, too. Bunches of them have sharing on by default and everyone can get to their hard drives from the network.)
Far too many people take security too lightly these days. Feel free to create a draconian security policy but be willing to be reasonable if the admin can demonstrate that they can run a secure system.
Oh, and you might want to look into mandating encrypted traffic on your network, since a lot of
hi, and welcome to the club!
seriously, what we have is the same problem at my univ. how do we solve it? good question. one suggestion i make is to have a staff of people on hand who know what they are doing with UNIX boxen. despite what many suits and schleps say, UNIX boxen are all too important for their horsepower (hardware and software) that can't be rivaled by NT, despite the hype. have a staff in your network services clan, ie in user support, who know what they are doing. make them available left and right for free or for a small fee, something very reasonable. and make sure they're trained, as i wont let all too many of our user support staff near our million dollar equip- they are just too dumb.
secondly, if a problem pops up, visit the person immediately in person. "hi, we noticed some issues from this system." it's probably safe to assume in most instances that the problem didn't really originate from a legit user of that system. but pull the system off the network and help with a security issue as you would normally. do it in person so that they don't fsck things up and wipe logs or whatnot. also make sure you approach them in a friendly manner, you are their friend. it will foster an environment in the future that generates more positive responses and faster responses if a problem is sensed.
lastly, educate people and ensure that they value security and know that assistance is available for setting up systems.
i should note that these are not really solutoins that in magically in place. i had to do a lot of work to ensure that people know who we are and what we do, who to contact etc... it took a lot of work. i'm still trying to change the system from the users' end (ie we have no official security coordinator though we see lots of attacks left and right, we tend to handle it as a system mgr user base ourselves), but things are improving, albeit slowly. and lastly, if you can move to a seriously routed network, you can manage to minimize issues more so than with a large, flat network (yeah, they exist, believe me!).
i hope this helps, and good luck!
jose nazario
jose@biocserver.cwru.edu
Posted by pwd:
This made me think of the general problem of
supporting a bunch of different systems, your
example is an extreme case of not being able
to force things. Off the top of my head I think
that I would not separate the Linux users
from the rest of the group, the problems may
be more common due to the wider support for
services under Linux but the problem is not
limited to full service systems, you could
get a back door problem on a Win 98 system.
I think that the first thing that I would
do is to set up a data base of each of the
system with a routine to check for there
location on the network; in other words have
your hubs report what is mac address is
using what port and then translate that to
an IP address and a system ID. Here with
only a few hundred system I built something
like that and we find it a godsend. Then I
would go further and loop slowly through
the list and check for security problems on
each system, this is the part that you have
a handle on. One of the things that I would
do is to use one of the OS type program so
that I don't have to depend on the user
telling me which OS they are running, you
might have a number of dual boot systems
(with that number of systems I would not
be surprised to find some real strange stuff).
When you find a problem then do one of two
things, if the system is where you think it
should be and is not some rogue add-on to
you network send the "owner" of the system
a e-mail (automatically of course) with
the following info.
1) that a problem was found.
2) what the problem was and why this is
a problem, this is where you need to
do a selling job and give the owner a
clear reason why it is in there best
interest to fix this problem.
3) instructions on how to fix the problem,
(turning off services that are un-needed,
updating software, running a anti-virus
program etc.)
Your question has started me thinking about the
more general case of not having ownership of
all of the systems on a network, this is more
common that one might think at first.
"How do we then get hundreds of different computer owners to update their systems when they didn't know what they were doing in the first place?"
I believe the case is more that your worried that _you_ don't know what _they_ are doing, not that they don't know what they are doing.
This is interesting, as I have learned from history (local department security hole where hacker comes in, and tries to get somewher else on campus from hacked box). But the problem isn't yours so much as it is the users... Just follow me for a moment...
Basically every box on your network is it's own little world, and security problem, and that problem is isolated to that IP address, if you take the right precautions. The person who set that box up is responsable for security of that system, not the campus at large or the computer department or the computer gurus.
The key to good security is to insure your not relying on inadaquite security protocol. And by inadaquite, I mean, "If the request comes from a box in our IP block, then it's safe, and we can allow it special privlages." That's LAZY security management, and the source of the bulk of your security risk.
Here, in my department, where we live in the massive IP space of ".nodak.edu" we don't want people telling us how to fix our security problems, at all! ".nodak.edu" covers the whole state, and North Dakota Higher Education Computer Network (NODAK-DOM), which means every university in the state relys on people in one city at one center for management. They are 70 miles away from us, and they don't know what we do, or why we do it.
We are very thankfull that they keep the backbone up, and keep our bandwidth sufficent, and keep the main servers and routers running. But to think about having them try to manage security for the whole state is rediculus! There are boxes I know of on our LAN with know security holes, and we realize they are there, and are leaving them there for the time being. Because the case is this, when the security patch is installed for a know hole, the applications we rely on no longer function, we submit a bug report, which takes up to 2 months to get addressed (IF it even gets acknoledged), and wait. Meanwhile, what are we to do? Fix the hole and make the rest of the campus happy, meanwhile not being able to do any work or research? Or, leave the hole, closely monitor connections and contacts, and keep doing research (which is why the computers were purchaced in the first place).
People make judgement calls, and assume risk. That's a fact of life. In order to achieve a goal, sometimes risks are taken. But, I still say, everyone has to see it's simply a case of "breach my box, my fault for not keeping track. Breach your box from my breached box, it's YOUR fault, not mine."
Ultimately, it's the hackers fault, not the admin. But the admin's job is to keep a secure box. If your worried about something being breached on your network, then you admin it. If your administration range covers more than you can the boxes you can admin, deal with the fact that you managed to work your way up the bandwidth chain, and from your level you have to deal with bigger issues, so make it clear that security on an indivual box basis is the responsbility of the person who uses that box.
What about doing some sort of remote boot over the network, they grab the kernel and all other core os components off a nfs server, which you keep up-to-date, let them then mount and use thier local filesystem at thier own risk, and any services they want to run that you arent maintaining on the nfs server would be have to be local... So anything you have security concerns, you load and run remote, even keep the conf files for said services and such remote...
in an educational environ it will be hard to get anything approaching this implemented, due to user`s 'rights' and 'academic freedom' - I had to deal with this constantly when i worked at a college...
man is machine
Many suggestions where made here. All were good ideas. However, Firewalling and Masquarading are overkill for your needs. Being a network gestapo is also not worth it.
The single biggest thing you can do is to inform and educate admins on your network. To that end, you might be best off if your IT department sponsorred some users groups and regularly gave talks about network security. Also, after finding problems in people systems simply telling them they have one is not good enough. Tell them where to get the fixes and how to fix it. Few, if any users actually WANT their systems to be insecure but they just don't know how to go about fixing their problems. Make it easy for them.
That being said, you will run into the few that simply don't care. For those you will need some method of keeping them off the net till they learn to care. Combinations of DHCP and managed switches and the like are a good start.
And lastly, you will need an absolute policy regarding any and all university owned machines, whether they are department servers or personal workstations. Especially in regards to allowing trusts between them. For instance, in the case of a student admin over a departmental server allowing trusted access from his own system for admin purposes is bad. What if the students own system is compromised? It's then a simple step into a departmental server. This can cascade into a whole slew of compromised systems.
I come from a university that had no such policies. I also have ties into the hacker community in the area. Security at the university was a well known joke. We always had a good laugh is someone mentioned the two words together.
** Martin
The ipmasq/firewalling ideas already mentioned are very good - consider them!
/etc/hosts.*, and create a basic set of ipfwadm/ipchains rules to block access to vulnerable ports on the box, such as 2049 and 6000.
.deb, .slp and .rpm packages (and getting permission from the author of the DTK, which is not free-for-all-use).
I have some others that might help:
Find/write a simple script that locks down
Have the script add a listener to the Deception port (see http://www.all.net/dtk/), and use the replies from it as a marker that "this box has been secured", during your automated scans.
Of course, the user *can* change the scripts and open his box up, but at least this way he has to think about why he is doing so, and hopefully has read some thought provoking material included with the lock-down script.
In fact, if you can get all your Linux users to install versions of the DTK (see the above URL), then it will be extremely hard for crackers to zero in on new "unsecured" boxes. This would require packaging the DTK into
The basic idea behind the DTK is very appropriate in situations like yours: since you cannot be sure that everyone is secure, make sure *everyone* looks like a potential victim (even if they aren't).
The hardest trick is to get the users to install it (and other hacks you might come up with). One way to (help) ensure this is to maintain a few local distribution-mirrors, where your protection packages have been added to the default installation. Encourage people to set up Linux from the local mirror (speed! security!).
Good luck!
Host your own websites, anywhere!
Firewalls are nice, but only work if you have control over the systems behind the firewall. Imagine if I, Joe Student, download a little program from outside the Internet, then run it. This program then creates a tunnel that originates from *behind* the firewall, yet allows the author to tunnel behind the firewall. The user then monitors packets on the internet, collecting *any* plain-text passwords going on the internal network. Before long, your entire network can be compromised. This is not a good solution.
Firewalls are nice. They are a good and necessary part of any security system. However, unless you plan to isolate all these rogue machines outside a firewall (a firewall that blocks different departments from one another), firewalls won't work by themselves. Besides, if your university is anything like the one I attended, it's not just students setting up rogue machines, but also staff & faculty. It's really hard to isolate the rogue machines outside a firewall in these cases.
IMO, you should look at MIT. They use Kerberos for all their non-rogue machines. All passwords (to university machines, at least) are sent over the network encrypted. This way, if Joe Student's machine is compromised, the cracker won't be able to sniff packets for passwords to other, more sensitive machines.
Beyond this, I think you need to ask yourself, "Should I really be enforcing security upon the students/staff/faculty?" This is a huge headache, and one that can never be handled completely. Besides, by acting as a security police for the students, you open yourself and the university up to a ton of potential lawsuits from machines that, despite your best efforts, are compromised.
I'd put in firewalls (IP Masquerading are nice, because there are no changes to users, nor are there any training issues regarding setting up proxy services within net applications) and Kerberos. Ensure that Kerberos is installed on *all* official machines. Then, let the students do what they want. If their machines get compromised, then that is their fault. Make it clear that security responsibilities lie solely in the hands of the students, and that the university will not monitor security issues for *any* machine not administrated by the university.
-dan
--Be human.
have seen work best are a combination of policy and technology, you
need both. You need to determine what the current network usage policy
is, how well it is enforced, and whether or not you can get it
changed.
You need to sit down with the rest of the folks in charge
of administering the networks (and at 20,000 users I hope you aren't
the only one). Determine what services you want to support, what
services you will allow but not support, and what services you will not
allow. You also need to determine what happens if a user should use
those services that are not allowed, and it must be enforced
consistently.
For example: All users with machines on the university network
must have their OS and root/administrator contact information
registered with the NOC. Users are responsible for maintaining the
security of their machines. *nix machines may only run services x and
y, as well as z if they register it with NOC or will cut off from
network access. Win95 users can go suck eggs, etc.
Users may not attempt to gain unauthorized access to any machines
on the university networks or otherwise, or they'll be referred to the
Dean for a spanking.
Then implement as many technological constraints as you can. Have
your routers block naughty traffic. Look for other nastiness[1], scan
your networks[2], and make sure the policy in enforced regularly, or it
isn't worth the work.
Most importantly: good luck.
right people. You may need permission from just the IT director or maybe the
President of the university
This policy really doesn't work. The problem is very straight forward -- when you have loads of these insecure systems around, and someone decides to crack one of them, two things happen. The first is that the cracker now has a nice comfortable fairly anonymous platform on the network that they can beat up other boxes on the network from. These boxes may not be student machines -- they might be after the campus webserver next. Now it most definitely is network operation's problem, and they have to go out, hunt down you box, turn it off, and try to clean up the mess. This takes time. Lots of time. Not to mention the other thing that is likely to happen is that the student/proffessor notices that their box is behaving wierdly, and runs for network operations, who now has to come and troubleshoot the machine (yes, has to, as tenured prof's don't take kindly to being told that "it's your problem"). If you want the school to allow you to run you linux box on a network without too many restrictions, you have a responsibility -- you have to make sure that your box, if not ridiculously secure, is at least decently well guarded. Do this, and you can keep your nice open network. Otherwise, expect to have the clamps put on, and tight.
/P.
The only solution I can see here is either to firewall everything off and force them to use that (it's not a pancea for all problems, but it'll keep outside attacks down) - as you do own the network bandwidth, right?
Or you can use a IP masqarading host and don't tell anyone you made the change. You can then transparently proxy everything about and keep outside connections.. outside.
You could also just take their boxen off the network unless they either maintain them themselves or let you -> ie, sudo access to RPM.
Make sure to keep this very simple, and open if you do want to do this - the users will castigate you if you mess up and give them a broken package or make it more than trivial to upgrade.
Or simply deny access to any university resources from unsecured machines.
--
That way, if a particular machine is causing trouble, you can turn it off. That's particularly effective in combination with network security scans.
Switching hubs also keep crackers from monitoring network traffic once a machine is compromised. If you have filtering, you may be able to enforce (well, strongly encourage) the use of particular network protocols and turn off others when there are specific problems.
You also get better performance with switching hubs, another reason to install them.
Your stated a machine base of 10% linux, I am assuming that a good persentage of the remaining un-managed boxen are windows.
I agree with most of the statements that suggest firewalling, security policy, etc.
Your problems in my opnion will be the enforcement of the policy, creating a policy, implementing the policy, and user complaints based on the policy.
Implementation will be one of the hardest aspects(beside enforcement). You will have to assume that the majority of your users are idiots, and write comprehensive step by step documentation
that will lead them by the hand through the process of securing their machines.
Enforcement of the policy will also be hard, a simple port scan, or external security tool run will catch blatant violations. Where I see problems is in the realm of the more subtile aspects, things that can only be checked by internal access to the machine. Do you have the manpower/inclination/time to run around and check all the machines that are in use?
The soloution IMHO is to combine good firewall
policy, with good internal security policy(someone who knows the numbers can point out how many security violations are internal), both of which need to be combined with user education as to why security should matter to them.
Keep in mind though, that as soon as the firewall goes up, and the policy becomes enforced, you will get complaints from all manner of users. Asking why "the thing they did yesterday" doesn't work today, with little to no more information.
Sorry I'm rambling.
This way, only the people who are willing to go out of their way to set it up will get the services they want. Also as a part of this you might want to offer some sort of official security testing procedure where if soembody wants to, they can call you up and ask you to run SATAN, etc, and make sure that they are in good shape.
In general it sounds like this is more of an issue to be solved through policy and communication and less through technical means.
---
This sig has been temporarily disconnected or is no longer in service
Talk to Texas A&M University about their tools for security. Especially their firewall Drawbridge, and Tiger security auditing scripts. They also have monitering software to moniter their internal network for cracking signatures.
Another sorce is to look at CERT. They have lots of links to documents and articles on security. One of their documents pointed me to the TAMA stuff.
Drawbridge is designed for blocking off site access on a machine/port by machine/port basis. Machines that pass the tiger scripts are enabled for more external access than ones that don't. As a default only SMTP is enabled from off site to a machine. Higher levels of external access can be obtained when a machine meats tighter security levels.
One of the nice things about Drawbridge is it can be run on a PC, and securly remotly updated. It also uses lookup tables so it's fast. It is a memory hog, but then that's the price for speed. I belive it will only work for Class B and C networks.
Email me at bryan@visi.com, and I'll gather a bunch of related links from my bookmarks at home. There are some good PDFs on their experiences, and the tools they made to implement security.
I've been dealing with security alot lately as I've recently setup a firewall for my home system. I personally don't use Drawbridge as my network is small and Linux IPCHAINS is more suited to my system. I do use some of the Tiger scripts for auditing. I also use Tripwire (available from CERT).
I'd like to propose an idea to guide your philosphy of how to succeed in this project, which is that the University network in this case is acting like an ISP (or at least a gateway)Alot of the same customer service issues apply.
- Don't piss off the user community by becoming a Network Gestapo. You'll end up very unpopular and possibly unemployed. Some of the offending users might be tenured professors, etc. who might take a dim view if you're not nice about solving the problem.
- Create/work with the local Linux Users group. Provide incentives for the user group leaders and members to take charge of the issue.
- Write a sniffer program to ferret out the appropriate information from the compromised machines. Using the output of the sniffer, send a friendly e-mail with
- "here's the problem....
- here's how to solve it....
- here's the consequence if you don't take care of it yourself....
- and finally this last item should have a "pull the trigger" deadline after which the sniffer's output (systems not in compliance) will have their access privileges terminated.
- After the cutoff date, use the local Linux users group as a resource to help the procrastinators and newbies meet the minimum compliance standards which will allow access to the network.
Good luck in cleaning up the mess....Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
In this model, publicly accessible hosts are considered "expendable", and their contents are recreated regularly through the firewall.
It doesn't address the issue of how to secure residential networks, unfortunately.
Just fyi - there is a fascinating set of posts from RISKS (from 1986 no less -- what does this tell you?) about the exact same sort of problem. For some reason completely unbeknownst to me, a transcript of this has lived in /pub on rtfm.mit.edu (exactly at ftp://rtfm.mit.edu/pub/reid.txt) for the past 13 years. Their conclusions? Policies will work if you don't have to cross organizational boundaries, but probably won't if you do.
I think the most interesting thing in the thread is the idea that we still lack a strong ethic regarding cracking. While I'd venture that it's better now then it was then - it's interesting to note that most universities (well, at least the one I went to) don't have to have people who go around and make sure that the libraries and offices and labs are locked up tight as a drum.
Creating social ethics that make computer breakins as infrquent as physical breakins are not a short-term solution though.
Read the file if you get a chance -- it's long, but well worth the time.
I think if you have a well thought out Network Policy (ie the 'Acceptable Use' guidelines) and make a good faith effort to get security info to your user community then you can justify bringing out the big guns to deal with potential problems...if you control the switches and routers in your organization then maybe think about a policy of blocking or turning off ports belonging to systems that fail your basic published security guidelines.
The kicker of course is making a good faith effort at getting timely info out, having a sensible & legible definition of what your security requirements are going to be, etc. Someone needs to decide when something is problematic enough that blocking it from your network is the safest thing to do given the needs of the at large community...this has to be balanced against being too heavy handed.
It sounds like there is going to have to be a policy set. "all systems will comply to the security guidelines outlined at (some URL) or they will not be allowed on the network."
Once you get the guidelines set, implement some detection measures (the easy part as you put it) and some automated notification. after some number of warnings (say 3 in as many weeks) just filter all their packets at the router (based on their MAC address).
Yes, it wouldn't take much to change your MAC address, but then they've intentionally circumvented policy & that, I'm sure, is covered in some other policy, with it's own punishment.
"We are not tolerant people. We prefer drastically effective solutions"
Soooo much agreed....
/etc/sendmail.cf built using the Jussieu Kit, with the most autist anti-spam measures on (even if that means we loose all mail from poorly configured sites, and despite the authors of the Kit publicly saying some of these features are too much and should be withdrawn). No FTP or web serving unless through the server, subject to quotas. etc.).
Here in my Uni (ENS Cachan, France), this is what we're doing : two routers with each its own set of ACLs (yeah, we're wasting a quarter class C for that). One (a small cisco) is owned by the school, one (a four-NIC hack'n'trash Linux box running ipchains) owned by us.
Both implement various security blocks (for instance, NO SMB access whatsoever to the outside world. NFS forbidden as well. SMTP mandatorily goes through the one server, and the MX records set a fascist way in the DNS.
The probable next step now that France left Iraq, China and Iran alone in the club of countries which forbide encryption is probably to lock out POP3, telnet & X access in favour of SSH pipes.
(Oh yeah, none of this is really strong. One can always do a httptunnel on a pipe pseudo-network device -- but that's circumventing the barriers... And these barriers are first here to protect the newbies from accidentally exporting their c:\WINDOWS\TOTO.PWL files).
There's also a tangle of legal documentation (the campus-wide Network Security Charter (NSC) each individual, lab or association has to sign in order to get even a simple login access anywhere on the campus; the dorm subnet NSC each member has to sign ; specific security agreements between the association in charge of the dorm subnet and the uni ; the nationwide Renater NSC, etc.).
Finally, there are quite a few daemons running on the inner router/server, we for instance strictly forbide MAC address changes if not warned in advance (and we do pull the plug for that), etc.
Yes, we have some problems from time to time with people having trouble with reading French and/or not willing to understand the rules, and I believe the guys now in charge are going to see quite a few incidents of the sort per year, but overall, having well-explained legalware signed by everyone (and spending a good deal of pedagogy after the signature, in order to make clear the Charter is not just a piece of paper !), and explaining why some services are blocked, is IMHO quite well working.
University usually = no money (for network maintenance and support.)
Assuming that there is little enthusiasm among the overworked network people that do exist, all that is available to you are simple solutions.
If there isn't already a firewall in place at your university then anyone on the Internet can attack any machine on the LAN. If this is true you've already lost the battle. Stopping users on your LAN from attacking each other is another problem.
Firewall the incoming traffic (assumed to be present.)
Set up ftp and WWW services outside the firewall to allow publishing of data.
Install smart switches (Cisco Catalyst 5000 series, etc.) with port security. (If there's no money then there's no money, but this is just about mandatory today to keep from actually having to visit hubs and yank patch cables for offending parties.)
Lock each port to a MAC address on the NIC. Changing NICs locks down the port and requires a help desk call and explanation as to why you are changing computers/NICs on that port.
Log incidences of NICs being turned on in "promiscuous mode" and lock out those ports for at least a week to prove you mean business.
Publish simple rules about what is not allowed on the network (IP spoofing, MAC spoofing, etc.)
Don't worry about people's out-of-date OS software. Who cares anyway? They're not hurting anyone but themselves. They may need an old OS for some reason. Don't even try to track that sort of thing, it's meaningless for the good of the network - which is all you really should care about. Individuals must learn to take care of themselves. Obviously you can suggest how they can secure their computers, but enforcement is impossible and unnecessary.
In summary:
Firewall incoming traffic
Implement remote port management tools
WWW and ftp services available outside of the firewall
Publish rules
Lock out violators
Let the users manage their own systems any way they choose.
I am sitting in the same admin seat and after having read some of the comments here I got this idea:
... and and and - you will end up being forced to punch a million holes in the firewall, rendering it useless.
With a virtually endless number of systems on the network one cannot ever possibly check each and everyone computer for security problems. It is way too time consuming even for a large IT-staff group and it will probably not be appreciated by people who feel you are sniffing around in their computers.
Firewalls and blocked routers are a nice idea, but Professor A. has a friend who must be able to telnet into box 123 and Professor B wants to
An own distribution is probably a too complex thing to go for. As soon as a distributor will update, some users will do so too. Your own distribution becomes old and you soon run into new problems.
So my idea (just an idea) is to create some kind of "ticket" which allows the users to connect their computer to your network. Assume that you write a program or a set of scripts which run a number of security checks on a computer, presenting the output in a code number, call it the ticket. This ticket is submitted to a server which grants the sending machine access to network - if the ticket shows that all tests were passed.
The idea is to limit your work to writing a - say monthly - version of the security check script. Let the program produce a ticket which is valid for a reasonable time span and place it as a complete, runable package on a public server. This way you will MAKE THE USERS CHECK THEIR OWN COMPUTERS. No valid ticket, no IP-number.
As I said it is a very raw idea, but I think it could work.