By David Markey
Security; I feel this is one portion of computer networking that is often overlooked by other IT companies in the city of Worcester; However, this is undoubtedly one of the most important things we consider at AVATAR Computing. That is, protecting your network from outside intrusion (AKA Hackers) on the Wild Wild Web. Client Data, Employee Data, and Company Data are your responsibility to protect as a IT / Security Professional, but are firewalls the only answer? Do they constitute the last line of defense? Let’s take a closer look:
Today I was alerted about an unusual amount of failed login attempts on a new client’s server. I remoted in and took a dive into the wonderful world of Event Viewer logs. Over 33,000 failed login attempts over a 2-day period. Let’s break down the details in the log file. These can be used to identify an attack versus an internal application or computer.
The first thing is the frequency of user account. Attackers will often try a dictionary brute force attack and this can easily be identified by looking through similar log files. Look to see what user names are failing, and bounce those names off your domain users listed. In this case, each record was attempting a different account name, none of which were part of the client’s domain.
Log files are your best friend, and understanding the language they speak will be invaluable to you for detecting abnormalities. Let’s break down some of the information we are given above. Receiving NULL SID on the subject line tells us a few things, likely the user is not on a windows distribution; and that the server could not identify the PCs SID (unique identifier). No account name or domain was reported, and the logon ID of 0x0, tells us that no account information is present. Seems a little bleak, however, the next line is our golden chorus; Logon Type – “3”. This narrows down the failure to a network attempted logon, i.e. RDP, SSH etc. Now as I scrolled through and read these logs, each “Account Name:” would change; I saw everything from “Scans” to “Test1” to “Administrator” with multiple attempts under Administrator (likely due to this being a default account).
So, what do we do about it once we’ve identified a brute force attack? Well the next step is to see where it is coming from, a good IDS (intrusion detection software) will come with tools that will allow you to differentiate RDP traffic from SSL traffic, and so on, to isolate the leak. In this case I used the open source Cyberarms IDS and turned all the agent filters on to see which tripped. Bazinga!
As you can see, out of all the filters, the TLS/SSL filter was the one to trip, these results are over about 6 hours, each soft lock thwarting attempts from specific IP addresses for 60 minutes. Now that we have narrowed down the area the attacks are coming from, we can appropriately compile a response. Whether that is patch updates, shutting off ports that aren’t being actively used by client services, etc., you can work these angles until the attacks cease. In this case, we shutoff older versions of TLS and ran updates, which solved our problem.
Remember these attacks ALL made it past the firewall. So, to sum up; your firewall is not the end all be all for security. Invest in good IDS systems and even better yet, GOOD I.T. STAFF, that will prevent your data from leaking to outside attackers. IDS systems should just be part of your solution. Your I.T. staff will need to configure them, know how to read event logs, setup console notifications, and inspect network packets. Diligence is your companies responsibility, remember there will always be someone trying to break in your front door, the question is, how strong are the locks?