Denial of Service Attack, Coursework Example

Case Background

The main registration database of the university in the case being observed is expected to take on the role of a centralized information management system that allows the administration to be more effective especially when it comes to mandating and monitoring the data that provides a better understanding on how the institution is able to perform in the field of providing necessary education to the public targeted by the organization. Having a centralized database basically allows the administrators to be able to establish plans that would define the way they are going to deal with the new height of enrollees they ought to serve during the entrant of every school year.

The system, as centralized as it is, functions fully as the source of competent procedure of information management for the university especially when it comes to dealing with student data and how they are supposed to be served by the organization with full sufficiency. However, with a distinct anomalous act from a user, the overall system falls down. The experience of DDoS in the university’s main data management system causes the overall registration procedure to crash off.

Based from the case, the attacker came from an internal connection within the network served by the data center service operations of the university. As seen from the diagram, the hacker [attacker] basically knows the authorized entry points and had the chance to access the full system through the command control system. From the said point, the hacker then tried to affect the separate network branches first before actually attacking the main data infrastructure. The fact that there was distinct HTTP requests all throughout the system marks the fact that the entire inner-infrastructure of the system has already been compromised. The university data-management system was compromised especially because of the fact that it has been established to stand at centralized option; its operations have been protected by a single pattern of networked sharing that was easier to counter flow with scrupulous information making the whole system unavailable for 24 hours. Noticeably, another problem to note is the fact that the files that were kept in the system were not fully backed up; one matter that makes the rebooting and rerunning of the system quite harder to accomplish; data recovery is then necessary.

Recommendations: Preventive Measures and Counter Response

Reestablishing privacy and the integrity of the system from scratch may not be an easy process to take into account. It could be realized that with the current status of the operation [and the indication of how the system ought to operate for the university], the need to resolve the problem is an immediate requirement to take into account.

Internal Firewalling:

As mentioned in the detail of the case-scenario description, the firewall from the external options of operation has already been fully established; however, the internal operations have not been fully protected yet. Perhaps the idea of trust on internal operators established the fact that the concept of responding to such conditions of jeopardizing the system did not fully come into terms among the administrators until the situation actually occurred.

Reboot and Restart:

Hence, to look through the system, it is important to reboot the entire operation. This means that the data-recovery operation should be the primary consideration. Once the data [as much as possible] has already been retrieved, rebooting the entire system would be the best next step. Considering that there is still an anomaly in the operation, the need to undergo a trial process in which the whole system should be retested for accuracy and integrity is a necessary move on the part of filtering the components of the system again.

IP Filtering

Bogus IP filtering could help in the process of identifying the culprit or at least the main source of the anomaly. This approach shall be undergone through running the entire system while a detection program is run along with it. This will allow the examination of the entire system to occur accordingly. Inspection through active WAN links could also be used to make sure that the bogus HTTP requests could be immediately identified accordingly. Once the source of the anomaly is detected, the realignment of the systems operation could be undergone.

As the system is being rerun, the need to make sure that it is protected from future DDoS attacks is necessary. Establishing internal firewalls and internal switches are expected to make detection for information flooding that might compromise the integrity of the information management operation easier to consider. Noticeably, it is with this particular hope of reestablishing the capacity of the system to operate within a full range of protection that the capacity of the system to host a new set of information in par with what has been recovered and how they are going to be managed to be able to fit the full potential of the university to function for the target school year.

Regular deep packet inspections could also be adapted later on as part of the maintenance operations dedicated to keep the integrity of the system in functioning for the expected responsibility it is supposed to respond to. Delayed binding of information as part of the maintenance process should also be imposed every now and again, especially before the peak time of using the system occurs. This means that regular checking of the system’s integral networks should be fully embraced as part of the need of the administration to establish good management of operations making it easier for the entire system to remain intact amidst massive information flow during enrollment periods.

References

Ethan Zuckerman, Hal Roberts, Ryan McGrady, Jillian York, John Palfrey (December 2011). “Distributed Denial of Service Attacks Against Independent Media and Human Rights Sites”. The Berkman Center for Internet & Society at Harvard University.

TaghaviZargar, Saman (November 2013). “A Survey of Defense Mechanisms Against Distributed Denial of Service (DDoS) Flooding Attacks” 15 (4). IEEE Communications Surveys & Tutorials. pp. 2046–2069