UA Home
Machines which are determined to be compromised will be blocked at the closest point possible to the compromised device. Most often, this involves blocking the MAC (hardware/physical) address of the computer's network card, but depending on the circumstances it may involve disabling the port to which machine is connected, blocking the IP address which the machine is using, or even blocking the NAT device (firewalls, routers, wireless access points, etc) which the compromised machine is located behind. Under extreme circumstances, there may be other blocking mechanisms used as well, such as disconnecting a floor, VLAN, or building in the case of very severe virus outbreaks, but MAC address blocking is the default blocking mechanism.
According to the University Information Security Policy, devices or networks of devices are subject to service disconnection by the designee(s) of the University Information Security Officer if such devices:
1. pose a security threat to the network
2. significantly impact the functionality of the network in a negative manner
3. violate Federal, State or University Policy
When a machine is blocked by MAC address, an automated email regarding the block and its reason is sent to the registered primary network managers of the IP address which the blocked machine had been using. Due to resource constraints, this is the only default notification.
A 'critical systems' list is compiled by SecOps, with more details below. If the MAC address of the device to be blocked appears in our critical systems list (previously also known as an 'exclusion' or 'do not block' list), SecOps will call whichever phone number(s) were provided along with the 'critical systems' request, as well as the phone numbers listed for the primary network managers as they appear in the Network Manager's Database before blocking the system. Due to the need to secure the rest of the campus, MAC addresses on the 'critical systems' list may still be blocked depending on the assessed risk and potential for collateral damage. Please note that if you have systems that cannot be blocked due to life safety issues, you must inform us of this!
Properly authorized network managers may request that they be contacted by phone before certain systems are blocked. To add a system to the "GotBlocked Exclude Systems List", go to the GotBlocked? web interface, click on the 'Add an excluded system' button, and fill out the form.
Two items to note:
1. Despite the name, being registered on this list does *not* prevent the system from being blocked depending on the situation, although we will make every reasonable effort to reach the system's listed contacts before a block occurs. A system which is actively malicious and attempting to compromise other systems will still be blocked if no contacts can be reached to gracefully remove the system from the network.
The only systems for which a complete exclusion may be requested are ones which will impact life safety if their network connections are terminated -- however, these systems really should be secured to the point where there shouldn't be a reason to need to block them to begin with.
2. This list was formerly known as the 'Critical systems list', but has been renamed to avoid confusion with the Information Security Office's 'Critical Device' registration program.
* First offense: The network manager or appropriate technical contact (ie, OSCR/CNS) may unblock at their discretion. See the guidelines below for when a machine is determined to be safe to be unblocked.
* Second offense within 30 days: The technical contact should contact SecOps and discuss what procedures were used the first time to clean the device before the unblock occurs. Other cleaning options, network/host based defenses, and user training should also be discussed.
* Third offense within 30 days (from the date of the first offense): The technical contact must discuss the situation with SecOps before a third unblock occurs. Other than in extreme circumstances, SecOps will require (as opposed to recommend) a reformat and reinstall of the machine before a third unblock occurs. Preventative measures mentioned above (host/network based defenses and user training) should be re-addressed.
* Incidents beyond the third within thirty days will be addressed on a case-by-case basis.
UA affiliates should have their appropriate primary IT support group remediate their machines -- if you are not sure who to contact, please reference the general information page.
For many types of compromise which result in a block to begin with, we *strongly recommend* that you reformat your machine before unblocking it. This is especially true if the machine was has been sufficiently compromised to allow an attacker to install malware/additional attack tools, since the attacker may also have installed additional backdoors, a keystroke logger, or some other additional malware. Additional backdoors can be potentially something as simple (and non-detectable by anti-virus) as adding an admin account for him/herself, or something more complex such as a bot client which connects out to receive additional commands at a given time. It is often more secure and less time consuming to rebuild the machine than to attempt to find all of the potential backdoors an attacker may have left.
In addition to rebuilding, it would be a good idea to not reuse any passwords which had been used on the compromised machine, since the attacker may have retrieved the password database (shadow file in Linux, or SAM database in Windows) to crack additional passwords on the machine offline. Warning other people that use the compromised machine to change their passwords if they use the same username/password combination on multiple systems would also be a good idea.
With regards to rebuilding and recovering from compromises, here are what some other institutions have to say on the matter:
* Carnegie Mellon CERT [http://www.cert.org/tech_tips/win-UNIX-system_compromise.html#E]
* MIT [http://web.mit.edu/ist/topics/security/restoring.html#3]
* University of Pennsylvania [http://www.upenn.edu/computing/security/root_compromise.html]
US CERT has a page of tech tips for what to do immediately after rebuilding your computer.
If you absolutely cannot rebuild the machine and this is a 'first time block', you should read our section on compromise detection after removing the malware that caused the block to begin with before unblocking the system. Please note that this does *not* guarantee that your machine is clean!
Before unblocking the system, be sure to consider what vector might have allowed the compromise the first time around -- did OS patching fail, was there an application which was vulnerable, was there host-based security software that was missing on the machine (ie, up-to-date AV, firewall), did a user have a weak password, was there human error that requires more security training (ie, not clicking on email attachments or downloading suspicious software)? There are many failure points which can lead to a compromised system, and repeat customers are not preferred customers when it comes to compromised systems.
To unblock a system, you may use the GotBlocked? web interface.
SecOps has a number of guidelines and suggestions for improving your network and host-based security. The best place to start for SecOps's suggestions is at the guidelines page and also the page describing services offered to network managers.
If you detect a compromised machine, please reference the reporting page for more information on how to report an incident.
