This article can also be found in the Premium Editorial Download "Information Security magazine: How to stop data leakage."
Download it now to read this article plus other related content.
| Discovering an SSH Compromise | ||||||
Requires Free Membership to View
|
NetFlow data exposed a server cluster compromise by revealing a high volume of port 22 (SSH) traffic from foreign IP addresses instead of the from authorized administrators. In this example attackers used the servers to create a rogue IRC network. (IP addresses and DNS names are removed to protect the compromised organization.)
|
||||||
Porous firewall: An investigation of multicast traffic showing up in firewall logs for a cluster of servers reveals something the logs did not--unauthorized traffic passing through. Analysis of the IP addresses shows several unknown European and U.S. addresses--none of them the Canadian support group that administers the server cluster using SSH through the firewall.
In this example, SSH had been compromised (see "Discovering an SSH Compromise," right), and further port analysis reveals the servers had been set up as IRC servers; they had connected to several other servers in different parts of the world, none of which matched authorized IPs. The traffic showed that the compromised cluster was being used to crack other servers, expanding the underground IRC network.
The IRC services were eliminated, SSH passwords were changed, patches applied and tighter firewall policies (in particular, egress filtering) were implemented. Follow-up analysis shows an unsuccessful effort to repeat the attack.
Tales out of school: Schools have an ongoing struggle with support issues on many fronts. In the course of sorting flows by a port used by a current threat, analysis of traffic from a high school reveals a multitude of problems: significant flows outward on that port, unsanctioned peer-to-peer file sharing, and suspicious conversations between Chinese IP addresses and the school's database server.
This was first published in January 2006
Security Management Strategies for the CIO
Join the conversationComment
Share
Comments
Results
Contribute to the conversation