Version 0.1
Erick Engelke, Engineering Computing
There are always risks when a computer is connected to the campus
networks. System administrators are particularly
concerned with security on that machine, whereas the network administrators are
presumably more concerned with the threats that machine poses to networks and
other devices. In reality, we are
concerned with both, but we do not always have enough influence on the
management of the machine to protect its own interests.
IT people often identify computers as “managed” versus “client managed”
a.k.a. “unmanaged”.
Computers which receive security and other updates through managed
systems (like ADS and Nexus) tend to present few security problems because they
are professionally maintained. It takes
effort, but someone is paid to do it.
Client managed computers are rarely maintained with such vigilance, and
statistics confirm the higher degree of vulnerabilities and subsequent malware infection on these machines.
Client managed computers exist throughout the university.
-
Wireless and wired laptops have a growing presence,
particularly as former limitations (battery life, weight, wireless connectivity
and laptop performance) improve every few months.
-
Residence computers are wired into our network too.
-
Many faculty and staff maintain their own computers with a
permanent presence on our wired subnets.
Historically, all three groups are been treated differently, even
though they present similar security risks.
Some typical security challenges are listed as follows:
|
Challenge |
Wireless |
Residence |
Workstations |
|
authentication - limit network
access to only trusted users. |
NAA |
MAC address locking |
Some MAC address locking, not everywhere |
|
bandwidth
auditing/management (2) – to
prevent users from overloading campus external links unnecessarily. Requires (1) above so that we can track
overuse and notify/threaten individual users. |
NAA with Toilet Tank Traffic Shaper |
Router features (see url below) |
None |
|
vulnerability and malware issues (3) – vulnerable systems tend
to breed malware which then consume large quantities
of bandwidth (see 2 above), and threaten to attack other campus devices (4). |
Snort packet watching Vulnerability scans |
||
|
user data security (4) – does using the
wireless network expose users’ plaintext passwords or other personal
data? Do the vulnerabilities in (3)
reduce the reliability or privacy of everyone’s stored data? |
N/A today VPN in future? |
Switched network reduces exposure of plaintext. A good firewall will help too. |
|
Full details
on the Residence network can be found at http://ist.uwaterloo.ca/cn/Residence/directions.html
The focus of this paper is the vulnerability and malware
aspect of our plan. The other areas are
mentioned only to assure the reader that this is but one component of a more
complete effort, and to show how it ties in with other efforts.
Initially I was concerned only with laptops, but the other two groups
may also benefit.
Our current strategy is to authenticate the client user, then provide unrestricted access and some traffic
auditing/management using Network Authentication Appliances or Cisco
switch/router features.
At the date this was originally written, we did not automatically take
active steps preventing clients from connecting if they might have
vulnerabilities or viruses. In fact, we
have no way of directly determining that information with certainty.
IST staff enlist technology which passively monitors
network traffic for suspected malware
signatures. Also, they occasionally do
active scans testing for responses containing signatures of known
vulnerabilities.
The results from these data collection techniques are converted into
automated warnings which are then issued to users and their IT staff. Approximately 50 Email warnings are issued
each day, all based on the statistics collected during that day.
While these signature-based
methods have been helpful, they have limitations. They are insufficient to detect every
vulnerability or compromise, they detect the problem after it is a problem, and they can also return false
positives.
Certainly warnings can be
issued, but it is probably best that a human review the results before
users/computers are banished from the network.
Unfortunately, the easiest way to reduce false positives is to choose
only the most conservative rules, but doing so also reduces our ability to
detect problems.
Identifying and fixing machines (it’s best to totally reinstall after a
compromise) is quite labour
intensive, certainly more than if the user had taken preventative
maintenance. Not only is this a support
burden for the client, IT staff are often forced to help. As laptops dramatically increase in number, this
strategy does not scale with present budgets.
In a nutshell, the current system is: trust all computers believed to be run by uw people, but only until we have
sufficient proof that the machine is a threat to the campus, then banish the
computer until someone can fix it and verify it is managed up to our standards.
The proposal in this paper is to change the normal rules by adding an
entrance test when the user connects to the NAA.
Suppose the user is initially allowed to connect with only minimal
functionality… essentially http access.
Then the machine is tested for meeting our minimal standards or forced
to upgrade to these standards before it can be a full participant in the
network. Computer users unable or
unwilling to meet these standards are simply not granted the additional access.
HTTP is all that is required for updates of the Microsoft OS and
Symantec antivirus and antispyware software.
A clear advantage of this strategy is that it encourages (with a heavy
hand) users to meet or exceed our minimum standards by using preventative
maintenance.
Such an entrance test will eventually become standard fare. Currently there are several small IT
companies with shipping products, and the heavyweights like Microsoft, Cisco
and Symantec have competing visions of integration with their products. But there will have to be some casualties
before a standard method is available, in the mean time, we can use our own
tests.
We can rely on proven technology available from the Nexus environment. The clients would not have to be running
Nexus, but some code used in Nexus would be added to the client computers.
Like other implementations, we require an agent (a small program) to be run on the client
computer. Some vendors claim their agent
is Java based and thus OS-agnostic and “safe”.
What they fail to tell you is that their agent requires a DLL or similar
download. Furthermore, that DLL is then
accessible by other Java programs, meaning malware
Java would then have the system access granted by the DLL.
Our agent is used to verify three things:
-
the OS is kept up-to-date with patches
-
antivirus (and antispyware) is
installed and updated
-
firewall rules are installed
These three factors are not a panacea, but they would greatly security
risks and future problems by encouraging best practices.
January 31, 2006
The functionality described above has now been completed and work is
now underway to integrate this technology with the NAA for production purposes.
The solution has two parts:
The user run agent is called MinUWet, and has
only been implemented for Windows – because that is the OS present on the vast
majority of our problematic clients.
The program is digitally signed by the
If necessary, MinUW can force an update using
the antivirus tool (currently only Symantec), or the WSUS tool.
The tool informs the user of the information being transferred, and we
have control of the source code, so we can verify that no additional
information is kept.
Information sent to the server uses cryptographic hashing to reduce the
threat of bogus replies. This will not
guarantee against false information, but our current problems are mostly
individuals who under-manage their systems, not hackers clever enough to break
modern cryptography or disassemble complicated programs.
A demo version is accessible on the web. If you connect from a non-windows computer,
you are granted immediate success. But
Windows computers are given a web page and a program to run before premium
network access will be granted.
http://www.eng.uwaterloo.ca/~erick/minuwet/classify.php
Last updated:
January 31, 2006
Erick Engelke