Category: Cyber Security

Awareness of Social Engineering

Social engineering methods and means for obtaining information have been around for ages.

They seem like simple requests or benign coordinated events, but the truth is that social engineering often exploits your most valuable asset.  Your users.  A compromised user can then be used to wreak havoc or throw deeper hooks into the targeted network.  Most network hacks are incremental in nature with an attack vector that often times leads to a compromised user, admin, or super user.

The easiest way to penetrate, hack, or otherwise take-over a network is to start with the company directory. 

The simple example of a social engineering attack might be… ring ring, “hello, this is Joe with the helpdesk.  I am working on xyz what is your password?”  Social engineering methods are still the most prolific way for attackers to get deep within a network and allow attackers to simply go under the radar while they wreak havoc or steal sensitive data. 

A recent spear fishing attack on a US aerospace company leveraged the company directory and intricate email spoofing.  The attacker started a conversation from an email that looked like’s email domain.  In other words the attacker had the name of a person in the organization with a valid email address and job title, and then registered, a similar looking email domain, to send users targeted malware.  They used the company directory and email domain to go deep and got a susceptible IT staff member to open a link and unknowingly involved in the attack.  Ultimately the attacker was able to get admin access to critical systems on the network.

It is important to maintain a user awareness and training posture for your organization.  Users and stakeholders need to be constantly reminded of internet and email etiquette as well as not to click on un-trusted links.  Your network cannot rely solely on technical measures to keep bad people out.  Even with anti-virus, anti-malware, updated browsers, and pop-up blockers a social engineering attack takes people and awareness to thwart.

Physical and Environmental Considerations

The location and physical security of a server system is one of the first things to consider when putting a system online.  Your needs may not dictate that your server be in a secure Tier 4 co-location facility, but your servers may need to be at least in a locked and controlled access room in the back corner of your office suite.  The bottom line is that you can’t certify a system secure if it is in common access kitchen that you share with 4 other businesses.

Many IT departments have a safe place that they put the core of their network in.  Reliable power and cooling are needed to keep your systems running 24 hours a day 7 days a week.  If you are able to co-locate your servers with a service provider then make sure that you have the physical access that you need in case of emergency and after hours needs.  Service level agreements with your provider will help ensure that you get the help you need and that when something happens your organization is not left holding the bag.

Environmental concerns should be considered such as flooding and fire protection.  Hardware should be placed off the floor to prevent susceptibility to local water pipe flooding.  If you can place equipment higher than that, then you are even better off.  In 1997 one of the facilities that we were working at had a water main break in the back of the building.  Although the water main break was 10 feet below the ground, the water pressure created a large hole, compromised the concrete foundation of the building and mud and water poured into the rest of the building.  When workers arrived the next morning they found 6 inches of mud and muck throughout the building.  Though there was severe damage to the facility most critical equipment was spared simply because it was elevated off the ground.

Users desktops should also be elevated off the ground for the same reason.  Telecom equipment in data closets is typically wall mounted on back boards and should also be positioned at comfortable working heights well off the ground. 

Harden Linux Servers

*There are many distributions of Linux, our guide covers most standard Debian, RedHat, CentOS and BSD versions, however your particular distribution of Linux may use different default paths and system configuration files. 

Operating system installation

The base operating system installation should be healthy with a minimal install.  Your system should only have the software and packages installed that are being used.  Installation for kernel and system devices should be using the most current stable releases available.  Your system and data partitions should have enough space for daily maintenance routines and working data.  Depending on your needs you may need more space or can get by with less space if your server configuration and data growth is static.  Running services and boot processes should be minimal and only what is needed for your server application.  System temp directories and swap memory files should be properly configured for your installation.

To list installed packages follow these command line samples:

RedHat RPM based
->rpm -qa

->dpkg –get-selections


To show your kernel version and details
->uname –a

Utilize the ps command to see running process.  You should gather a baseline of running processes as a regular audit of system security.

Show processes for Linux
->ps -e

Show processes on BSD
->ps ax

To show disk space and utilization use the df command
->df -a

To see free memory
->free -m

To see startup processes
->chkconfig  -list

Startup scripts can be found in the following locations

/etc/rc.d/rc3.d/ or /etc/rc3.d/
/etc/rc.d/rc5.d/ or /etc/rc5.d/

Startup scripts start with an “S”.

/etc/init.d/*    is where service daemons are configured.

Depending on your Linux distribution you have a couple of options for ensuring that your system software is up to date for known vulnerabilities.  The easiest way to update software and dependencies is to use a package manager and trusted distribution update sources.  If you are running third party applications then make sure that you keep those up to date as well.

RedHat based systems use the RedHat Package Manager (RPM).  This package manager uses the up2date command with many options to check for dependencies and version updates.  RedHat and various other distributions that use RPM require registration and/or purchase to subscribe to automatic update services.

The rpm architecture includes several tools to build and install rpm packages.  The rpm database keeps track of software installed on your system which allows you to easily upgrade or uninstall packages.  The following example shows how to build an rpm package and install the apache web server from a source tarball.

->rpmbuild -tb httpd-2.4.x.tar.bz2
The rpmbuild utility will automatically create the rpm packages and will also list the dependencies that your system may be missing.

->rpm -U httpd-2.4.x-1.i686.rpm

Debian based systems utilize the Debian Package Manager.  Various command line utilities are available such as aptitude and apt-get which will source packages from standard Debian installation sources and check for dependencies.

->apt-get update

->apt-get upgrade

->apt-get install

Without the use of a package manager you will need to download source files then config and make software packages to update your system manually with a local compiler.

Ensure that system time is correct and synchronized to a reliable time source

Show system date and time

To setup a time server edit /etc/ntp.conf
Enter a line for each time source as follows

Replace “” with a time server or pool address that you choose.

Enable system logging and audit log files

System logging is an important piece to system hardening and security.  Proper configuration and auditing of log files is recommended.  On Linux there are various different log software daemons.  Syslog, syslog-ng and rsyslog are the commonly included logging utilities with Linux distributions. 

Permissions should be set for log files so that root is owner and they are not available to standard users.  Also, you should configure system log files to be sent or copied to a trusted centralized location so that they are tamper resistant.  When attackers breach a system they can cover their tracks or wreak havoc on your log files to make it hard to determine what or how they accessed it.

The configuration files for these logging daemons are located in /etc and the default log file repositories are in /var/log.


There are many commercial and open source software packages for collecting and auditing log files.  Many of these packages allow you to create alerts as well as provide more friendly filters to make viewing less tedious.  Server logs should be checked on a regular basis and can help troubleshoot other system problems. 

Lockdown file system security and permissions

To list file permissions and owner
->ls -l

Utilize the chmod command to set file system permissions.  Ensure that the following files are owned by root with their perspective permissions.

/etc/passwd set to rw-r–r–
/etc/group set to rw-r–r–
/etc/fstab set to -rw-r–r–
/etc/shadow set to r——–

The chmod command is a utility built into the command shell to manage file permissions and ownership.   See man chmod for symbolic and numeric usage options.  Also see as a good tool for understanding and converting mod permissions on files and directories.

Set cron permissions to allow only root to add cron jobs.
create/etc/cron.allow and /etc/at.allow with root as the owner and permission set to r——–
root should be the only text in these files.

Ensure that password policies meet your organizational requirements.  /etc/login.defs  is used by the system to configure password policies.  See man login.defs for configuration details.  Password aging should be enforced at 90 days or less and minimum length should be set with at least 10 characters.  Highly secure systems should enforce longer passwords.

Utilize sudo rather than su to perform super user tasks

Sudo is a per command super user utility which users can launch with their own passwords.  In other words you are able to keep the root password safe and secret and give administrative users the proper access to run tasks via sudo commands.

Edit /etc/sudoers  files to give users sudo access.  To run a command under the super user context precede commands with sudo.

->sudo pico /etc/ssh/sshd_config
Will open the sshd_config file with the pico editor as super user.

Configure networking, firewall, and port settings

Network segmentation and placement of your server may play a role in how much effort you put into configuring your local firewall settings.  Whether your network is NAT, DMZ, local trusted, or placed directly on a public segment will determine how you need to configure local host-based firewall settings.  Network segmentation and firewall settings used in conjunction with an edge security solution is recommended.

To see which network ports are open and listening run netstat -a

Linux uses INPUT, FORWARD, and OUTPUT chains via iptables for host-based firewall rules.
The iptables rules are simple logic rules to determine whether or not a packet is accepted or rejected.  The order of the rules is important to consider.  Incoming traffic is filtered from top down.

Ubuntu iptables reference is one of the most complete and can be found at

To view currently running iptables configuration:
->sudo iptables -L

Sample output from this command on a running system:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
REJECT      all  —  anywhere             loopback/8          reject-with icmp-port-unreachable
ACCEPT     all  —  anywhere              anywhere            state RELATED,ESTABLISHED
ACCEPT     tcp  —  anywhere             anywhere            tcp dpt:www
ACCEPT     tcp  —  anywhere             anywhere            tcp dpt:https
ACCEPT     tcp  —  anywhere             anywhere            tcp dpt:smtp
ACCEPT     tcp  —  anywhere             anywhere            tcp dpt:pop3
ACCEPT     tcp  —  anywhere             anywhere            tcp dpt:pop3s
ACCEPT     tcp  —  anywhere             anywhere            tcp dpt:imap2
ACCEPT     tcp  —  anywhere             anywhere            tcp dpt:imaps
ACCEPT      all  —  anywhere             anywhere            state RELATED,ESTABLISHED
REJECT      icmp —  anywhere          anywhere            reject-with icmp-port-unreachable
LOG              all  —  anywhere             anywhere            limit: avg 5/min burst 5 LOG level debug prefix `iptables denied: ‘
REJECT      all  —  anywhere              anywhere            reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT      all  —  anywhere             anywhere            reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  —  anywhere             anywhere

The following iptables configuration file corresponds to the output above which allows HTTP(port 80), HTTPS (443), SMTP (25), outbound connections, pop3, imap,  imaps(993), and pop3s(995).  See security through obscurity section for other tricks.  Packets that meet the filter rules are accepted.  All others are dropped. 

//file = /etc/sysconfig/iptables.sample

# Generated by iptables-save v1.4.8 on Thu Nov 29 07:35:35 2012

[0:0] -A INPUT -d ! -i lo -j REJECT –reject-with icmp-port-unreachable
[9855:1333917] -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
[20:964] -A INPUT -p tcp -m tcp –dport 80 -j ACCEPT
[16:832] -A INPUT -p tcp -m tcp –dport 443 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp –dport 25 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp –dport 110 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp –dport 995 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp –dport 143 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp –dport 993 -j ACCEPT
[0:0] -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
[535:32144] -A INPUT -p icmp -j REJECT –reject-with icmp-port-unreachable
[921:58908] -A INPUT -m limit –limit 5/min -j LOG –log-prefix “iptables denied: ” –log-level 7
[1067:66503] -A INPUT -j REJECT –reject-with icmp-port-unreachable
[0:0] -A FORWARD -j REJECT –reject-with icmp-port-unreachable
[12195:1597429] -A OUTPUT -j ACCEPT

# Completed on Thu Nov 29 07:35:35 2012

//eof /etc/sysconfig/iptables.sample

You can also use gui tools such as system-config-firewall and system-config-firewall-tui to configure your local host firewall.  Linux distributions allow you to specify basic firewall settings during installation but most default installations are open and allow all traffic.

Be cautious when editing firewall rules on a remote system as you can block yourself out of your own system.  See section on security through obscurity for more settings.

Configure and secure SSH server daemon and Xwindows settings

Remote access should be configured with SSH version 2 and you should not allow root login.  Edit SSH server settings in the /etc/ssh/sshd_config file.  Key settings for the ssh daemon include:

PermitRootLogin  no  – do not allow root to login via ssh, users can still su or sudo once logged in
Protocol 2   – force ssh to use protocol version 2 which is more secure
AllowUser   user1, user2, user4  – tell ssh which users are allowed access
DenyUser   user3, user5   – tell ssh which users are denied access
Port 22  – set the listening port number for ssh daemon, see security by obscurity

If you are configuring and utilizing X windows ensure that you enable X11 forwarding so that sessions are encrypted to your X server via SSH.  Otherwise X windows sessions are unencrypted and easily sniffed off the network.  Enabling X windows should be minimized as there are known exploits and system overhead with it.

 Advanced packet filtering with tcpd and hosts_access control files

Tcpwrappers allow for robust access control and logging of network daemons and was one of the earliest packet filtering methods for Linux systems.  The tcpd daemon can be used in conjunction with inetd, when services are defined to run via inetd.conf, or daemons can be compiled and configured to include the libwrap library natively. 

Access control rules for tcpd are located in /etc/host.allow and /etc/hosts.deny

Many options are available to shape and filter incoming connections with these access control rules.  See man hosts_access for good documentation on how to use and implement the access control programming language.  Connections that are filtered by tcpd are logged via standard syslog log file mechanisms so that auditing of these wrapped services is possible.

If your system is running an http daemon there are a couple of basic security precautions that you should take.  Apache web server is a robust web server platform with many commercial and free add-ons to enhance its functionality.  Apache mods (modules) are configurable enhancements to the Apache web server system.  File system security for content directories as well as the executable http binaries and apache installation files should be locked down and checked.  Root should be the owner of these directories and they should not be writable by others.

->ls -l /etc/apache2

-rw-r–r–           1   root   root     8096                 May 31 20:49                 apache2.conf
drwxr-xr-x       2   root   root     1024                 Nov  8  19:05   conf.d
-rw-r–r–           1   root   root              0 Mar 19  13:31 httpd.conf
drwxr-xr-x       2   root   root     9216                 Nov  8  19:05   mods-available
drwxr-xr-x       2   root   root     1024                 Mar 19  13:40 mods-enabled
-rw-r–r–           1   root   root        786 May 31 21:03                 ports.conf
drwxr-xr-x       2   root   root     1024                 Nov  8  19:05   sites-available
drwxr-xr-x       2   root   root     1024 Mar 19  13:30 sites-enabled

The following system settings in your apache config file are recommended to further limit access.

<Directory />
   AllowOverride None

//Prevents users from overriding server settings with different .htaccess files.

<Directory />
   Order  Deny, Allow
   Deny from all

//To prevent users from accessing file system directories

<Directory /path/public_html>
  Order  Deny, Allow
  Allow from all

//Allow access to specified web site directory replace path with your path

The Apache mod_security package is recommended to enable enhanced configuration in your Apache configuration files.  Extra logging and more granular control over error messages and file uploads is enabled. 

The Apache HTTP server website provides a good reference.

Secure and Configure MySQL and Postgress SQL servers

One important thing to consider when protecting a database is that data is often clear text inside the database files.  Encryption of the underlying file system and any database backups is recommended.  Password and sensitive data such as credit card numbers should be hashed and the hashed data value should reside in the database. 

User access to database applications should be over SSL connections and clear text authentication should be disabled.  SSL certificate installation and safeguarding helps to prevent man-in-the-middle compromises.  Backups and file systems should be physically safeguarded to prevent attackers from having a crack at the database.  Remember once an attacker has the data or access to the server console your system is as good as hacked with most measures such as encryption and hashing only delaying the disclosure of data.

Web applications should be protected against SQL injection attack methods and all input fields should be filtered and defined.

It is recommended to run Anti-virus or anti-malware software on your system.  These applications or only as good as their configuration and current definition versions but can allow you to be protected against known wild variants of bad software.

System files should be checked for integrity and compared regularly to a known good source.  You can easily find and compare checksums of system files and backup files.  If configuration files have changed it should raise a red flag.  Intrusion detection systems should be configured to watch these files.

Linux Security References:

BITS Data Room

Network System and Application Hardening

System hardening is the application of known best practices and security measures in order to increase the security resilience of a network. 

The fundamental philosophy of system hardening is to reduce the overall exposure to risk by reducing the attack surface area. 

System hardening should be part of a cohesive approach along with proper network segmentation, access control, and training programs.  System hardening helps to increase a server system and network’s resilience against denial of service, unauthorized disclosure, and network intrusion.  Hardening a server system not only helps protects against threats, but also allows for successful forensics investigations if a security incident is to occur.

It is important to note that not all threats can be prevented and security attack vectors are often outside of technical control measures with end users often being compromised.  A thorough and regular end user training and awareness program should be adopted as part of your organization’s cohesive strategy.

Needs vary based on your application, but hardened servers should have a reliable redundant disk subsystem.  Hardware or software raid levels should include redundancy for physical drive failure.  If your machine is on a VM platform then you will want to ensure that the underlying hardware is server class with redundant power and storage.

Connectivity to your server systems should be sufficient to meet your bandwidth needs.  Your own risk analysis can help determine if you need redundant connections based on the cost of downtime or hardware failure.  Modern MPLS (Multiprotocol Label Switching) networks can be engineered to meet your needs if your organization has multiple office locations.  MPLS networks are designed to keep traffic between your different network locations isolated and optimized.  Keeping a service grade connection with an SLA will help ensure that downtime due to connectivity is minimized. 

The base operating system installation should be healthy with a minimal install.  Your system should only have software and packages installed that are being used.  Installation for your operating systems, server applications, and system devices should be current stable releases.  Your system and data partitions should have enough space for daily maintenance routines and working data.  Depending on your needs you may need more space or can get by with less space if your server configuration and data growth is static.  Running services and boot processes should be minimal and only what is needed for your server application. 

The Security Management Process

A technically minor attack like a defaced web page may or may not be as devastating as a backend server breach.  What about a multi-vector DDoS (distributed denial of service) attack?  The security management process helps your organization get a better understanding of your attack surface i.e., exposure to risk.  It is important for your organization to perform your own risk analysis to determine how costly a data breach or offline system is.

An incident response plan detailing what to do in the event of a cyber breach is key to helping your organization recover.  Technology changes, vendors change, and people change around your cyber landscape so it is important to keep your incident response plan up to date and relevant.  For many organizations this is a perpetual process.

The first part of your organization’s solution is to gather your management team and ensure that IT security is an included and thorough part of your risk management plan.  Healthcare, education, government, and financial organizations are required to include information security and many industry catered templates or programs can be leveraged.

Security risk management is an important business and financial undertaking. It includes identifying important assets to an organization and helps to determine the value or emphasis that should be placed on protecting those assets.  These assets can be information (data), facilities, people, products, or systems.  A complete risk management program is not only required for many organizations but imperative to their survival and financial well being. 

The only way to measure the performance of a risk management program is to perform audits.  Audits help to inform you of whether or not your administrative, physical, or technical safeguards are working and properly in place.  If a security incident uncovers a new gap in your security management plan then your team must account for this new gap or vulnerability.

Your cyber security plan should consider compromised users and ways to mitigate and trap such users.  It’s all in the log files.  Log file correlation and automation is a good practice to adopt, and getting problems to the human awareness and response level is ultimately what your organization needs to successfully mitigate a cyber event. 

Successful attacks take time to implement and realize.  Most all major cyber incidents like that of retail chain Target or the PlayStation network of Sony go unnoticed for weeks or even months.  Recent attacks in the news show that organizations are often times lazy about log file auditing or simply don’t know what they are looking at. 

Size of the Cyber Security Problem

Let’s get an idea for the size and scope of the cyber security problem. 

Billions of devices, from security cameras to corporate workstations to points-of-sale, are all attached in one way or another via this thing we often refer to as the internet of things.  To add some size to this problem we have billions of people all relying on this every day for work, healthcare, social, and government services amounting to a huge cyber dependent economy.  Projected growth in both population and reach of the internet is going to continue to grow this problem with raw numbers alone. 

Now, technologies are put into places to control things such as power generators or GPS driven cars and then patched right in.  Literally if compromised these technologies could cause real physical danger to the public.

The problem gets compounded and becomes larger when you start to consider out-of-the-box vulnerabilities and mis-configurations.  We estimate that as many as 30% of new devices, systems, and VMs are put online and vulnerable with out-of-the-box vulnerabilities.  Another 20% of systems are open with administrator mis-configurations. Then the hardware issues: MTBFs (mean time between failures) for devices such as hard drives and power supplies interrupt life with maintenance downtime when they find single points of failure.  Online “cloud” providers allow public facing virtual machines to run un-patched.  While everything needs continual patching from front end plugins to the underlying firmware on core routers. The list goes on…

As you can see this problem is big enough already. 

Let’s now consider the facts about the cybersecurity problem:

  1. Information warfare is constant, persistent, lucrative, and disruptive.
  2. It now includes everyone with players such as nation states, militaries, hacker groups, organized crime, universities, and corporations.

The rules are simple:

  1. Don’t become a target
  2. Everyone’s a target

News reports of cyber security and data breaches are daily with countless un-reported, negligent, or unknown. 

When an organization is victim to a cyber attack it is often times a humiliating and tarnishing event.  Some organizations never recover while others may eventually regain confidence. 

The attackers and cyber thieves operate from a perceived safety base masked by VPN’s, Proxies, and Tor.  State backed hackers from certain nations operate in teams with rewards for finding something interesting.  Bot-nets of hackers can perform Distributed Denial-of-Service attacks on most any major network or website with ease. 

The web and the ecosystem around it provides us with great things and the modernities of integrated technology, but it is also a huge launching platform and mask for deviant individuals and encited parties to operate.

Many organizations have spent years online and spend millions of dollars on firewalls, intelligent network components, anti-virus and malware licenses, spam filtering services, training, staffing, certificate services, … and others have not.  New technologies, people, and businesses simply come on-line into the never ending expanse we call cyber space.  Otherwise known as the internet, the web, the cloud and online services.

BITS Help Desk

Cyber Security

Cyber Security Starts Here


Cyber security is both an active and comprehensive undertaking.  There is no firewall, magic antivirus, pop-up blocker, Java update nor VPN client that will protect you from everything.  A comprehensive approach starting with leadership that includes risk management, best practice implementations, and system hardening is needed to best protect your organization’s information assets. 

“Cyber Security Starts Here” is meant to be an informative yet precisely condensed and current manual to help any organization improve their cyber security posture.  In today’s world of privacy concerns, and ever expanding connectivity it is imperative for you to adopt and implement a practical strategy.  Your strategy needs to be inclusive of leadership as well as end-users and IT staff.

We can’t tell you all of our tricks here, but hopefully you will take this information as a start to your own cyber security initiatives.