bill’s blog

Another wonderful malware day… Well not exactly, but a beautifully executed social engineering attack! Today a lot of my users called to say that they were getting emails from friends asking them to join tagged. A classic phishing attack and I can’t tell you how many people fell for it! In this case it wasn’t as bad as some of the ones asking for bank PINS & passwords but it’s another example of people not using common sense! Now I can’t say for certain what information they asked for but one should never give any person information.

The information age has made the exchange of data common place. Many of the things like our social security number and mother’s maiden name are so freely available that credit card companies already know the answers before you ever speak with them.

http://www.consumerfraudreporting.org/phishing_Tagged_dot_com.php

It seems that this particular scam has been circulating since 2007. SO my big question is why did it get past DefenderSoft? So for all you network admins out there the lesson learned is there is a big difference between companies that offer SPAM protection.

Password enumeration while not related to phishing should be mentioned.

A couple of things to keep in mind is never just click and email link and expect that is brings you to the site that is advertised in the email. When signing up at legitimate social networking sites be careful of allowing them access to your address book.

Luckily for me… a lot of the emails came from other employees so they were able to verify that the email was a scam.

Wow where does one start?

I guess the easiest way to look at it is; the Internet is no longer the safe place it was during its academic infancy! It has grown outside of its humble beginnings and has grown to mimic the world it services! Unfortunately, as we all know the world is not a safe place. The world has become a smaller place because of the Internet. One can shop the furniture stores of Asia while sitting in their New England homes. This does pose a risk! It used to be that you knew which neighborhoods to avoid. There are bad guys on the Internet that will prey on the unsuspecting. The Internet insulates us but also provides for a certain amount of anonymity for the bad guys. Jurisdiction plays a big part in this. Bad guys can’t always be brought to justice for the crimes they commit.

Common sense tells us to protect ourselves. We start small. We purchase anti-virus/malware applications to protect our computers. We patch our machines. We place our computers behind firewalls. We set up proxies to keep us off of “bad” websites. We set up spam filters to cut down on phishing attacks. BUT like anything else, the more we protect, the more we need to protect. The bad guys are always seeking ways to have at your computers.

One thing to keep in mind is that, network security monitoring isn’t about going out, researching the latest hip application and deploying it on your network. That’s not to say that these devices don’t work… They do but deploying a device and then trusting it to notify you is a bad thing. It leads to compliancy. On the other side of the token, false positives will lead to compliancy as well (even more so).

So what are we to do?

The first thing one must realize is that without knowing your baseline, one can never tell when something is wrong except when things stop and then it’s too late. One must understand the rules that go into what triggers an alarm. We need to look at normal traffic and then suspicious traffic. Setting up Wireshark and committing someone to watch all the traffic that enters our networks is not something pleasant to do nor do we always have the time to do this! This is where network-monitoring solutions come into play. One must understand the types of traffic that pass through our firewalls, understanding the differences between TCP traffic and UDP traffic (all traffic really). TCP traffic is connection-based conversations and the acknowledgement of packets is key. This makes it easy to ’see’ where ‘things’ break. UDP traffic is connectionless based traffic and as such not seeing an acknowledgement doesn’t mean the conversation is broken. We need to put aside our pre‐conceived notion of what the traffic should look like. It is only then that we can understand the rules that trigger alarms on our monitoring devices. This is where capturing (and archiving) data comes into play. Session data represents traffic that is passed between 2 hosts. There are 2 different forms of session data: Full Content, which collects everything (the entire packet). This is most accurate assuming that all packets are captured. And Session First, which records the “conversations” that are taking place on an entire network link. The collection device must be able to see as much (all) data that travels across the monitored link. This is a great way to see all the conversations that are happening. Unfortunately, this method is somewhat compromised in that it is not collecting all the packets contents make the reconstruction of the ones and zeros (What was actually ‘said’?) that passed between the two hosts impossible. This is often deployed where server space is a consideration. Ultimately…

You can never have too much data ready for analysis once you’ve found your enterprise to be compromised.
- Richard Bejtlich, senior forensic consultant, Foundstone (techtarget.com, 2002)

So now what?

We have to understand risk. What is you pain threshold? Monitoring and entire network in a class C subnet is one thing and even that can get out of hand depending on the types of services that are provide. We have to understand the threat and where it’s coming from. Security through obscurity work for a little while BUT it will not keep your network out of harms way. My own network at home is scanned many times during the course of the day. It’s not like I’m doing any kind to e-commerce of have trade secrets that will make anyone rich… but if a machine on my network can be compromised then an attacker could use it to stage bigger events against more high profile targets. CPU cycles and bandwidth aren’t cheap. Why share it with the bad guys! BUT more importantly realize that if you don’t protect your network and machines… you’re just as responsible for helping the bad guys. One must realize that it’s not a question of if… it’s a question of when. Once you’re comfortable with the threats to your network and can then decide your comfort level with the risks!

Network Security Monitoring (NSM) affords you the opportunity to understand something abnormal is going on within your sphere of influence! It will not protect your network. That is the job of many other devices (firewalls, proxies, software update servers, etc.). You want to know when someone might be looking at your network in a non–ethical way! Hopefully you’re devices are set up in such a way to help you understand the level of threat involved. Is the threat a structured attack or is it merely script-kiddies knocking at doors? This is where the art of network monitoring comes into play. Tuning your NSM system to reduce the amounts of false positives is important. Knowing that your systems are fully patched against a Back Orifice attack means that you don’t have to alert your entire CIRT (Computer Incident Response Team) in the middle of the night. However, if your NSM sets off an alert about multiple SSH login failures from an IP address in the Ukraine (ruling out that damn scientist in Alaska who always forgets his login), well it’s time to wake up the boys!

Next steps?

OK now that we know something fishy is going on, what do we do with this information? Well assuming that the alarm has been validated… You did make sure it’s real? The alarm needs to be categorized. Now many NSM solutions will do this on the fly. The Sguil Project adopted the following seven categories (Bejtlich, 2005):

1. Unauthorized Root/Admin Access
2. Unauthorized User Access
3. Attempted Unauthorized Access
4. Successful Denial-of-Service Attack
5. Poor Security Practice or Policy Violation
6. Reconnaissance/Probe/Scans
7. Virus Infection

Other systems may use slightly different categories but these spell out the reasons for network security monitoring in the first place. The first three categories are really the same thing (unauthorized access) however, what separates them is the permissions/privileges associated with the user the attacker would gain should they succeed. If they gain root access, well that’s game over. Next is the Denial-of-Service Attack, we don’t put computers out on the network/Internet for no reason. We put it there so that others can gain authorized access to the resources the host provides. Preventing legitimate users from gaining access is of utmost concern. Poor Security Practice is poor administration. Providing any information to a would be attacker is shameful! Make sure you do the research into how to make service more secure. Not configuring the services that you are running on your network with security in mind is only asking for problems. Reconnaissance/Probe/Scans are a part of everyday life. Understanding patterns is the key here. If you’re constantly being port scanned from the same IP address… that’s not normal investigate what’s happening! Lastly, Virus infection to a greater degree is preventable. Zero-day vulnerabilities happen but not being up to date on virus definitions is problematic. Infections happen. Understanding the flow of traffic is important (is the virus coming from off our network OR is it already on our network).

Have a plan!

OK we’re in a better place. We understand what’s going on with our network. We understand the attack vector. We may even know who’s attacking us! What next? Having a response plan in place is extremely important. Not knowing what to do with a critical server in a time of attack can make all the difference. Should we power down the device? Maybe it depends on the attack. Should we remove the host from the network? Probably! Do you have a back up plan? Is it a clustered device? Has the other boxes in the cluster been compromised? Are we under attack or have we already been compromised? Are there any regulatory requirements? After 9/11 the Federal Reserve and the Securities and Exchange Commission pushed for a two-hour recovery time for financial services companies. MasterCard which processes nearly a trillion dollars annually, needed to make some changes. Beneath the quiet hillside (in St. Louis), there’s a telecom system fit for a metropolis. Southwestern Bell has installed SONET rings and multiple OC-12 links for redundancy (networkworld.com, 2002). Filtering an IP addresses or subnets is a temporary solution but can be easily performed. Do we have a disaster recovery plan? A disaster could be a catastrophic event such as 9/11 or it could simply be a compromised host. Knowing what to do is the whole point of drilling for an event. AND that should be part of your plan!

Lastly, and while not a monitoring tool is end-user awareness. Attacks can take all forms, and many an attack starts without the use of a computer. Making people aware of security, its meaning to the organization is important and should be overlooked!

“The methods that will most effectively minimize the ability of intruders to compromise information security are comprehensive user training and education. Enacting policies and procedures simply won’t suffice.”
-Kevin Mitnick

Things will go wrong, it’s how they are handled that will keep you in a job and your organization safe!

Resources:

Bejtlich, R., (2005), Tao of Network Security Monitoring: Beyond Intrusion Detection, Addison-Wesley Professional:New York, pp 372-374.

Ferraro, C., (), Network security monitoring is more than IDS, Retrieved on June 6, 2009 from http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci870026,00.html

Messmer, E., (2002, December 12), MasterCard factors 9/11 into disaster-recovery plan, Retrieved on June 6, 2009 from http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/export/home/httpd/htdocs/news/2002/1202mastercard.html&pagename=/news/2002/1202mastercard.html&pageurl=http://www.networkworld.com/news/2002/1202mastercard.html&site=lanwan

Security in not about relying on a single process to protect assets! A belts AND suspenders approach is the best way to minimize the risk of compromise. Access control list are only a small part of the equation! They relate to who will have access to a particular resource once they have been authenticated. The key here is ACLs support known users to the system NOT unknown users. Network security is a cat and mouse game. The smarter you get at protecting your assets; the hacker will always be one step away! As long as computers are accessible from the Internet they will always be at risk. Many vendors will tell you their product does it all! BUT in reality they don’t and they often fail miserably. Those companies that speak in terms parts to a security plan understand that a layered approach to computer security increases your chances at successfully defending your resources! SO what are these different layers and how are the applied?

First there are firewalls. Firewalls are designed to block unauthorized access while permitting outward communication (wikipedia.org, 2009). They sit on the perimeter of your network and the Internet. They control which packets are allowed to pass through to internal resources. Firewalls have a default set of attack signatures whereby they can tell when they are under attacked based on the type and frequency of the packets they “see”. Additionally, network administrators can programmed the device to apply complex rule sets that will determine if the traffic is legitimate or not! These rules bases can be set to allow or deny packets based on the port, source IP address, destination of the traffic, time of day, and contents of the packet. Firewalls can also be deployed within a network infrastructure to protect resources with higher protection needs such as medical information or financial records. They can be deployed on hosts within a secured network in keeping with the belts and suspenders approach… protect the network…protect the host!

Network Access Controls discover and evaluates endpoint compliance status, provisions the appropriate network access, provides remediation capabilities, if needed, and continually monitors endpoints for changes in compliance status (symantec.com, 2008). In other words, any device that connects into your network it is checked to make sure that it conforms to your minimum requirements before it will be allowed to use your protected resources. We (as network administrators) can take measures that minimize who can use our network by making sure that unused wall jacks are not connect to the network or using MAC address to filter to determine who can get an IP address but this will not stop an determined threat or the casual use of networked PDAs. Network Access Control devices proactively scan your network for new devices and agents are delivered to the device wanting access. The end-user agrees allow the agent to “attach” itself to the client and then when access is no longer needed deletes itself from the host machine. Symantec calls this technology, dissolvable agents!

Never under estimate the value of keeping your machines fully patched. Software Updates can insure that vulnerabilities are closed and cannot be used as an attack vector! Applying patches just to keep current is not always the best thing to do. Very often new bugs can be introduced into an otherwise stable environment. Understanding what services a system is offering and patching the system that is vulnerable. There’s no need to patch the httpd daemon if you’re not running/installed web services. Change management plans are a big part of this scenario!

Access Control Lists (or ACLs) is a permission-based method for securing resources (very often is relates to objects on a file system or in a database). In an ACL-based security model, when a subject requests to perform an operation on an object, the system first checks the list for an applicable entry in order to decide whether to proceed with the operation (wikipedia.org, 2009). ACLs allows for greater control over the access to files. In the standard POSIX model, there are owner, group and other permissions, each having read, write and execute attributes assigned to them… very restrictive especially considering that only one user and one group can be assigned to the file/directory. With ACLs, the options are much more varied! You can have multiple owners and multiple groups assigned to a file/directory. In addition, you have the following permissions attributes:

Figure 1. Available ACLs permissions attributes for OSX Server v10.5 (Heese, 2009)

NOTE: You can specify not only ALLOW permissons but also DENY permissions!
One thing to keep in mind when deploying ACLs is that not all file systems support them. Formatting your hard disk, writing data to disk and then discovering an un-supported file system can lead to a lot of wasted time!

Virus Protection is an overlooked aspect of file security. Very often people think in terms of protecting my computer. But it is more than that. Viruses can erase files but Trojans can allow others to gain access to your computer (whether it’s a personal computer or a file server). Critical data such as credit card numbers are often stored in databases and once a computer has been compromised, it’s only a matter of time before the data housed on that computer is lost. One thing to keep in mind when working on a server is never to browse the Internet (especially with root privileges). Much of the malware spread across the Internet takes advantage of vulnerabilities within certain OSs and browsers. Why take the risk. Yes it’s a pain in the bottom but think of all the hassles you’ll have to deal with should you host become compromised. To illustrate the point a little further, it has been recently reported that ATMs are being compromised by some very sophisticated pieces of malware. Now granted the ATMs themselves are being compromised but rather hardware security modules (or HSM) that encrypt and decrypt your PIN as it makes its way from the ATM to the bank clearinghouses are. Specially configured malware can be installed on these devices, and it grabs the decrypted PIN numbers out of memory and writes them to a log file that can be retrieved at a later date (Anderson, 2009).

The last item I want to touch on is log files and while not a security mechanism, it is something worthy of protecting. We often don’t put much thought into log files until there is a problem. Unfortunately, if your log files reside on the same host that’s been compromised, then you should consider that the log files have been altered. Why alter a log file? While many daemons will spit lots of information to syslog so will attempts (or more importantly FAILED attempts) to access a host be recorded. When an attacker is trying to compromise your system, one of the first things he will probably do is completely erase the log files, or erase evidence of his trespass out of those files. Moving you log files off of a host and onto a dedicated syslog server insure that you access can be properly evaluated without the fear that they may have been compromised.

Ultimately, security is NOT about set and forget. You must take an active role! It is not about one size fits all! One single solution will prevent you host from compromise! If you machine is out on the Internet long enough, it will get compromised. That’s not to say that the bad guys are looking for you. Remember we are dealing with computers. The bad guys let the computer work for them. Throwing as many obstacles in the path of the cracker will discourage only the most determined of individuals.

Resources:

Anderson, N., (2009, April 15), PIN-grabbing malware compromises bank networks, Retrieved on May 11th, 2009 from http://arstechnica.com/tech-policy/news/2009/04/pin-grabbing-malware-compromises-bank-networks.ars

Heese, B., (2009, May 11), Available ACLs permissions attributes for OSX Server v10.5

Unknown, (2008, December), Symantec™ Network Access Control, Retrieved on May4th 2009 from http://eval.symantec.com/mktginfo/enterprise/fact_sheets/b-datasheet_network_access_control_12-2008_12836809-3.en-us.pdf

Unknown, (2009), Main: Syslog Security Tip, Retrieved on May 11th, 2009 from http://www.syslog.org/wiki/Main/SyslogSecurityTip

Various, (2009, April 24), Access control list, Retrieved on May 6th, 2009 from http://en.wikipedia.org/wiki/Access_control_list

Various, (2009, May 4), Firewall, Retrieved on May 4th, 2009 from http://en.wikipedia.org/wiki/Firewall_(networking)