Category Archives: Failures

Sendmail upgraded

Posted on by

The University mail server was upgraded from Sendmail version 8.12.9-20030924 to version 8.12.10. This was done as a more proactive step to maintain better version levels. The previous version was patched to address a OOB issue which was a temporary fix. The daemon and configuration files have been upgrade to the current release level of 8.12.10.

Resnet DHCP Server Problem Resolved

Posted on by

A number of people in Resnet, mostly centered in the Langlow subnet, but not restricted to that area, had been reporting receiving invalid IP addresses, even though they had successfully registered their machines. The dhcpd.conf file had valid bootp entries for these machines as well. An astute student gave us a crucial piece of information – students that had registered after a certain time (unclear, but probably last week) were having the problem, while students resgistered before that time were working properly. This led me to believe that the dhcpd daemon was not running with the current version of its .conf file, and that a restart of the daemon would resolve the problem. When we attempted to restart the dhcpd process, it was found that the restart_dhcpd perl script was not running, whihc would explain the problem. Upon restarting the dhcpd, the problem was resolved.

Best Alarm and Video Systems Restored

Posted on by

Measures taken against the Nachi worm, namely the blocking of TCP ports 135 and 139, caused the Best Lock and Video monitoring systems to fail. Apparently, theses systems use these ports to communicate with the Lenel Communication Server Process.

The blocks were lifted and the Communication Server was restarted, which restored the connection.

More Wormy Stories

Posted on by

The University’s network, and particularly the ResNet, continues to suffer from random Blaster worm attacks. Network traffic slowed to a crawl about 11 AM this morning when a number of ResNet computers started looking for other vulnerable machines to infect. OIS personnel had to shutdown all the ResNet subnets to mitigate the load. ResNet personnel are in the process of visiting the infected computers to apply patches and clean the machines. The subnets will come back up when the infected machines are cleaned.

We want to remind everyone in ResNet that it is mandatory that all Windows computers attached to the University’s network must up-to-date with Microsoft critical updates. In addition, current anti-virus software must be running on all computers.

Call the Help Desk at x8585 for help or questions.

As the Worm Turns

Posted on by

The University experienced a major attack of the Blaster worm and its varients starting late last Monday evening, August 18th. The Blaster worm spreads by exploiting security weaknesses in Windows 2000 and XP operating systems. The worm generates high volumes of traffic looking for new targets on and off the campus. This traffic caused our network to essentially shut down.

OIS shutdown the internet connection early Tuesday morning and spnt most of Tuesday reconfiguring the network. The network was moved to a new Cisco 6509 Core Router and restored to service in the early afternoon. Restrictive Access Control Lists were applied to every building until OIS personnel updated every computer with current security patches and anti-virus software. Network services were more or less back to normal late Friday afternoon, but some problems continue to appear.

OIS is monitoring the situation closely, but everyone can help in this effort. Everyone should ensure that their computer’s anti-virus software is installed and active and Microsoft’s updates are being applied.

Majordomo down

Posted on by

Majordomo is down. Majordomo, the software package used for user discussion lists has failed after working without an error for almost two week on the new mail server. For some unknown reason the software now fails to function properly. We have attempted to upgrade with no success. We have attempted to roll back to the old server, but no luck.

First Blaster, then Nachi Worm Infect Campus Workstations

Posted on by

At 11:00 AM, the campus network was disconnected because of widespread infection of University workstations by the Nachi worm subsequent to an initial infection by the Blaster worm (see http://us.mcafee.com/virusInfo/ for more details). The University’s Windows servers do not appear to have been infected. A byproduct of Nachi infection is a large volume of network traffic, and it was this that apparently overwhelmed the campus network.

OIS employees have eradicated most worm infections in Jones Hall, McIntyre Hall, Wheelock Hall and Security Services, and non-public workstations in Collins Library.

Currently, most University network services are online, with the exception of Windows filesharing. Thus, access to MERLIN2 and ALEXANDRIA is unavailable at this time. We expect it to become available sometime tomorrow morning(Wednesday, 20 August) from the above buildings.