1

TERM PAPER
OF
COMPUTER
NETWORK

TOPIC: NETWORK SECURITY IN

LINUX

SUBMITTED TO: - SUBMITTED BY:-

MS.CHAVI RALHAN VISHAL PATYAL

ROLL NO. 03

CLASS:-BT MT CSE

SECTION- C
 2

REG. NO:-3050060122

Acknowledgements:-
First of all I would like to express my sincere
gratitude to the almighty for encouraging me to
complete this term paper. The following are
some important people in my life who gave me
strength and valuable suggestions to complete
the task.
First, my parents, friends, whose love and
affection give me strength and encouragement
to face challenges of life.
Second, my mam Chavi Ralhan, whose
inspiration, motivation spiritual guidance
always keeps me in the right path and keeps my
faith in God almighty without whose blessings
nothing is possible.
Finally, thanks for the Lovely Professional
University which gave me great opportunity to
make the term paper.
 3

Table of contents:-

Linux Server and Network Security in Linux

Application Configuration
Linux System Administration

Networ k Security

8.1. Packet Sniffers

8.2. System services and tcp_wrappers

8.3. Verify Your DNS Information

8.4. identd

8.5. Configuring and Securing the Postfix MTA

8.6. SATAN, ISS, and Other Network Scanners

8.6.1. Detecting Port Scans

8.7. Send mail, gmail and MTA's

8.8. Denial of Service Attacks

8.9. NFS (Network File System) Security.

8.10. NIS (Network Information Service) (formerly YP).

8.11. Firewalls

8.12. IP Chains - Linux Kernel 2.2.x Firewalling

8.13. Net filter - Linux Kernel 2.4.x Firewalling

8.14. VPNs - Virtual Private Networks

 4

References.

Linux Server and Network

Security in Linux
The most dangerous threat to internal networks are Internet gateways.
Gateways are systems (or other hardware devices) with a minimum of two
network interfaces where one interface is connected to the Internet (via an
ISP connection) and at least one interface is connected to an internal LAN
segment. Just as a gateway allows traffic to go out from your LAN onto the
Internet, it also allows traffic from the Internet onto your LAN. The trick is to
only let the traffic you want onto your LAN, and it's no easy feat.
You could be legally liable if someone hacks their way into your LAN and
steals confidential data (social security numbers, credit card numbers, etc)
that you maintain on your clients or customers. Worms or trojans could be
planted that send passwords or other sensitive information out onto the
Internet to a waiting sniffer. The risks are many and the consequences
could threaten the very existance of your company. It's not uncommon for
large institutions like banks and insurance firms to decline pressing charges
against a hacker simply because they don't want the negative press and
loss of confidence they would suffer as the result of a public prosecution by
a district attorney.
"Multi-homed" (multi-connection) systems such as gateways are not the
only security risk. A server that is only connected to the Internet, such as a
Web server, is also at risk of being hacked. You may not care if some
hacker cracks his way in and defaces your Web pages. You just reload the
pages. But there are other, more hideous, attacks that are not uncommon:

• Your server can be used as a base from which attacks on other

systems can be launched.
• Your e-mail server could be used as a relay for spammers.
• Your system can be surreptitiously used as an IRC (chat) server or
for some other band-width intensive application that steals
performance from both your server and your Internet connection.
• Your could be the target of DOS (Denial of Service) attacks which
renders your servers (e-mail or Web), and your Internet connection,
useless.
 5

• Internet servers that use SSL to collect sensitive information such as

credit card numbers or account numbers and passwords can be
targets of hackers in order to try and gain access to the devices
where this data is stored. (SSL only protects in-transit HTTP traffic. It
does nothing for operating system or server security.)

Addressing security issues is one of those cases where "an ounce of

prevention is worth a pound of cure". A hacker could do untold damage if
they get into your system or network. And because hackers learn their
trade in underground electronic communities, if one finds a way into your
system you can bet that they'll let everyone else know about it.

Security measures can be categorized into the following four broad

classifications:

1. OS configuration - "hardening" the operating system

2. Application configuration - making sure the server applications you
do make available do only what they're supposed to do
3. Perimeter security - configuring your network infrastructure with
firewalls and DMZs
4. Physical security - only authorized users and systems should have
access to the network infrastructure

Different publications may categorize things differently but that's of little

consequence. The important thing is that doing so allows you to take a
"divide and conquer" approach to addressing all of the various aspects
involved in securing a network, its servers, and the information contained
on them.

OS Configuration :

Hardening the operating system involves many things are are not only
operating system-specific, but may often vary from one "flavor" of an
operating system to another. Typical steps include:

• Disabling all default accounts and groups that are not needed. When
an operating system is installed it sets up quite a few user accounts
 6

and groups by default. (Try logging into your Debian system using the
username news and see how far you can navigate around your
system's file system and what files you can catto the screen.)
There's a line in the /etc/passwd file for each user. Each line
contains different pieces of info separated by colons (:) with the last
item being the user's default shell (typically the Bash shell). To
disable user accounts, just change the default shell
to /bin/false so they can't log in.

• Change your startup configuration so that only necessary services

are running. Many services open TCP/IP "ports" which hackers find
when running port scans against systems. (Many applications are
responsible for starting services also.) Closing all unnecessary ports
is a common practice. You can run a port scanner from another
system against your server to see which ports are open.

• Configure file system security (using

the chmod and chown commands) so that only the bare minimum
of access to files and directories is allowed.

• Utilize strong (mixed case, alpha-numberic, long) passwords on

accounts that are necessary.

• Don't use common names for groups that are given high levels
access (ex: "admins").

• Use TCP wrappers (tcpd) to run Internet-related daemons and

properly configure the hosts.allow and hosts.deny files to
restrict access.

• Don't run a GUI if you don't need one and never leave a GUI running
while the server isn't being used for an interactive console session.

• Log off of server consoles when they're not being used. This is
especially important for Internet-connected systems.
 7

ApplicationConfiguration

Some applications are insecure due to the defaults used during their
installations and some are just inherently insecure. Telnet and ftp are two
inherently insecure applications because passwords are transmitted over
the wire as clear text.

The biggest threat to many applications is their vulnerability to "buffer

overflow" attacks which usually results in the hacker having access to the
system with the rights of whatever user account the application was
running under.

The following are some general guidelines related to applications:

• Use more secure equivalents for insecure applications (ex: ssh

instead of telnet, sudo in place of su, etc).

• Keep your applications up-to-date with the latest versions. Many

releases are specifically developed to address security issues.

• Determine which ports an application opens up and see if they are

absolutely necessary. If they aren't, shut them down.

• Check the application vendor's Web site for information on how to

make the application more secure and for any news items and or
patches that address newly-discovered security vulnerabilities.

• If you have a Web server, learn proper programming techniques to

ensure that CGI scripts are secure and make sure the scripts you use
utilize these techniques. Also acquaint yourself with the security
issues related to Server Side Includes and any Web site interpreters
you may be running (such as PHP or ASP).

• In the case of a Web server, if Web page updates are fairly

infrequent, you could just edit the pages on the server using a text
editor or use a floppy disk to "sneaker-net" the updated HTML files by
mounting the floppy disk, copying the files into the Document Root
directory, and then unmounting the floppy. Either of these would
 8

eliminate the need to run an ftp server service and enabling an

account for the person who maintains the pages.

• If you have an Apache Web server (or have a Web site that is hosted
on a shared Apache Web server) and the US government's Titan
Rain investigation has you considering blocking visitors from China
(which we are now doing), you can configure Apache to deny access
to your site from Chinese IP addresses .
• Searching Google for the name of the application along with the word
'harden' will usually yield some helpful configuration information.
If all you want to do is set up a simple Web server (running Apache)
then there are quite a few "applications" (OS utilities actually) that run
by default that are not needed. They open ports and since each open
port is a possible entry point into your server by a hacker, you don't
want them open. I disable them by renaming their 'S' (startup)
symlinks in the appropriate run level directory. Since Debian boots
into runlevel 2 by default, we want to go into the run level 2 startup
directory with the command:

Now if you again reboot your system and run the netstat -a command
you'll see only Apache has a port open.
Other daemons and services don't open ports but they're not needed either
and they just use up memory. Two examples in the default installation that
you can also rename are S89atd and, if your system isn't connected
directly to a cable or DSL modem that uses PPPoE, S14ppp.
Because applications interact with the operating system, start processes,
and accept input they can affect operating system security. Likewise,
operating system security can affect an application's ability to function
properly. Achieving maximum OS security while still retaining full
application functionality is a balancing act.

This balancing act is evident when using "jails" or chroot jails. You can put
any program or daemon in it's own jail. A chroot jail is a way of configuring
the operating system so that the directory the application is running from
appears to be the root of the entire file system. As such, the only directories
the application can "see" or has access to are the ones it needs to run.
That way, if an application does have a security flaw, the hacker exploiting
that flaw won't have access to the entire file system.
 9

For example, if you want to set up a DNS server be advised that BIND runs
as root. As such, if a hacker exploited a security flaw in BIND they would
have root access to the entire file system. By running BIND in a jail, the
hacker would only have access to the BIND application directory.

Perimeter Security

The most common means of protecting a network is using a firewall (or two
in the case of a DMZ which was illustrated back on the Firewall page). The
biggest problem with firewalls is that people think they're more than they
actually are. A firewall's major strength is protecting against traffic-based
attacks (DoS, etc). If you let people into your network from the outside, the
firewall has no way of differentiating between a legitimate user and a
hacker. A firewall is not a substitute for strong OS and application security.

If you're going to use a firewall package on a Debian system, keep in mind

that the firewall is the application. As such, a system-based firewall won't
offer much security if the underlying OS isn't hardened. (This is why the
NetMax commercial firewall product includes the OS piece. It allows them
to ensure the OS is properly configured.)

If you want to have Internet servers or provide remote access using a VPN
server, be sure to use a DMZ configuration with two firewalls. In cases
where critical or confidential business information is at risk, use stateful
firewalls and IDS (Intrusion Detection System) software.

Snort

Snort is a commonly-used free IDS software package and setting it up is

easy. If you're going to set up a Snort box inside your DMZ you'll want to
make sure that the system is locked down (OS and application
configurations) as tight as possible. Installing Snort is simply a matter of
entering the command:

apt-get install snort

Once the packages are downloaded the configuration starts automatically.

 10

• Select the ethernet interface you'd like Snort to listen on.

• Enter the network information for the DMZ network that the Snort
system will be on. This consists of the network (wire) address and the
subnet mask in bitmask notation (ex: '192.168.1.0/24').
• If you're just playing around with Snort you can blank out the recipient
for daily e-mails. Otherwise enter an e-mail address.

Again, firewalls, DMZs, and IDS systems are not magic bullets. They can
detect certain traffic patterns and pass or block traffic within certain
parameters. However, they can't tell a legitimate remote user from a
hacker. A firewall compliments good OS and application security practices,
it doesn't replace them nor can it make up for weaknesses in them.

Be Proactive:-

Security is not a "set it and forget it" proposition. Because there are no
absolutes, constant monitoring is essential. New attacks are being
developed every day and if you're simply going to respond once an attack
is discovered it's likely too late. Hackers will use DoS attacks, log
alterations (provided they can gain access), and other means to disguise
other, more intrusive, exploits. In many cases simply waiting for obvious
evidence that you've been hacked means you'll never know you've been
hacked. The hackers will sneak in, grab what they want, and sneak back
out again covering their tracks as they go.

In short, any security plan that is reactive rather than proactive is pretty
lame. In addition to the security measures mentioned above, there are
several things you can do to be more proactive in ensuring security:

• Monitor log files - By routinely monitoring system and application log

files you get to know what's "normal" which makes it easier to spot
things that JDLR (just don't look right). If you can afford the disk real
 11

estate, set up applications where logging configurations are allowed

(like Apache) to log as much information as possible.

• Set up an Intrusion Detection System like Snort and have it monitor

your DMZ. If you have an e-mail enabled pager or cell phone you can
configure the IDS software to send any alerts to it so you'll know
immediately if someone is snooping around your systems.

• Hack your systems - Obtain, learn, and use some of the same tools
the hackers do. By doing so you'll see what the hackers see, which
could be an eye-opening experience.

• As mentioned earlier, if you've got an available public address, set up

a honey-pot system and monitor it on a frequent basis. You can use
the same hacker tools against it and compare the results with those
you found on your production systems.

• Got to www.cert.org and subscribe to their e-mail notifications. They

do a great job of getting the word out on newly discovered
weaknesses in operating systems or applications, often before any
exploits of those weaknesses have been reported. They also include
information on what to do about the weakness.

• Because Debian is free and the hardware requirements are so light,

set up a hardened system as a standby. That way if one of your
firewall or application server systems takes a dump you can configure
the standby to take it's place a lot quicker than trying to figure out
what happened to the system that's down and trying to fix the
problem. When you're in a rush to get a system back on line some
security measures may be passed over for the sake of expediency. If
all of your systems, including the standby, are the same, you can
simply restore a backup from the failed system to the standby system
to get the security and application-specific information applied and be
up and running in a matter of minutes.

Linux System Administration

 12

Many people find Linux far easier to install, configure, and

administer than proprietary operating systems. It is so reliable
that once it is up, it requires almost no effort at all to maintain.
Linux systems typically go 3-12 months without requiring any
maintenance or even reboots!

Because of this ease-of-use, many small organizations find it

cost-effective to hire us to do the initial configuration and the
occasional maintenance of their Linux and Unix systems. This
occasional maintenance usually is to change configurations, add
services, or apply updates. Many clients opt to have us apply
security patches as soon as they come out, for maximum
security.

A small monthly charge takes the time and hassle out of your
staff worrying about this. The sad fact is that most SysAdmins
simply do not bother to worry about these security patches,
resulting in an insecure system, due to lack of time.

Linux is the most popular web server on the Internet because of

its reliability, ease-of-use, security, capability, and low cost. A
Linux system using the Apache web server offers all of the useful
capability that might be found in proprietary servers and works
well with Internet Explorer, Netscape, and Opera browsers.

The staff at Horizon Network Security can install Linux systems to

act as a firewall, web, email, and DNS server in organizations
that are otherwise all Windows. This solves the security and
reliability problems that many experience. Linux also can provide
network-attached disk servers and print servers to Windows and
Mac desktop systems. Many organizations are finding that Linux
makes excellent servers to their Windows and Mac desktop client
systems.

Networ k Security:-

Network security is becoming more and more important as people spend more and
more time connected. Compromising network security is often much easier than
compromising physical or local security, and is much more common.
 13

There are a number of good tools to assist with network security, and more and
more of them are shipping with Linux distributions.

8.1. Packet Sniffers

One of the most common ways intruders gain access to more systems on your
network is by employing a packet sniffer on a already compromised host. This
"sniffer" just listens on the Ethernet port for things
like passwd and login and su in the packet stream and then logs the traffic
after that. This way, attackers gain passwords for systems they are not even
attempting to break into. Clear-text passwords are very vulnerable to this attack.

Example: Host A has been compromised. Attacker installs a sniffer. Sniffer picks
up admin logging into Host B from Host C. It gets the admins personal password
as they login to B. Then, the admin does a su to fix a problem. They now have the
root password for Host B. Later the admin lets someone telnet from his account
to Host Z on another site. Now the attacker has a password/login on Host Z.

In this day and age, the attacker doesn't even need to compromise a system to do
this: they could also bring a laptop or pc into a building and tap into your net.

Using ssh or other encrypted password methods thwarts this attack. Things like
APOP for POP accounts also prevents this attack. (Normal POP logins are very
vulnerable to this, as is anything that sends clear-text passwords over the network.)

8.2. System services and tcp_wrappers

Before you put your Linux system on ANY network the first thing to look at is what
services you need to offer. Services that you do not need to offer should be
disabled so that you have one less thing to worry about and attackers have one less
place to look for a hole.

There are a number of ways to disable services under Linux. You can look at
your /etc/inetd.conf file and see what services are being offered by
your inetd. Disable any that you do not need by commenting them out (# at the
beginning of the line), and then sending your inetd process a SIGHUP.

You can also remove (or comment out) services in your /etc/services file.
This will mean that local clients will also be unable to find the service (i.e., if you
remove ftp, and try and ftp to a remote site from that machine it will fail with an
 14

"unknown service" message). It's usually not worth the trouble to remove services
from /etc/services, since it provides no additional security. If a local person
wanted to use ftp even though you had commented it out, they would make their
own client that used the common FTP port and would still work fine.

Some of the services you might want to leave enabled are:

• ftp
• telnet (or ssh)
• mail, such as pop-3 or imap
• identd

If you know you are not going to use some particular package, you can also delete
it entirely. rpm -e packagename under the Red Hat distribution will erase an
entire package. Under Debian dpkg --remove does the same thing.

Additionally, you really want to disable the rsh/rlogin/rcp utilities, including login
(used by rlogin), shell (used by rcp), and exec (used by rsh) from being
started in /etc/inetd.conf. These protocols are extremely insecure and have
been the cause of exploits in the past.

You should check /etc/rc.d/rc[0-9].d (on Red Hat; /etc/rc[0-

9].d on Debian), and see if any of the servers started in those directories are not
needed. The files in those directories are actually symbolic links to files in the
directory /etc/rc.d/init.d (on Red Hat; /etc/init.d on Debian).
Renaming the files in the init.d directory disables all the symbolic links that
point to that file. If you only wish to disable a service for a particular run level,
rename the appropriate symbolic link by replacing the upper-case S with a lower-
case s, like this:

root# cd /etc/rc6.d
root# mv S45dhcpd s45dhcpd

If you have BSD-style rc files, you will want to check /etc/rc* for programs
you don't need.

Most Linux distributions ship with tcp_wrappers "wrapping" all your TCP
services. A tcp_wrapper (tcpd) is invoked from inetd instead of the real
server. tcpd then checks the host that is requesting the service, and either
 15

executes the real server, or denies access from that host. tcpd allows you to
restrict access to your TCP services. You should make
a /etc/hosts.allow and add in only those hosts that need to have access to
your machine's services.

If you are a home dial up user, we suggest you deny ALL. tcpd also logs failed
attempts to access services, so this can alert you if you are under attack. If you add
new services, you should be sure to configure them to use tcp_wrappers if they are
TCP-based. For example, a normal dial-up user can prevent outsiders from
connecting to his machine, yet still have the ability to retrieve mail, and make
network connections to the Internet. To do this, you might add the following to
your /etc/hosts.allow:

ALL: 127.

And of course /etc/hosts.deny would contain:

ALL: ALL

which will prevent external connections to your machine, yet still allow you from
the inside to connect to servers on the Internet.

Keep in mind that tcp_wrappers only protects services executed from inetd, and
a select few others. There very well may be other services running on your
machine. You can use netstat -ta to find a list of all the services your
machine is offering.

8.3. Verify Your DNS Information

Keeping up-to-date DNS information about all hosts on your network can help to
increase security. If an unauthorized host becomes connected to your network, you
can recognize it by its lack of a DNS entry. Many services can be configured to not
accept connections from hosts that do not have valid DNS entries.

8.4. identd
 16

identd is a small program that typically runs out of your inetd server. It keeps
track of what user is running what TCP service, and then reports this to whoever
requests it.

Many people misunderstand the usefulness of identd, and so disable it or block

all off site requests for it. identd is not there to help out remote sites. There is no
way of knowing if the data you get from the remote identd is correct or not.
There is no authentication in identd requests.

Why would you want to run it then? Because it helps you out, and is another data-
point in tracking. If your identd is un compromised, then you know it's telling
remote sites the user-name or uid of people using TCP services. If the admin at a
remote site comes back to you and tells you user so-and-so was trying to hack into
their site, you can easily take action against that user. If you are not
running identd, you will have to look at lots and lots of logs, figure out who was
on at the time, and in general take a lot more time to track down the user.

The identd that ships with most distributions is more configurable than many
people think. You can disable it for specific users (they can make
a .noident file), you can log all identd requests (We recommend it), you can
even have identd return a uid instead of a user name or even NO-USER.

8.5. Configuring and Securing the Postfix MTA

The Postfix mail server was written by Wietse Venema, author of Postfix and
several other staple Internet security products, as an "attempt to provide an
alternative to the widely-used Sendmail program. Postfix attempts to be fast, easy
to administer, and hopefully secure, while at the same time being sendmail
compatible enough to not upset your users."

Further information on postfix can be found at the Postfix home and in

the Configuring and Securing Postfix.

8.6. SATAN, ISS, and Other Network Scanners

There are a number of different software packages out there that do port and
service-based scanning of machines or networks. SATAN, ISS, SAINT, and
Nessus are some of the more well-known ones. This software connects to the target
machine (or all the target machines on a network) on all the ports they can, and try
 17

to determine what service is running there. Based on this information, you can tell
if the machine is vulnerable to a specific exploit on that server.

SATAN (Security Administrator's Tool for Analyzing Networks) is a port scanner

with a web interface. It can be configured to do light, medium, or strong checks on
a machine or a network of machines. It's a good idea to get SATAN and scan your
machine or network, and fix the problems it finds. Make sure you get the copy of
SATAN from metalab or a reputable FTP or web site. There was a Trojan copy of
SATAN that was distributed out on the
net. http://www.trouble.org/~zen/satan/satan.html. Note that SATAN has not been
updated in quite a while, and some of the other tools below might do a better job.

ISS (Internet Security Scanner) is another port-based scanner. It is faster than

Satan, and thus might be better for large networks. However, SATAN tends to
provide more information.

Abacus is a suite of tools to provide host-based security and intrusion detection.

Look at it's home page on the web for more
information. http://www.psionic.com/abacus/

SAINT is a updated version of SATAN. It is web-based and has many more up-to-
date tests than SATAN. You can find out more about it
at: http://www.wwdsi.com/~saint

8.6.1. Detecting Port Scans

There are some tools designed to alert you to probes by SATAN and ISS and other
scanning software. However, if you liberally use tcp_wrappers, and look over your
log files regularly, you should be able to notice such probes. Even on the lowest
setting, SATAN still leaves traces in the logs on a stock Red Hat system.

There are also "stealth" port scanners. A packet with the TCP ACK bit set (as is
done with established connections) will likely get through a packet-filtering
firewall. The returned RST packet from a port that _had no established
session_ can be taken as proof of life on that port. I don't think TCP wrappers will
detect this.

You might also look at SNORT, which is a free IDS (Intrusion Detection System),
which can detect other network intrusions. http://www.snort.org
 18

8.7. send mail, qmail and MTA's

One of the most important services you can provide is a mail server. Unfortunately,
it is also one of the most vulnerable to attack, simply due to the number of tasks it
must perform and the privileges it typically needs.

If you are using send mail it is very important to keep up on current

versions. send mail has a long long history of security exploits. Always make
sure you are running the most recent version fromhttp://www.sendmail.org.

Keep in mind that send mail does not have to be running in order for you to send
mail. If you are a home user, you can disable send mail entirely, and simply use
your mail client to send mail. You might also choose to remove the "-bd" flag from
the send mail startup file, thereby disabling incoming requests for mail. In other
words, you can execute send mail from your startup script using the following
instead:

# /usr/lib/sendmail -q15m

This will cause send mail to flush the mail queue every fifteen minutes for any
messages that could not be successfully delivered on the first attempt.

Many administrators choose not to use send mail, and instead choose one of the
other mail transport agents. You might consider switching over
to qmail. qmail was designed with security in mind from the ground up. It's
fast, stable, and secure. Qmail can be found at http://www.qmail.org

In direct competition to qmail is "postfix", written by Wietse Venema, the author

of tcp_wrappers and other security tools. Formerly called vmailer, and sponsored
by IBM, this is also a mail transport agent written from the ground up with security
in mind. You can find more information about postfix at http://www.postfix.org

8.8. Denial of Service Attacks

A "Denial of Service" (DoS) attack is one where the attacker tries to make some
resource too busy to answer legitimate requests, or to deny legitimate users access
to your machine.

Denial of service attacks have increased greatly in recent years. Some of the more
popular and recent ones are listed below. Note that new ones show up all the time,
 19

so this is just a few examples. Read the Linux security lists and the bugtraq list and
archives for more current information.

• SYN Flooding - SYN flooding is a network denial of service attack. It takes

advantage of a "loophole" in the way TCP connections are created. The
newer Linux kernels (2.0.30 and up) have several configurable options to
prevent SYN flood attacks from denying people access to your machine or
services. See Section 7 for proper kernel protection options.
• Pentium "F00F" Bug - It was recently discovered that a series of assembly
codes sent to a genuine Intel Pentium processor would reboot the machine.
This affects every machine with a Pentium processor (not clones, not
Pentium Pro or PII), no matter what operating system it's running. Linux
kernels 2.0.32 and up contain a work around for this bug, preventing it from
locking your machine. Kernel 2.0.33 has an improved version of the kernel
fix, and is suggested over 2.0.32. If you are running on a Pentium, you
should upgrade now!
• Ping Flooding - Ping flooding is a simple brute-force denial of service
attack. The attacker sends a "flood" of ICMP packets to your machine. If
they are doing this from a host with better bandwidth than yours, your
machine will be unable to send anything on the network. A variation on this
attack, called "smurfing", sends ICMP packets to a host with your machine's
return IP, allowing them to flood you less detectably. If you are ever under a
ping flood attack, use a tool like tcpdump to determine where the packets
are coming from (or appear to be coming from), then contact your provider
with this information. Ping floods can most easily be stopped at the router
level or by using a firewall.
• Ping o' Death - The Ping o' Death attack sends ICMP ECHO REQUEST
packets that are too large to fit in the kernel data structures intended to store
them. Because sending a single, large (65,510 bytes) "ping" packet to many
systems will cause them to hang or even crash, this problem was quickly
dubbed the "Ping o' Death." This one has long been fixed, and is no longer
anything to worry about.
• Teardrop / New Tear - One of the most recent exploits involves a bug
present in the IP fragmentation code on Linux and Windows platforms. It is
fixed in kernel version 2.0.33, and does not require selecting any kernel
compile-time options to utilize the fix. Linux is apparently not vulnerable to
the "new tear" exploit.

8.9. NFS (Network File System) Security.

 20

NFS is a very widely-used file sharing protocol. It allows servers

running nfsd and mounted to "export" entire file systems to other machines
using NFS filesystem support built in to their kernels (or some other client support
if they are not Linux machines). mounted keeps track of mounted file systems
in /etc/mtab, and can display them with showmount.

Many sites use NFS to serve home directories to users, so that no matter what
machine in the cluster they login to, they will have all their home files.

There is some small amount of security allowed in exporting file systems. You can
make your nfsd map the remote root user (uid=0) to the nobody user, denying
them total access to the files exported. However, since individual users have access
to their own (or at least the same uid) files, the remote root user can login or su to
their account and have total access to their files. This is only a small hindrance to
an attacker that has access to mount your remote file systems.

If you must use NFS, make sure you export to only those machines that you really
need to. Never export your entire root directory; export only directories you need
to export.

8.10. NIS (Network Information Service).

Network Information service (formerly YP) is a means of distributing information

to a group of machines. The NIS master holds the information tables and converts
them into NIS map files. These maps are then served over the network, allowing
NIS client machines to get login, password, home directory and shell information
(all the information in a standard /etc/passwd file). This allows users to
change their password once and have it take effect on all the machines in the NIS
domain.

NIS is not at all secure. It was never meant to be. It was meant to be handy and
useful. Anyone that can guess the name of your NIS domain (anywhere on the net)
can get a copy of your passwd file, and use "crack" and "John the Ripper" against
your users' passwords. Also, it is possible to spoof NIS and do all sorts of nasty
tricks. If you must use NIS, make sure you are aware of the dangers.
 21

8.11. Firewalls

Firewalls are a means of controlling what information is allowed into and out of
your local network. Typically the firewall host is connected to the Internet and
your local LAN, and the only access from your LAN to the Internet is through the
firewall. This way the firewall can control what passes back and forth from the
Internet and your LAN.

There are a number of types of firewalls and methods of setting them up. Linux
machines make pretty good firewalls. Firewall code can be built right into 2.0 and
higher kernels. The user-space toolsipfwadm for 2.0 kernels and ipchains for
2.2 kernels, allows you to change, on the fly, the types of network traffic you
allow. You can also log particular types of network traffic.

Firewalls are a very useful and important technique in securing your network.
However, never think that because you have a firewall, you don't need to secure
the machines behind it. This is a fatal mistake. Check out the very
good Firewall-HOWTO at your latest metalab archive for more information on
firewalls and Linux.

If you have no experience with firewalls, and plan to set up one for more than just
a simple security policy, the Firewalls book by O'Reilly and Associates or other
online firewall document is mandatory reading.

8.12. IP Chains - Linux Kernel 2.2.x Firewalling

Linux IP Firewalling Chains is an update to the 2.0 Linux firewalling code for the
2.2 kernel. It has many more features than previous implementations, including:

• More flexible packet manipulations

• More complex accounting
• Simple policy changes possible atomically
• Fragments can be explicitly blocked, denied, etc.
• Logs suspicious packets.
• Can handle protocols other than ICMP/TCP/UDP.

If you are currently using ipfwadm on your 2.0 kernel, there are scripts available
to convert the ipfwadm command format to the format ipchains uses.
 22

8.13. Netfilter - Linux Kernel 2.4.x Firewalling

In yet another set of advancements to the kernel IP packet filtering code, netfilter
allows users to set up, maintain, and inspect the packet filtering rules in the new
2.4 kernel.

The net filter subsystem is a complete rewrite of previous packet filtering

implementations including ipchains and ipfwadm. Net filter provides a large
number of improvements, and it has now become an even more mature and robust
solution for protecting corporate networks.

Iptables

is the command-line interface used to manipulate the firewall tables within the
kernel.

Net filter provides a raw framework for manipulating packets as they traverse
through various parts of the kernel. Part of this framework includes support for
masquerading, standard packet filtering, and now more complete network address
translation. It even includes improved support for load balancing requests for a
particular service among a group of servers behind the firewall.

The stateful inspection features are especially powerful. Stateful inspection

provides the ability to track and control the flow of communication passing
through the filter. The ability to keep track of state and context information about a
session makes rules simpler and tries to interpret higher-level protocols.

Additionally, small modules can be developed to perform additional specific

functions, such as passing packets to programs in userspace for processing then
reinjecting back into the normal packet flow. The ability to develop these programs
in userspace reduces the level of complexity that was previously associated with
having to make changes directly at the kernel level.

Other IP Tables references include:

 23

• Oskar Andreasson IP Tables Tutorial -- Oskar Andreasson speaks with

LinuxSecurity.com about his comprehensive IP Tables tutorial and how this
document can be used to build a robust firewall for your organization.
• Hal Burgiss Introduces Linux Security Quick-Start Guides -- Hal Burgiss
has written two authoritative guides on securing Linux, including managing
firewalling.
• Net filter Homepage -- The net filter/iptables homepage.
• Linux Kernel 2.4 Firewalling Matures: net filter -- This LinuxSecurity.com
article describes the basics of packet filtering, how to get started using
pintables, and a list of the new features available in the latest generation of
firewalling for Linux.

8.14. VPNs - Virtual Private Networks

VPN's are a way to establish a "virtual" network on top of some already-existing

network. This virtual network often is encrypted and passes traffic only to and
from some known entities that have joined the network. VPNs are often used to
connect someone working at home over the public Internet to an internal company
network.

If you are running a Linux masquerading firewall and need to pass MS PPTP
(Microsoft's VPN point-to-point product) packets, there is a Linux kernel patch out
to do just that. See: ip-masq-vpn.

There are several Linux VPN solutions available:

• vpnd. See the http://sunsite.dk/vpnd/.

• Free S/Wan, available at http://www.xs4all.nl/~freeswan/
• ssh can be used to construct a VPN. See the VPN mini-how-to for more
information.
• vps (virtual private server) at http://www.strongcrypto.com.
• yawipin at http://yavipin.sourceforge.net

See also the section on IPSEC for pointers and more information.
 24

Reference:-

http://www.google.com

http://www.aboutdebian.com/security.htm

http://www.linuxsecurity.com/

http://www.verysecurelinux.com/

http://www.swflug.org/lessons/security/index.htm

http://www.amazon.com/Linux-Network-Security-Administrators-
Advantage/dp/1584503963

http://www.wikipedia.com

http://www.guruji.com