Simple Security Scripts from Simple Commands

For many systems administrators, the task of system security is very daunting and time consuming. I discovered early in my career that even though my work as a systems administrator never seemed to end, I could not neglect the responsibility of system monitoring and security. I started with some of the freeware options, such as Portsentry from Psionic:
http://www.psionic.com/
and Saint from World Wide Digital Security:
http://www.wwdsi.com/
and Sys Admin magazine March 2001:
http://www.sysadminmag.com/articles/2001/0103/0103b/a2.htm

I really like both of these tools, however, I wanted to have more control and flexibility with my system security and notification.

As I sifted through my never-ending supply of logs each day, I thought there must be a better way. I then realized that I was going about this task all wrong. I was neglecting my own knowledge, skill, and expertise in favor of other programs.

Through experience, I found out that when a system is cracked most crackers follow a certain modus operandi. They usually change binaries so their presence and activities are undetected. I also found out that specific files are altered and hidden directories can and usually are created.

I decided to go about the protection and detection of my system in the following ways. Nonetheless, I realize that, much like someone who wishes to enter a building, there is only so much you can do to prevent a cracker from entering your system. If the perpetrator wants on your system bad enough, they will get in. I implemented a four-tier warning program created from simple UNIX commands and anchored by Portsentry.

Tier One
I wanted to be alerted if anyone scanned my inet services or, in other words, to be alerted if someone was “checking the doors” for security holes. As most administrators do, I implemented TCP Wrappers, with a twist. I added the following to my /etc/hosts/deny:

ALL: ALL: spawn ( \
echo -e "\n\
TCP Wrappers\: Connection Refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
Host\: %c\n\
Date\: $(date)\n\
" /bin/mail -s "From tcpd@$(uname -n). %u@%h -> %d."
admin@somewhere.com)

This script will generate an immediate notification to an account of your choice, preferably on a different system. Here’s a detailed explanation of how the script works:

• ALL: — ALL means to deny every and any IP address unless over ruled by the /etc/hosts.allow file.
• spawn — Spawn or create the actual notification.
• echo -e “\n\ — Starts the notification with a new line and then create a heading of “Connection Refused”.
• By — Uses the command uname to identify the system.
• Process — Will identify which process your system is being probed for or by (ftp, portmap, etc.).
• Host — Tries to detect the host the intrusion originates from.
• Date — The date of the attempt and the last line simply emails an account of your choice the notification in the proper format. An example follows:

TCP Wrappers: Connection Refused
By: workstation1.somewhere.com
Process: portmap (pid 321)
Host: xxx.xx.xx.xx
Date: Wed Dec 13 04:51:22 IST 2006

This script provided me with instant notification of any attempts on my system and also a log of this attempt should I need it in the future. When administering a large number of systems or a system that is probed continually, it’s wise to set up an account on a system specifically for handling security issues.

Tier Two
I also wanted to track changes in specific files and binaries using md5cksum or cksum as a fingerprint. You will want to run the script the first time on a system that has never been on a network or that you know has never been tampered with:

#!/bin/sh
/usr/bin/md5sum /etc/passwd > /root/ck_sum.txt
/usr/bin/md5sum /etc/services >> /root/ck_sum.txt
/usr/bin/md5sum /bin/ps >> /root/ck_sum.txt
/usr/bin/md5sum /bin/netstat >> /root/ck_sum.txt
/usr/bin/md5sum /bin/ls >> /root/ck_sum.txt
/usr/bin/md5sum /usr/bin/top >> /root/ck_sum.txt
/usr/bin/md5sum /etc/inetd.conf >> /root/ck_sum.txt
/usr/bin/md5sum /usr/bin/md5sum >> /root/ck_sum.txt
/usr/bin/md5sum /bin/rpm >> /root/ck_sum.txt
/usr/bin/md5sum /bin/ck_sum.scp >> root/ck_sum.txt
echo "Report from someworkstation" > /root/ck_sum.out
/usr/bin/diff /root/ck_sum.txt /root/ck_sum.org >>
/root/ck_sum.out
mail -s "check sum from someworkstation" admin@somewhere.com
< /root/ck_sum.out

The script starts by running md5sum on what I consider my important binaries and files, including the script itself. The output looks like this;

849813023732aef68bb4df674d628f2f /etc/passwd
63a1913bc0d1d39927b40628d6a98ecd /etc/services
6d16efee5baecce7a6db7d1e1a088813 /bin/ps
b7dda3abd9a1429b23fd8687ad3dd551 /bin/netstat
f482ae701e46005a358a01c139f1ae74 /bin/ls
6afa152b929c0ab6ddd0a321254f139f /usr/bin/top
3509dee17211e59dec058e30a50c79e3 /etc/inetd.conf
908162ab85e1e3668a235e223aad7d0e /usr/bin/md5sum
eb3fc42223173db0888cee7aec96f413 /bin/rpm
146fc45ab3af038bf592b271556b7cd5 /bin/ck_sum.scp

The first time I run the script, I save the file as ck_sum.org (for original) and save it on another system, just in case.

The line echo "Report from someworkstation" > /root/ck_sum.out starts the log with a nice heading. I then use the basic UNIX command diff to compare the ck_sum.org to the file I just created, ck_sum.out. I again mail the log to a system used for log checking. If nothing has been altered, the file should only contain:

"Report from someworkstation"

Remember that any administration on the system may cause changes in the files your are checking. For instance, when I add a user, my /etc/passwd file changes. I will then need to recreate ck_sum.scp by re-running my script.

Tier Three

I also wanted to track changes in all files. I realize most of the systems I administer have a relatively small number of users. However, I run this even on the systems that have many users and just omit the home or user directories. I call this script file_check, because I use the script for just that purpose. I again implement basic UNIX commands, this time focusing on the find command (man find).

I actually have two different scripts: the first checks for changes daily, and the second checks weekly. However, you can use any time frame that fits your needs. Here is the script for checking files that were altered in a 24-hour period followed by the breakdown of the script:

#Script to find changes in files on the system
#Omitting the /proc dir
find / -mtime -1 -exec ls -ld {} \; grep -v /proc >
/tmp/1days 2>/dev/null &
# find starting at the root dir "/"
# -mtime is the time the file was last modified
# -1 is the time less than one day of modified time
# -exec ls -ld, execute listing of files in long format and
# also list directories but not content.
# {}
# grep -v /proc omits the /proc dir
# > /tmp/1days pipes the output to this file
# >/dev/null pipes any errors to /dev/null

To use the script for a time period other than a single day, simply change the “-1” to whatever time period you wish. For example, here is my command when I look for changes that have happened in the last week:

find / -mtime -7 -exec ls -ld {} \; grep -v /proc >
/tmp/1days 2>/dev/null &

I use cron to schedule the run time of the script and to email the files to me. Then I check for any files I do not think should have changed in the last day.

In tier three, I also start checking the logs without examining each log individually. I use a script called log-checker, which uses the UNIX command grep, or egrep if you prefer to query logs for keywords (man grep or man egrep). The entire script is only five lines long:

#!/bin/sh
grep refused /var/log/secure > /root/secure.txt
/usr/bin/last >> /root/secure.txt
grep auth /var/log/messages >> /root/secure.txt
mail admin@someworkstation.com < /root/secure.txt

I simply grep for keywords such as “refused”, “auth”, and “connection” in my logs, dumping the output into a file called secure.txt:

/bin/grep refused /var/log/secure > secure.txt
/bin/grep auth /var/log/messages >> secure.txt
/bin/grep connection /var/log/messages >> secure.txt

I also add /usr/bin/last >> secure.txt for good measure to see who has been on the system since the last log. Finally, I have the log emailed to myself, mail admin@somewhere.com <>

Tier Four

In the fourth tier, I installed Portsentry to anchor my entire security logging methodology. I edited portsentry_config.h by uncommenting the line starting with WRAPPER_HOSTS_DENY, and adding the path to the hosts.deny file to enable the use of the program with TCP Wrappers.

Although I like programs like Portsentry, Saint, etc., I appreciate that with a few simple UNIX commands, I can keep a eye on my systems and have several tiers of protection.

THE THREAT POSED BY

PORTABLE STORAGE DEVICES

Strategies and solutions to combat corporate data theft

In a society where the use of portable storage devices is commonplace, the threat that these devices pose to corporations and organizations is often ignored. This white paper examines the nature of the threat that these devices present and the counter-measures that organizations can adopt to eliminate them.

Introduction

In an on-demand society where individuals can easily access portable music players, PDAs, mobile phones and digital cameras, technological innovation has responded to personal needs with the development of electronic devices that include data storage capabilities. There is, however, a downside to this modern-day scenario – the misuse of these devices in a corporate environment can spell disaster to a corporation! The statistics are not encouraging; for instance, the 2005 CSI/FBI survey reports that “theft of proprietary information is up from [US] $168,529 in 2004 to [US] $355,552 in 2005” (Gordon et al., 2005).

2005 CSI/FBI computer crime and security survey

“Theft of proprietary information up from $168,529 in 2004 to $355,552 in 2005.”

Today, corporations who recognize the extent of the data theft problem are enacting security policies that regulate the use of portable storage devices in the corporate environment. But is a security policy alone the best solution to mitigate the risks posed by portable storage devices? And what are the real risks associated with the uncontrolled use of portable storage devices?

The rise of portable storage devices

In the last ten years data storage technology has broken all the barriers that used to bind it to large devices that stored limited amounts of data. These technological breakthroughs have:

Increased data storage and data transfer speeds exponentially
Increased device portability through a substantial reduction in physical device size
Increased device availability by the development of mass-appeal low-cost products
Simplified the connectivity method to computer systems.

A typical example is the Apple iPod released in October 2005. This device can store up to 60 GB of data – as much as the typical corporate workstation’s hard drive. In practice, this translates to millions of proprietary, financial, consumer and otherwise sensitive corporate records!

Transferring data from one computer system to another is nowadays a non-technical, highly efficient, inconspicuous task. This effectively puts corporations in harm’s way, since the misuse of portable storage devices can expose corporate networks to a number of dangerous issues which might have an impact on corporations in a variety of ways.

Why do corporations require protection?

Statistics demonstrate that 98% of all crimes committed against companies in the U.K. had an insider connection (Computer Crime Research Center, 2005). Data theft, legal liabilities, productivity losses and corporate network security breaches are all dangers that corporations have to face if malicious insiders or careless employees misuse portable storage devices at their workplace.

Scotland Yard

“98% of all crimes against companies in the U.K. had an insider connection.”

Data theft

The actual act of stealing corporate data by insiders is quite simple in itself and today software that is easily available for download automates the whole process. Insiders only need to plug in the portable storage device on a corporate workstation and all data, including sensitive data is automatically copied, without any additional user intervention. This automated process, commonly known as ‘pod slurping’, is able to copy whole databases and other confidential records to a portable storage device in a matter of a few minutes.

Serious Organized Crime Agency (SOCA) – U.K.

“…one of the big threats still comes from trusted insiders. That is, people inside the company who are attacking the systems.”

Data theft does not limit itself to corporate insiders. Outsiders can use social engineering techniques to manipulate unsuspecting employees into using media or portable storage devices on the corporate network workstation. Seeded with malware, these devices open backdoors in the corporate perimeter defense, allowing hackers easy access to corporate data. A well publicized example was an experiment conducted in 2006 by the Training Camp, a UK-based training institution (Sturgeon, 2006). This involved the distribution of promotional CDs to office workers. However, apart from the advertised material, these CDs contained a script that tracked and advised The Training Camp when the CD was used. Notwithstanding the fact that the CD contained an advisory note to check their company’s security policy before running it, 75 out of the 100 CDs distributed were used on the corporate network. This experiment underscores the fact that employees, acting in good faith, can bypass the best perimeter security, exposing corporations to serious repercussions. Corporations typically accumulate a wide array of data that can be stolen. This includes:

• Blueprints and engineering plans
• Tenders, budgets, client lists, emails and pricelists
• Credit card and other financial information
• Software source code and database schemas
• Medical or other confidential personally identifiable records
• Classified, restricted or personal information
• Scripts, storyboards, print material, photographic, video or animated film
• Score sheets, lyrics, sound files and other forms of phonographic material.

U.S. Secret Service & CERT Coordination Centre

“Respondents identified current or former employees and contractors as the second greatest cyber security threat, preceded only by hackers.”

The data stolen can be sold to competitors or used by the insiders, their criminal associates or hackers to commit a wide range of crimes ranging from identity theft to extortion and blackmail.Employees
leaving the company to work with a competitor may also use the data acquired to gain an edge over their previous employer or directly discredit the image of that company.

Surveys conducted by the U.S. Secret Service and CERT Co-ordnination centre concluded that: “Respondents identified current or former employees and contractors as the second greatest cyber security threat, preceded only by hackers” (Keeney et al., 2005). This is further corroborated in the CSI/FBI survey which indicates that 68% of respondents claimed losses due to security breaches
originating from insiders (Gordon et al., 2006).

2006 CSI/FBI Computer crime and security survey

“68% of respondents claimed losses due to security breaches originating from insiders.”

Legal liabilities

When confidential information is ‘lost’ or illicit/objectionable data is introduced on the corporate network through portable storage devices, corporations might become legally liable for any information that is stolen or illicitly introduced. Liabilities can impact the corporation’s assets significantly under different laws in different countries; under HIPAA (USA) the wrongful disclosure of individually identifiable health information, can be penalized with a maximum fine of $250,000 and 10 years imprisonment. The table below outlines a list of laws and the country in which they are applicable.

Country Laws

U.S.A. Sarbanes Oxley Act, Gramm-Leach-Bliley Act, USA PATRIOT Act, Title 21 of the Federal Regulations Part 11 (21 CFR Part 11), Federal Information Security Management Act, HIPAA

E. U. Data Protection Directive, Privacy and Electronic Communication Regulations; EU Annex 11, Computerized Systems;

U.K. Turnbull Guidance Act [1999], Companies Act, Data Protection Act, Freedom of Information Act, Money Laundering Regulations 2003

Japan Personal Information Protection Act 2003

Canada Personal Information Protection and Electronic Document Act (PIPEDA)

Australia The Federal Privacy Act (Privacy Act 1988)

Productivity loss

The corporate network can be misused by untrustworthy employees who use portable storage devices to bypass perimeter security personal files. These could include part-time work orhobby related material to be carried out during working hours. The problem grows to an exponential level when video games are transferred to the workplace. Video games are addictive, require constant user input and through multiplayer capabilities these can be a means of enticing and distracting more than one employee.

Corporate network security breaches

The usage of portable devices at work can also impact corporate network security through the intentional or unintentional introduction of viruses, malware or crimeware that can bring down the corporate network and disrupt business activity. Law enforcement agencies today acknowledge that “…one of the big threats still comes from trusted insiders. That is, people inside the company who are
attacking the systems” (Ilett, 2006).

U.S. Federal Trade Commission

“Disgruntled employees gaining access to customer lists and other information is proving a growing danger.”

Commonly used countermeasures

There are only a few countermeasures that corporations can adopt to prevent unauthorized portable device use. Banning portable storage devices on the corporate premises and the physical blocking of computer access ports are common practices. The deployment of Windows Group Policies is also utilized. These countermeasures however have a number of shortcomings:

• Most portable storage devices are small and easily concealable, therefore it is difficult to ensure
  that no-one has brought in a banned device.
• The inability to discriminate between legitimate devices and devices that should be denied access
  to resources.
• The overhead in manpower required to enforce these countermeasures.

The only really effective solution to counter portable device threats is by deploying a software solution that protects the corporate network perimeter against unauthorized device usage – a solution that
allows you to discriminate between legitimate and illegitimate use of devices, in compliance with the custom security policies set up by the corporation.

GFI Software offers a permanent solution which helps you protect your corporation against portable storage device threats. This is GFI EndPointSecurity – the effective counter measure against the enemy within! GFI EndPointSecurity allows you control entry and exit of data via portable storage devices, allowing you to prevent users from taking confidential data or introducing viruses and trojans to your network. GFI EndPointSecurity allows you to actively manage user access to media players (including iPod and Creative Zen), USB sticks,CompactFlash, memory cards, PDAs, Blackberries, mobile phones, CDs, floppies and more.

To read more and to download a trial version, visit
http://www.gfi.com/endpointsecurity/.

Conclusion

The uncontrolled use of portable storage devices by corporate insiders is a definite threat to the security and stability of every business. Malicious insiders and gullible employees who fall for social
engineering practices are the weakest link in the corporate security chain. Relying on user voluntary compliance to the corporate device usage policy is not a solution – you must deploy software
countermeasures that thwart this risk. GFI EndPointSecurity is a real alternative to corporate turmoil. It ensures business continuity by allowing portable device access to legitimate users whilst keeping corporate business sheltered from unauthorized data transfers to and from portable devices. With GFI EndPointSecurity, corporations are permanently protected!

BEST PRACTICES FOR SECURITY

INCIDENT RESPONSE

Are you prepared to make the best decisions and responses to security incidents in your business?

Picture this scenario: you arrive to work on Monday morning to find problems on your network. You can't log in, some servers seem to be down, and the phone is going crazy. You consider the possibility of two causes :

some fault has occurred and needs fixing you network is ( or has been ) under attack

What you do next is critical. Every decision you now make means a huge difference to the productivity of your business. This paper presents a short list of what needs to be done to address this situation: you have a security problem, it may be malicious hackers, or it could an entirely accidental problem.

Security Incidents . A definition
An IT security incident is a violation of IT security policy, acceptable use policy or of standard procedures

Which covers a lot of events, but most frequently amongst small to medium enterprises:

malware attacks

• virus ( becoming rare )
• worms
• trojan horses

Denial of Service ( DoS )

• as a side-effect of malware attack
• as a deliberate, intelligent attack

Intruders, intelligent agent attacks

• insiders
• outsiders
• ex-insiders

Email

• advertising - SPAM
• scams: phishing, Nigerian, stock market
• malware-carrying: trojans
  

Operational incidents

• system failures: crashes, environmental failure
• operator error
  

Prevention is always best, in other words: cheapest. Prevention is generally more economical, less stressful, and incurs less downtime however it requires a very full understanding of the security landscape and prevention systems such as anti-malware tools, and good processes. But eventually, the inevitable happens and the cost of recovery is directly related to the amount of fore-planning applied.

It has been estimated that in 2006, New Zealand businesses will lose a total amount of $140-240 million due to security incidents (Ref). This is a very high figure (dodgy statistics warning!) which must be close to the entire IT security revenue figure for New Zealand.

Detecting Incident Occurrence Detection is not always easy, often detection is through observing the side-effects of a security incident (eg. High network traffic). Major incidents are frequently announced by statements such as "that's funny", or "Uh oh" ...

Intrusion detection tools are generally good analysis tools, sometimes useful for tactical alerting. Always good to have in your toolkit.

Assessing the situation
Assess the situation as soon as possible after detection. Ask yourself (and anyone else in the vicinity) the following questions:

• what is the business impact of the incident?
• if the affected system(s) are isolated then what is the impact to business?
• how much effort will it take to resolve?
• this estimate can be re-evaluated later
• estimate for repair-in-place
• estimate for offline rebuild from scratch
• estimate to recover from backups ( you do have backups, don't you? )
• is there enough people with enough expertise available?
• if not, think about calling someone - either additional internal resources, or external providers
• document everything include dates and times, include contact information
  

Identifying the people to handle the incident
An incident team for a small to medium enterprise is almost always two people. One will be the technical lead who will perform the bulk of the remedial work, and the other will be a backup person reporting to management and recording the actions taken. Further people may be involved depending on the size of the organisation, usually in the reporting chain rather than in direct involvement. These may include:

• the IT manager
• the CEO/CIO/CTO
• Media relations
• Legal
• Law enforcement

Always get help if you feel the situation is getting out of hand. For example, in one case an incident involving malware infection dragged on for two weeks before someone was called in to diagnose the problem and resolve it within an hour. Get equipment and software tools if required. For example:

• new workstations, servers, switches/routers, firewalls
• IDS tools
• Anti-virus, Anti-spam tools
• Preparation is the key to saving time here. It is always good to have an incident toolkit ready with software tools on a CD or USB stick.

Forming a plan for resolution
Make a plan, not necessarily written, but at least well communicated. Include the following basic steps:

1. Contain the problem
Potentially by isolating the affected systems

2. Do No Damage
make backups of the affected system(s)
decide if preservation of evidence or critical data is required, if so then backups and correct procedures are critical

3. Resolve the problem
rebuild systems from scratch?
load backup data?
re-secure the affected system(s) as soon as possible

These steps may be reiterated as the resolution process continues. During resolution the following must be continuously performed:

• record all actions taken, and document as much as practical
• updated estimated RTO times
• report to management and other interested parties

Keep other people in the organisation up to date with expected RTO times and any issues that are outstanding. Discretion needs to be applied here : avoid public dissemination of sensitive information ( such as what type of system failed ), and be very cautious as to attributing blame.

Return to Operation
After the incident has been resolved the systems can be returned to operation, but only after they have been tested and re-secured to prevent any re-occurrence. Identify and mitigate all vulnerabilities that were exploited After return to operations, monitor the system closely to make sure all systems are restored to normal.

Report to management and other interested parties that the system has been restored.

Preventing Reoccurrence
This is by far the most crucial area, unfortunately it is often overlooked. Many problem would not occur if prevention measures had been put in place following the first occurrence.

Review the Causes

• Was the incident caused by a failure in one or more of the following?
• Technical controls?
• Environmental systems?
• Human factors?
• Management & budget constraints?

Review Resolution

• Could the incident have been detected earlier?
• Could the incident have been resolved quicker?
• Did you need more resources?
• Was reporting adequate?
• Would simulations and rehearsals help in resolving similar incidents?
• Would it help to have better incident response plans?

Create a Final Report
... and keep it short and to the point. 1-2 pages is the norm. In the final report detail the incident causes, how it was detected, the handling process, and provide an executive summary.

The key is to prevent re-occurrence.
Scenarios

Think about how you would handle each of the following hypothetical situations:

Scenario 1
The company's web server slows down then stops responding. High network traffic causes you to suspect a Denial of Service attack. Points to address:

• How will you identify the source of the traffic?
• Should you shutdown the corporate web server?
• How will you stop the traffic?
• How will you prevent it from reoccurring?

Scenario 2
The organisation starts receiving complaints about spam originating from its network The administrator identifies the source as the company.s web server Points to address:

• How would you validate the source of the spam?
• How would you respond to complaints regarding the spam?
• How would you isolate and repair the web server?
• How would you prevent reoccurrence?

Scenario 3
A new Trojan/worm is released on the Internet - it distributes itself through Email attachments and downloads malicious code from an Internet FTP server. A number of people in your organisation have opened such attachments. Points to address:

• How do you identify infected systems?
• How could you prevent the malware entering the enterprise before antivirus signatures
  were updated?
• How would you prevent further spread?

Scenario 4
An employee at your site mentions that his bank account has been cleaned out by hackers in Estonia. He has been using online banking from his company workstation. Points to address:

• Could you confirm whether or not his password was stolen?
• How would you report this incident?
• Would you warn other employees?

Scenario 5
The database administrator finds a strange directory on a database server, created by root 6 weeks ago. Points to address:

• How will you identify the source of the attack?
• How will you preserve the system?
• How will you identify what has changed on the system?
• How will you recover the system?

Scenario 6
A network intrusion detector identifies that someone has downloaded malware from a webmail account.

• How will you identify the person involved?
• How will you make sure their workstation is unaffected?
• How will you prevent it from reoccurring?

References
1. A survey conducted by the Employers and Manufacturers Association (Northern). Press release 6 December 2005. http://www.nzherald.co.nz/topic/story.cfm?c_id=137&ObjectID=10358566