FOSS Network Infrastructure and Security/Security Functions with FOSS

 FOSS Network Infrastructure and Security 

---

Foreword — List of Abbreviations — Introduction to FOSS and GNU/Linux — Network Concepts and Architectures — Major Networking Functions with FOSS — Security Functions with FOSS — Network Planning — Further References — Glossary — About the Author — Acknowledgements — About APDIP — About IOSN

Security Paradigms, Security Policies and Infrastructure Issues

Network and information security is one of the most important considerations when designing and deploying a network. Before we can get into the details of network security implementation with FOSS, we need to look at the different security paradigms that have been in existence for some time now. The older paradigm supported the notion that perimeter security was the ultimate form of security for any network. That myth has now been debunked, and the new paradigm advocates that every device must be made secure in itself in addition to the perimeter security imposed by firewalls and packet filters.

Security as a technical solution is also no longer a valid assumption. Security now involves not only stopping malicious packets from entering your network, but also preventing these malicious packets from coming from your network; deploying tools to detect intrusion attempts and generate logs; intelligent network sniffers and use of an individualized security policy; centralized logs to keep on top of information overload (or log overload), centrally managing the configuration firewalls and routers to detect changes (configuration management and security policy management); and host security tools to ensure that the last frontier of the protection – the host itself – is protecting data and is not compromised. All of these form a web of security that will effectively protect the organization, provided you know what you want to protect and how you want to protect it. This is to be articulated as a security policy.

The security policy is now one of the most important security tools for any organization as it helps in maintaining consistency in security implementation. Without the use of a security policy, it becomes difficult for an administrator to decide what to focus on. It also helps an organization to take action against people who defy the policy. In the absence of any such policy, work is always done on an ad hoc manner, which can create more possibilities for security breaches.

There is no one solution that can solve your security problems. What is more useful are best practices that document ways in which common security problems can be avoided. There are also security best practices for when a security breach occurs. Let’s look at common reasons for security breaches and some of the best practice remedies.

Network Security Risks

Open Architecture of TCP/IP

While TCP/IP is a highly efficient, cost-effective and flexible communications protocol for local and global communications, and is widely adopted on the global Internet and in the internal networks of large corporations, it was designed 20 years ago when the Internet consisted of a few hundred closely controlled hosts with limited security. The Internet now connects millions of computers that are controlled by millions of individuals and organizations, and where the core network is administered by thousands of competing operators. This complex network spans the whole globe, connected by fibres, leased lines, dial-up modems, and mobile phones. Thus, while it is tolerant of random errors, TCP/IP is vulnerable to a number of malicious attacks.

The basic premise of ‘end-to-end’ connectivity on the Internet means that you are as likely to receive illegitimate traffic as legitimate traffic. Thus the scope of security is not to stop all traffic, but to detect and deter the most malicious of attacks.

Common Types of Threats and Attacks

• Unauthorized access – insecure hosts, cracking, intrusion
• Eavesdropping on a transmission – gaining access to the medium to look for passwords, credit card numbers, or business secrets
• Hijacking, or taking over a communication
• Inspecting and modifying any data being transmitted
• IP spoofing, or falsifying network addresses
• Impersonating to fool access control mechanisms
• Redirecting connections to a fake server
• Denial of Service (DoS) attacks, when a huge amount of useless data coming to the target makes it unable to function properly
• Interruption of service due to system destruction or using up all available system resources for the service CPU, memory, bandwidth
• Default passwords and default configuration

Mistakes People Make that Lead to Security Breaches

Technological holes account for a great number of successful break-ins, but people do their share as well.

Five Worst Security Mistakes End-users Make

• Failing to install an anti-virus, keep its signatures up-to-date, and perform full system scans regularly.
• Opening unsolicited e-mail attachments without verifying their sources and checking their content first, or anything from untrusted sources.
• Failing to install security patches, especially for frequently used software like those for word processing, web browser, e-mail client and operating systems.
• Not making and testing backups.
• Using a modem while connected through a local area network.

Seven Worst Security Mistakes Senior Executives Make

• Assigning untrained people to maintain security and providing neither the training nor the time to make it possible to learn and do the job.
• Failing to understand the relationship between information security and business problems. They understand physical security but do not see the consequences of poor information security.
• Failing to deal with the operational aspects of security: making a few fixes and then not allowing the follow-through necessary to ensure that the problems stay fixed.
• Relying primarily on a firewall.
• Failing to realize how much money their information and organizational reputations are worth.
• Authorizing reactive, short-term fixes so that problems re-emerge rapidly.
• Pretending the problem will go away if they ignore it.

Ten Worst Security Mistakes IT People Make

• Connecting systems to the Internet before hardening them.
• Connecting test systems to the Internet with default accounts/passwords.
• Failing to update systems when security holes are found.
• Using telnet and other unencrypted protocols for managing systems, routers, firewalls and PKI.
• Giving users passwords over the phone or changing user passwords in response to telephone or personal requests when the requester is not authenticated.
• Failing to maintain and test backups.
• Running unnecessary services: ftpd, telnetd, finger, rpc, mail, rservices.
• Implementing firewalls with rules that do not stop malicious or dangerous traffic, whether incoming or outgoing.
• Failing to implement or update virus detection software.
• Failing to educate users on what to look for and what to do when they see a potential security problem.

Security Best Practices and To-dos

Some set a goal to fully and completely secure a system, which is impractical as it is usually impossible to make a system full-proof. A realistic goal is to set up a regular routine where you identify/correct as many vulnerabilities as possible.

Security Best Practices

A good security system makes it so difficult for an attacker to gain access that he gives up or gives an administrator enough time before he gets in.

• The idea is not that you should protect a system to the point that it cannot be compromised, but

to secure it at least enough so that most intruders will not be able to break in, and will choose to direct their efforts elsewhere. This is just like putting iron bars and locks on our windows and doors. We do it not to ‘keep the robbers out’, but to persuade them to turn their attention to our neighbours.

• Rather than directing our efforts at protecting against the thousands of specific threats (this

exploit, that Trojan virus, these mis-configurations), we focus our energies on tasks that provide the most comprehensive protection against the majority of threats.

• Best security practices are very dynamic, constantly changing and evolving.
• Administrators should include their own best security practices and modify those mentioned

here to best fit their environment.

Points to Ponder

• Take into consideration your needs, risks, and resources.
• Information systems are unavoidably complex and fluid, so the most effective way to apply security is in layers.
• You should place security measures at different points in your network, allowing each to do what it does best.
• From an attacker’s perspective, you will have constructed a series of obstacles of varying difficulty between the attacker and your systems.
• Secure each component in your system (firewalls, routers, servers, hosts and appliances) so that even if an attacker works his/her way through your obstacle course, at the end he/she will find systems that are resistant to attack.

Backup

• Maintain full and reliable backups of all data and log files.
• Archive all software (purchased or freeware), upgrades, and patches off-line so that they can be reloaded when necessary.
• Backup configurations, such as the Windows registry and text/binary configuration files, used by the operating systems or applications.
• Consider the media, retention requirements, storage, rotation, methods (incremental, differential, full) and scheduling.
• Keep a copy of a full backup in a secure off-site location for disaster recovery.

Security To-dos

• Enforce Deny by Default. Everything that is not allowed specifically is denied. This is a good way of tightening security.
• Reduce access to things on a ‘need to know’ basis. That means that anybody who does not need access to a computer, a network, or a piece of information should not have access to it. This is also known as the Least Privilege Rule. Give the least privilege, the least access capabilities you can for someone to do his/her job.
• Try to have identified choke points, which are points where you can inspect everything going on the network – i.e., a network where all communications pass through the Internet, a VPN concentrator where all the external accesses converge, a Modem pool where all external dial-in access come to, a dedicated VLAN where all the Wireless (WLAN) Access Points are connected to see who is coming from the wireless entry points.
• Try to identify and focus on your weakest link, or the weakest part of your security that would compromise all the rest. Remember that the hacker just needs to succeed once to hack you, whereas you have to succeed all the time in your security job to protect your organization. So, the weakest link is always where you should focus your attention, trying to have no security ‘fence’ notably ‘lower’ than all the others in your network.
• You should also try to have the capability to ‘fall back’ into a secure position in case of trouble. Security Policy Management systems can ensure the ‘lock down’ of the network in case of a worm, for example. Such a configuration would allow the DNS and maybe some vital traffic for the company (payroll, electronic fund transfer, ERP traffic) and block all the potential worm infection vectors (mail, web).
• You should try to have a security device ‘deep down’ in your network, not only at the boundaries with the external world. If the life of your company depends on one computer holding sensitive data or running a factory, add a firewall in front of it. This is ‘Defense in Depth’.
• If you diversify your defense, such as running two different brands of antivirus (one kind for your mail gateway, and another kind for the desktops and user machines), that may help you catch some attacks that were not blocked by one brand but will be by the other brand. You can also have a diversity of kinds of defense, like having antivirus and personal firewalls on the desktops.
• KISS – Keep It Short and Simple. If your network and your security are simple, you will be less likely to have forgotten something that attackers will exploit. Clarity is important as you HAVE TO understand the whole network and the whole security organization. Do not feel that it is ‘dumb’ to ask ‘simple questions’; these are often the ones that will make everybody realize that there is a problem.
• Security through obscurity is the opposite of the following principle. If someone tells you ‘do not worry, this is secure’ and does not want to explain the security mechanism, then YOU SHOULD WORRY. Hiding how things work and having your security depending on this to be secure is the worst thing you can have. For example, you should still secure computers in your network even if attackers cannot download the DNS zone of your company which lists the IP addresses. Sooner or later, an attacker will find a way to know about this ‘hidden’ computer and will then have full access. The only things you should keep secret and hidden are your password and your cryptographic keys (PGP private keys). Assume that all other knowledge may be known by attackers.

Securing Your Network and Hosts Properly

Firewalls

Many people think that a firewall is a single device that is configured to protect your internal network from the external world. In reality, a firewall is a system (or a group of systems) that enforces an access control policy between two networks. It disallows unauthorized and/or malicious traffic from traveling into and out of your network. Users must realize that firewalls cannot protect you from attacks that do not go through it. If there is another entry point to your network that is not protected by a firewall, then your network is not secure. Also, contrary to the common misconception, firewalls do not verify the content of the traffic going through it.

Types of Firewalls

Packet filtering firewalls

• Examines the source and destination address of the data packet and either allows or denies the packet from traveling through the network.
• Blocks access through the firewall to any packets that try to access ports which have been declared ‘off-limits’.

Application layer firewalls

• Attempts to hide the configuration of the network behind the firewall by acting on behalf of the network/servers.
• All requests for access are translated at the firewall so that all packets are sent to and from the firewall, rather than from the hosts behind the firewall.

Stateful inspection firewalls

• Examines the state and the context of the packets.
• Remembers what outgoing requests have been sent and allows only the responses to those requests back through the firewall.
• Attempts to access the internal network that have not been requested by the internal network will be denied.

Firewall Best Practices

Regardless of which type of firewall, someone has to configure it to make it work properly. The rules for access must be defined and entered into the firewall for enforcement. A security manager is usually responsible for the firewall configuration. But again, if the policy is not made properly, then there is not much that the security manager can do. Some rules of thumb are:

• Explicitly deny all traffic except for what you want.

The default policy should be that if the firewall does not know what to do with the packet, it should deny/drop the data packet.

• Do not rely only on your firewall for the protection of your network. Remember that it is only a device, and devices do fail.
• Make sure you implement what is called ‘defense in depth’, or multiple layers of network protection.
• Make sure all of the network traffic passes through the firewall.
• If the firewall becomes disabled, then disable all communication.
• If there is another way into the network (like a modem pool or a maintenance network connection), then this connection could be used to enter the network, completely bypassing firewall protection.
• Disable or uninstall any unnecessary services and software on the firewall.

Limit the number of applications that run on the firewall.

• Consider running antivirus, content filtering, Virtual Private Network, etc. on different hardware.
• Do not rely on packet filtering alone. Use stateful inspection and application proxies if possible.
• Ensure that you are filtering packets for illegal/incorrect addresses, to avoid IP spoofing.
• Ensure that physical access to the firewall is controlled.
• Use firewalls internally to segment networks between different departments and permit access control based on business needs.
• Remember that firewalls will not prevent attacks that originate from inside your network.

Netfilter/iptables

iptables13 is the most popular FOSS firewall tool available on GNU/Linux. It works in combination with netfilter, which is included as an integral part of the Linux kernel. It has been in the kernel as the firewalling subsystem since release 2.4.x.

iptables is a much improved version of previously available IP Chains and ipfwadm software.

It does packet filtering (stateless or stateful) as well as Network Address Translation (NAT) and IP Masquerading. It can also perform packet mangling (manipulation).

iptables consists of the following:

• Userspace command for runtime configuration of the firewalling subsystem;
• Kernel modules and the user interface application. Kernel modules are components that handle
• various tasks and are compiled as loadable modules in the GNU/Linux kernel;
• Generic table structure for the definition of rulesets; and
• A number of classifiers (matches) and one connected action (target).

iptables – Tables , Chains and Rules iptables normally has multiple tables defined in the kernel. The default is the ‘filter’ table. The Linux kernel starts with three lists of rules in the ‘filter’ table. A chain is a checklist of rules. There are three built-in chains: the INPUT, OUTPUT and FORWARD chains. The Linux kernel examines each chain to decide the fate of the packet. In turn, each rule says ‘if the packet header looks like this, then here is what to do with the packet’.

iptables Syntax

[root@mail /]# iptables [options] [table] rules TARGET

Main iptables options

1. Create a new chain (-N).

2. Delete an empty chain (-X).

3. Change the policy for a built-in chain. (-P).

4. List the rules in a chain (-L).

5. Flush the rules out of a chain (-F).

6. Zero the packet and byte counters on all rules in a chain (-Z).

You can use ‘iptables –h’ to see a list of command options

To manipulate rules in a chain

1. Append a new rule to a chain (-A).

2. Insert a new rule at some position in a chain (-I).

3. Replace a rule at some position in a chain (-R).

4. Delete a rule at some position in a chain (-D).

5. Delete the first rule that matches in a chain (-D).

The default policies

The default policy is to accept all packets to, from, and through it.

INPUT ACCEPT any any FORWARD ACCEPT any any OUTPUT ACCEPT any any

To set the default policies to DROP all packets:

 iptables –P INPUT DROP
 iptables –P FORWARD DROP
 iptables –P OUTPUT DROP

Targets – what to do if a packet matches a rule

ACCEPT DROP REJECT LOG

Example rules

 iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
 iptables -D INPUT 1
 iptables -D INPUT -s 127.0.0.1 -p icmp -j DROP
 iptables -A INPUT -s 0/0 -j DROP
 iptables –A INPUT –p tcp –dport 25 –j ACCEPT
 iptables –A FORWARD –p tcp dport 25 –j ACCEPT
 iptables –A FORWARD –I eth0 –o eth1 –p tcp –dport 25 –j ACCEPT
 iptables –A FORWARD –s 192.0.2.0/24 –d 202.52.255.1 –p tcp –dport 25 –j ACCEPT
 iptables –A FORWARD –s 192.0.2.0/24 –d 202.52.255.5 –p udp –dport 53 –j ACCEPT
 iptables –A FORWARD –d 202.52.255.5 –p tcp –j LOG –log-prefix “TCP log ”

To get help:

 iptables -p tcp -h
 iptables -m state -h
 iptables –j ACCEPT -h

Connection tracking

Stateful connection tracking of traversing packets with –m state –state options

NEW – packets that create a NEW connection ESTABLISHED – packets belonging to an existing connection – reply packets RELATED – packets related to an existing connection – ICMP error messages/ FTP data connections INVALID – packets not corresponding to any existing connection

# iptables –A FORWARD –d 192.0.2.0/24 –p tcp –m –state –state ESTABLISHED –j REJECT

# iptables –A FORWARD –m –state –state INVALID –j DROP

Sample iptables setup

iptables –F flush all the chains
iptables –X delete all the empty chains
# Changing Default policy
iptables –P INPUT DROP
iptables –P FORWARD DROP
iptables –P OUTPUT DROP
# INPUT chain
iptables –A INPUT –p icmp –j ACCEPT
iptables –A INPUT –I eth1 –p tcp –dport 22 –j ACCEPT
iptables –A INPUT –I eth1 –m state –state ESTABLISHED,RELATED –j ACCEPT
# FORWARD chain
iptables –A FORWARD –p icmp –j ACCEPT
iptables –A FORWARD –I eth0 –o eth1 –d 192.0.2.1 –p tcp –dport 25 –j ACCEPT
iptables –A FORWARD –I eth0 –o eth1 –d 192.0.2.2 –p tcp –dport 110 –j ACCEPT
iptables –A FORWARD –I eth0 –o eth1 –d 192.0.2.3 –p tcp –dport 80 –j ACCEPT
iptables –A FORWARD –I eth0 –o eth1 –d 192.0.2.4 –p tcp –dport 53 –j ACCEPT
iptables –A FORWARD –I eth0 –o eth1 –d 192.0.2.4 –p udp –dport 53 –j ACCEPT
iptables –A FORWARD –I eth0 –o eth1 –d 192.0.2.0/24 –m state – state ESTABLISHED,RELATED –j ACCEPT
iptables –A FORWARD –I eth1 –o eth0 –s 192.0.2.1 –p tcp –dport 25 –j ACCEPT
iptables –A FORWARD –I eth1 –o eth0 –s 192.0.2.4 –p tcp –dport 53 –j ACCEPT
iptables –A FORWARD –I eth1 –o eth0 –s 192.0.2.4 –p udp –dport 53 –j ACCEPT
iptables –A FORWARD –I eth1 –o eth0 –s 192.0.2.0/24 –p tcp –dport 80 –j ACCEPT
iptables –A FORWARD –I eth1 –o eth0 –s 192.0.2.0/24 –m state – state ESTABLISHED,RELATED –j ACCEPT
# OUTPUT chain
iptables –A OUTPUT –p icmp –j ACCEPT
iptables –A OUTPUT –o eth1 –p tcp –dport 22 –j ACCEPT
iptables –A INPUT –o eth1 –m state –state ESTABLISHED,RELATED –j ACCEPT
# Enabling NAT
iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -j MASQUERADE

References

http://www.unixreview.com/documents/s=1237/urm0103c/0103c.htm
http://www.knowplace.org/netfilter/index.html
http://www.GNU/Linuxguruz.org/iptables/
http://www.boingworld.com/workshops/GNU/Linux/iptables-tutorial/iptables-tutorial/iptablestutorial.html

Server Security, Host/Network Scanning and Intrusion Detection System

It is often advisable that a detection and prevention measure be run in addition to the firewall. This is commonly referred to as Network Scanning and Intrusion Detection System (IDS). There are also other proactive measures that can make your system and servers secure. Let’s look at some of these.

Server Security Dos and Don’ts

• Run the server on a hardened and routinely updated operating system.
• Keep current on software/application updates.
• Ensure that you test these updates in a controlled, non-production environment whenever possible.
• One server patch may undo a correction applied by a previous patch so scan the server after the patching-up.
• Disable file sharing on all critical machines as it makes them vulnerable to information theft and certain types of quick-moving viruses.
• Improper sharing configurations can expose critical system files or give full file system access to any hostile party.

Host/Network Scanning

Network scanning refers to the activity of scanning your own networks for vulnerabilities. There are tools available for this purpose. Incidentally, these are most often the same tools used by crackers and external parties to gauge your network security. Thus, using them yourself can lead you to quite a few of those security holes, which would go unnoticed otherwise. Below are some tips on what to scan for.

Scanning systems tips

• Scans will help determine that only the required ports are open.
• Check that services running on the open ports are not vulnerable to known security bugs/holes.
• If new open ports are found, check if your systems have been compromised.
• Perform full port scans using a tool like nmap/ndiff, nessus, or fscan on a regular basis.
• Port scans should cover all ports (1-65,535), both UDP and TCP, on all systems: both client and server devices such as routers, switches, printers, and anything else connected (physically through wire or wireless) to your network.

Nmap

Nmap is a Network MAPper. It is a powerful utility for network exploration or security auditing, which can rapidly scan large networks or single hosts to determine the hosts available on the network, the services they (ports) are offering, the operating system (and OS version) they are running, and the type of packet filters/firewalls in use. It runs on most types of computers, and both console and graphical versions are available. It is also a GNU GPL software, available with full source code.

Here are examples of Nmap usage:

1. This option scans all reserved TCP ports on the machine. The -v means turn on verbose mode.

nmap -v target.example.com

2. This launches a stealth SYN scan against each machine that is up out of the 255 machines on class ´C´ where target.example.com resides. It also tries to determine what operating system is running on each host that is up and running. This requires root privileges because of the SYN scan and the OS detection.

nmap -sS -O target.example.com/24

3. This sends a Xmas tree scan to the first half of each of the 255 possible 8-bit subnets in the 198.116 class ´B´ address space. We are testing whether the systems run sshd, DNS, pop3d, mapd, or port 4564. Note that Xmas scan does not work on Microsoft boxes due to their reduced TCP stack. The same goes with CISCO, IRIX, HP/UX, and BSD boxes.

nmap -sX -p 22,53,110,143,4564 198.116.*.1-127

4. Rather than focus on a specific IP range, it is sometimes interesting to slice up the entire Internet and scan a small sample from each slice. This command finds all web servers on machines with IP addresses ending in .2.3, .2.4, or .2.5.

nmap -v —randomize_hosts -p 80 ´*.*.2.3-5´

5. Launch a stealth scan with OS detection on all privileged ports against 255 hosts in the network, and then output the results into the file /root/nmap.scan.

nmap –sS –O 192.0.2.0/24 –oN /root/nmap.scan

6. Launch a stealth scan with OS detection on specified ports against 255 hosts in the network, in verbose mode.

nmap –sS –O –v 192.0.2.0/24 –p ‘1-1024,1080,3128’

Nessus

The mantra for network monitoring and scanning could be: ‘Prevention is ideal, but detection is a must’. We must realize that the no prevention technique is fool-proof and new vulnerabilities are discovered every week that you may not be aware of. Thus, constant vigilance is required to detect new unknown attacks. Once you are attacked, without logs, you have little chance of finding what the attackers did. It is also common sense that you cannot detect an attack if you do not know what is occurring on your network. Logs provide the details of what is occurring, what systems are being attacked, and what systems have been compromised. If any log entry does not look right, you should investigate them immediately. But thousands of lines of logs are produced every day. It is necessary to use the appropriate tools to diagnose these. It is also necessary for these logs and scans to be compared against vulnerability databases, so that the security gap in the network can be known immediately.

Nessus

Nessus is a security scanner that can remotely audit a given network or server. It can determine whether ‘crackers’ may break into it, or misuse your network or servers in some way.

Unlike others, Nessus does not take anything for granted and will not assume that services run only on fixed ports. For example, if you run your web server on port 1234, Nessus will detect it and test its security. It will not make its security tests by the version number, but will really attempt to exploit the vulnerability. It is very fast and reliable, and has a modular architecture that allows you to fit it to your needs. Nessus also has front ends for both Windows and Macintosh.

Nessus Installation

Nessus is made up of two parts: a client and a server. You need a UNIX -like system to use the server. In this test, the standard client Nessus is used, mainly because it supports the cipher layer. The Nessus Security Scanner relies on the following items:

• GTK - The Gimp Tool Kit, version 1.2

GTK is a set of Widgets (like Motif) which is used by many FOSS applications such as The Gimp.

GTK is used by the POSIX client Nessus.

Download it at ftp://ftp.gimp.org/pub/gtk/v1.2

Note #1: If your system comes with GTK, make sure that you have the gtk-config program installed.

If you do not, install the gtk-devel package that should come on your distribution CD-ROM.

Note #2: If you do not want to install GTK and/or if your system lacks X11, then you can compile a command-line client by doing .

/configure –disable-gtk

in nessus-core

• Nmap, which we already covered earlier, is an excellent port scanner. It is available at http://www.insecure.org/nmap/.
• OpenSSL (optional but heavily recommended) is used for the client-server communication as well as in the testing of SSL-enabled services. Get it at http://www.openssl.org.

Nessus also comes as a standalone package that auto-installs itself. To use it, download the script nessusinstaller. sh at http://www.nessus.org/download.html.

Using Nessus

Create a nessusd account

The nessusd server has its own user database, with each user having a set of restrictions. This allows you to share a single nessusd server for a whole network and different administrators who will only test their part of the network.

The utility nessus-adduser takes care of the creation of a new account:

# nessus-adduser

Using /var/tmp as a temporary file holder

Add a new nessusd user

Login: sunil

Authentication (pass/cert) [pass]:

Login password: nessus

User rules

nessusd has a rules system which allows you to restrict the hosts that Sunil has the right to test. For instance, you may want him to be able to scan his own host only.

Please see the nessus-adduser man page for the rules syntax. Enter the rules for this user, and hit ctrl-D once you are done: (the user can have an empty rules set)

Login: sunil

Password: nessus

DN:

Rules:

Is that ok? (y/n) [y]

User added.

Configure your Nessus daemon

In the file /usr/local/etc/nessus/nessusd.conf, you can set several options for nessusd. Typically, this is where you can define that you want nessusd to use your favourite language. The standard configuration file has been kept for this illustration.

Start nessusd

Once all of this is done, you can safely start nessusd as root:

nessusd -D

Fire up Nessus in X windows graphical environment

Click on Login, since this setup is correct. Since this is the first time you are connecting to this server, it will ask for the password. The next time you connect to it, the public key will be enough. Once connected, the Log-in button changes to Log-out, and a Connected label appears at its left.

The security checks configuration

Let all the security checks be performed, except the DoS attacks, because you do not want hosts to crash.

Clicking on a plugin name will pop up a window explaining what the plugin does.

The plugins preferences

Some security checks will require extra arguments. For instance, the pop2 overflow security test needs a valid pop account. The plugin, which tests whether an FTP directory is writeable or not, asks if it should just trust the permissions or really attempt to store a file.

The scan options

Here you choose which port scanner you want to use. Opt for the Nmap tcp connect scanner, since it is the fastest.

Define the targets

Uncheck the ‘Perform a DNS transfer zone’ option, since it would make DNS transfer on fr.nessus.org and nessus.org, and it would be useless, since it would not gain any new hosts.

Use the following options to define the targets:

192.0.2.1 A single IP address.

192.0.2.1-7 A range of IP addresses.

192.0.2.1-192.0.3.50 Another range of IP addresses.

192.0.2.1/29 Again a range of IP addresses in CIDR

prof.fr.nessus.org A hostname in FQDN notation.

prof A hostname (as long as it is resolvable on the server).

prof, 192.0.2.1/29, ... Any combination of the above mentioned forms separated by a comma.

The rules section

The rules allow a user to restrict his test. For instance, if you want to test 192.0.2.0/29, except 192.0.2.2. The rule set entered allows you to do that. Once all of this is done, start the scan.

The Nessus scan report

Now that the scan is over, the report window just pops up.

Resolving the security issues

Go through the scan report and try to resolve reported security holes on the respective servers by following the suggestions given in the report OR by referring to the vendor’s site.

Intrusion Detection System (IDS)

Intrusion detection is the art of detecting inappropriate, incorrect, or anomalous activity. IDS inspects/ sniffs all network traffic passing through it for any abnormal content. It has a built-in signature-base and anomaly detection, which provides the capability to look for set ‘patterns’ in packets. It can also string search signature (i.e., look for confidential information), log and TCP reset features. IDS provides worthwhile information about malicious network traffic and helps identify the source of incoming probes, scans, or attacks. It is similar to a security camera or a burglar alarm as it alerts security personnel that someone is picking the ‘lock’ – i.e., it alerts security personnel that a network invasion may be in progress.

SNORT

The most common FOSS IDS in use is SNORT.19 It does the following:

• Monitors network traffic for predefined suspicious activities or patterns
• Alerts system administrators when potential hostile traffic is detected
• Serves as a cross-platform, lightweight network intrusion detection tool
• Can be deployed to monitor small TCP/IP networks
• Detects a wide variety of suspicious network traffic as well as outright attacks
• Deployed rapidly to fill potential holes in a network’s security coverage

Three Modes of SNORT

Sniffer mode

Displays the packet headers or data

snort –v
snort –vd

Packet logger mode

Records packets to the disk

snort –dev –l ./log

snort -l ./log –b log all packets in binary mode

snort –dvr ./log/snort.log to display packets in ascii mode from the binary log

Network intrusion detection mode

Does not record every single packet sent down the wire

snort -d -h 192.0.2.0/24 -l ./log -c snort.conf

This will configure SNORT to run in its most basic NIDS mode, logging packets that the rules tell it to in plain ASCII to a hierarchical directory structure (just like the packet logger mode).

To send NIDS alerts to syslog use -s:

snort -s -h 192.0.2.0/24 –l ./log -c snort.conf

High Performance Configuration

snort -b -A fast -c snort.conf

This logs packets in tcpdump format and produces minimal alerts.

To read this file back and break out the data in the familiar SNORT format:

snort -d -c snort.conf -l ./log -h 192.0.2.0/24 -r snort.log

To run SNORT in daemon mode (provide full paths):

usr/local/bin/snort -d -h 192.0.2.0/24 -l /var/log/snortlogs -c /
usr/local/etc/snort.conf -s -D

To post packet logs to public mailing lists use –O to obfuscate your IP addresses

snort -d -v -r snort.log -O -h 192.0.2.0/24

To get help options:

snort –h

References

http://www.snort.org/docs/writing_rules/

http://www.snort.org/docs/lisapaper.txt

OpenSSH

One of the biggest advantages of UNIX and GNU/Linux is the ability to work remotely on the server systems. This feature is an inherent part of any UNIX-like operating system. In earlier days, most people used Telnet to log remotely into servers but now Telnet has been made obsolete by ssh or secure shell.

The main difference between Telnet and ssh is the secure communication protocol of the latter. In Telnet all of the communication was done in plain text, whereas in ssh all communication is encrypted.

OpenSSH is both an ssh server and client. It is installed by default on most GNU/Linux distributions. Since it even encrypts the password sent to set up the session, it effectively eliminates eavesdropping, connection hijacking, and other network-level attacks. It includes the following different server subsystems:

sshd – ssh daemon run on the server machine
sftp-server – sftp server sub-system
ssh-agent – authentication agent that holds the keys
ssh-add – used to register new keys with the Agent
ssh-keygen – used to create public authentication keys

OpenSSH Config Files

Since OpenSSH is both a client and a server, there are two configuration files for each purpose:

/etc/ssh/ssh_config – ssh client systemwide configuration file, provides defaults for users

/etc/ssh/sshd_config - sshd server system-wide configuration file

OpenSSH Server Configuration

Installation and basic operation

Install the openssh-server and openssh rpm package included in your Linux distribution. Most GNU/ Linux distributions will have the option to install OpenSSH. Please note that the openssh-server package depends on the openssh package. OpenSSH packages also require the OpenSSL package (openssl) which installs several important cryptographic libraries that help OpenSSH provide encrypted communications.

OpenSSH daemon, sshd, uses the configuration file ‘/etc/ssh/sshd_config’

The default config file is sufficient. For customization, refer to the sshd main page for config options.

Editing/viewing the sshd_config file

[root@mail /] # vi /etc/ssh/sshd_config

#Port 22 - Specifies the port number that sshd listens on

#Protocol 2,1 - Specifies the protocol versions sshd supports

#ListenAddress 0.0.0.0 - Specifies the local addresses sshd should listen on

#HostKey /etc/ssh/ssh_host_rsa_key - Specifies a file containing a private host key used by SSH

#SyslogFacility AUTH - Gives the facility code that is used when sshd logs messages

#LogLevel INFO - Gives the verbosity level that is used when sshd logs messages

#LoginGraceTime 600 – time limit for a user to log in

#PermitRootLogin yes - Specifies whether the root can login using ssh

#StrictModes yes - Specifies whether sshd should check file modes and ownership of the user’s files and home directory before accepting login

#PubkeyAuthentication yes - Specifies whether public key authentication is allowed

#PasswordAuthentication yes - Specifies whether password authentication is allowed

#PermitEmptyPasswords no - When password authentication is allowed, it specifies whether the server allows login to accounts with empty password strings

#MaxStartups 10 - Specifies the maximum number of concurrent unauthenticated connections to the sshd daemon

#KeepAlive yes - Specifies whether the system should send TCP keepalive messages to the other side

#VerifyReverseMapping no - Specifies whether sshd should try to verify the remote host name

Subsystem sftp /usr/libexec/opensshsftp-server

Managing the sshd service

To start the service: #/etc/rc.d/init.d/ sshd start

To stop the service: #/etc/rc.d/init.d/ sshd stop

To restart the service: #/etc/rc.d/init.d/ sshd restart

To automatically run the service: # chkconfig sshd on

OpenSSH Client Configuration

To connect to an OpenSSH server from a client machine, you must have the openssh-clients and openssh packages installed on the client machine.

System-wide ssh client configuration is stored in /etc/ssh_config and is used as the default for all systemwide users.

The configuration values can be changed in per user configuration files or on the command line. The default home directory is ~/.ssh

Using the ssh with password authentication

1. Make sure you have the following enabled in /etc/sshd_config file on the ssh server

PasswordAuthentication yes

2. To log in to a host named server.com, type the following:

$ ssh gaurab@server.com

The first time you ssh to a remote machine, you will see a message similar to the following:

The authenticity of host ‘server.com (192.0.2.22)’ can’t be established.
RSA key fingerprint is
0f:41:6c:52:31:59:43:0f:dd:49:5f:3d:47:9d:b5:9e.
Are you sure you want to continue connecting (yes/no)? yes

Type yes to continue.
This will add the server to your list of known hosts as seen in the following message:

Warning: Permanently added ‘server.com,192.0.2.22’ (RSA) to the list of knownhosts.
gaurab@server.com’s password:
Last login: Sat Oct 16 19:34:13 2004 from gw-ktm.lahai.com
[gaurab@server.com gaurab]$

3. known_hosts file in .ssh folder contains the remote servers’ host keys:

$ more known_hosts
server.com,192.0.2.22 ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEA5IwKqHiqSeXjrX3dCpS1gXZo9GqJ0hkk+clf+WmABYbEH6IGMyy2CeA
RtaR6QLpqB1SaGEFsn84dqA6kWLYfn4FuDVDc8KTyABLVEMOm6NnLZkHPKr3Cb0RgivDYSYHlwgWu
Di7XBvmoC44WA2EbM7eBy5h1kHrXZ5yPXq3rxI0=

Using the ssh command with public key authentication

1. Make sure you have the following enabled in /etc/sshd_config file on the ssh server.

PubkeyAuthentication yes

2. Key pair generation:

ssh-keygen - authentication key generation, management and conversion

To generate a RSA key pair to work with version 2 of the protocol:

$ ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter the file in which to save the key (/home/gaurab/.ssh/id_rsa):

Enter a passphrase that is different from your account password and confirm it by entering it again:
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Your identification has been saved in /home/gaurab/.ssh/id_rsa.
Your public key has been saved in /home/gaurab/.ssh/id_rsa.pub.
The key fingerprint is:
e5:a1:ac:ce:8d:16:3a:b9:3a:e4:e9:06:9c:90:b6:da gaurab@lahai.com

The public key is written to ~/.ssh/id_rsa.pub.
The private key is written to ~/.ssh/id_rsa.
Never distribute your private key to anyone and change the permissions of your .ssh directory using the command chmod 755 ~/.ssh

$ ll .ssh/
total 8
-rw——— 1 gaurab gaurab 951 Oct 16 19:37 id_rsa
-rw-r—r— 1 gaurab gaurab 236 Oct 16 19:37 id_rsa.pub

Copy the contents of ~/.ssh/id_rsa.pub to ~/.ssh/authorized_keys on the machine to which you want to connect.

If the file ~/.ssh/authorized_keys does not exist, you can copy the file ~/.ssh/id_rsa.pub to the file ~/.ssh/authorized_keys on the remote SSH server.

Securely copy your public key file to the remote ssh server:

$ scp ~/.ssh/id_rsa.pub gaurab@server.com:

Logon to the remote ssh server using password authentication, one more time:

$ ssh gaurab@server.com

Copy the content of the public key file to authorized_keys file on the remote host:

$ cat id_rsa.pub >> ~/.ssh/authorized_keys

Now, logon to the remote ssh server via public key authentication:

$ ssh gaurab@server.com

Enter passphrase for key ‘/home/gaurab/.ssh/id_rsa’:
Last login: Sat Oct 16 19:40:11 2004 from myhost.com
[gaurab@server.com gaurab]$

To run a command on the remote host with ssh and exit:

$ ssh ns.lahai.com ls /usr/share/doc

Using the scp command

The scp command is used to transfer files between machines over a secure, encrypted connection.

To transfer the local file shadowman to /home/username/shadowman on penguin.example.net:

$ scp shadowman username@penguin.example.net:/home/username

To transfer a remote file to the local system:

$ scp username@tohostname:/remotefile /newlocalfile

To transfer the contents of the directory /downloads to an existing directory called “uploads” on the remote machine penguin.example.net:

$ scp /downloads/* username@penguin.example.net:/uploads/

Using the sftp command

The sftp command is used to open a secure, interactive FTP session via an encrypted channel.

$ sftp username@hostname.com

Once authenticated, you can use a set of commands similar to using FTP.