1.network Security In Linux

1

TERM PAPER OF COMPUTER NETWORK

TOPIC: NETWORK SECURITY IN LINUX

SUBMITTED TO: MS.CHAVI RALHAN

SUBMITTED BY: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. 2. 3. 4.

OS configuration - "hardening" the operating system Application configuration - making sure the server applications you do make available do only what they're supposed to do Perimeter security - configuring your network infrastructure with firewalls and DMZs 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[09].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 lowercase s, like this: root# root#

cd /etc/rc6.d 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 datapoint 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-todate 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-AdministratorsAdvantage/dp/1584503963 http://www.wikipedia.com http://www.guruji.com