wiley publishing suse linux 9 bible phần 9 ppt

482 Part IV ✦ Implementing Network Services in SUSE Linux The Linux firewalling, as we said, is packet filter–based. A packet filter will act upon a net- work packet, dealing with the parameters that can be queried in the TCP/IP headers. For example, you can produce a rule that takes into consideration the source of the packet (the source IP address), the destination (destination IP address), the protocol (for example, TCP), the port (SSH), and the TCP options (SYN). Taking all of these into consideration, you can define a rule that describes a very specific sce- nario for a network connection. Putting numerous rules together, you can produce a very powerful firewall. With the introduction of iptables, we were given the godsend that was stateful firewalls. iptables is something that most Linux administrators should know, especially when you need to secure your network or individual machines from a network attack. They are rela- tively simple to use and extremely powerful when done correctly. All kudos to Rusty Russell (the lead iptables developer) for implementing this feature as it allowed us to produce tight firewalls with fewer rules. We will talk about stateful firewalls and what they do in this chap- ter, as well as a few scenario-based iptables rules. Why Use a Firewall? A firewall, whether Linux-based or not, should always be used to protect machines connected to the Internet. A firewall, by its very nature, is designed to control what can be accomplished over the network, and it is very unlikely you want your 200 Windows machines to be connected to the Internet in full view of any malicious person that comes along (and bare Windows machines on the Internet are like drops of blood in a 10-mile radius of a pack of sharks!). Most people think that a firewall is there to stop crackers from the Internet, but the fact of the matter is that your users are untrusted, too. It is all well and good to trust your users when you have security checked them and have run psychoanalytical tests to see if they have a predisposition for breaking the rules you have imposed on them. However, internal situations aren’t always so simple. Take the following example. We had a customer whose firewall was very tight at deterring Internet-based attacks and didn’t let in anything that did not need to be there. For their internal users, there were no restrictions on connections to the Internet. All users were trusted and all good guys. Their email and oper- ating system on the other hand were not, and they started receiving emails with viruses that arbitrarily scanned thousands of hosts on the Internet to carry on propagating throughout the ether. The customer found this out only because their Internet service provider (ISP) called them to say their connection would be closed if the scanning did not stop. This virus came through email to the user, and because Simple Mail Transport Protocol (SMTP) traffic was allowed through to the mail server, there was nothing to stop it. This is an important point. A packet filtering firewall does not stop viruses that are transported using HTTP, SMTP, and so on. It stops TCP/IP traffic only on certain ports. We used the logging facilities of iptables to track the source of these problems, and we pro- ceeded to remove the virus (the customer subsequently installed virus scanners on all machines). To combat these internal problems in the future, we tightened the security of the organiza- tion from a network standpoint. We restricted what could be accessed on the Internet from the internal network apart from the essentials. This stopped port scans from exiting the net- work and stopped most incarnations of virus transmission over Internet protocols. 32_577395 ch23.qxd 12/15/04 12:23 AM Page 482 483 Chapter 23 ✦ Implementing Firewalls in SUSE Linux Port scanning is when a machine automatically tries to connect to a range of TCP/IP ports on a machine to see if there are any services listening. It is used not only by crackers, but also by legitimate users who wish to see what services are available on a server. You should port scan only hosts that you have been allowed to interrogate. Port scanning a machine usually triggers alarms on a system, and you may get into trouble depending what the administrator is feeling like that day. This example fully illustrates that network security must be considered as a whole, not just as a threat from the Internet. Configuring a Firewall with iptables To configure a firewall on Linux, you need to get used to the iptables command, which is used to manipulate the kernel packet filtering settings from user space. (Refer to Chapter 6 for more information on TCP/IP, because an understanding of TCP/IP is needed.) The terms user space and kernel space are used a lot in the Unix community. When some- thing runs in kernel space, it is under the control and the constraints of the kernel. Something running in kernel space could be a kernel module or the packet filtering code. When something is in user space, it uses the system libraries and is not under the strict con- trol of the kernel. We use iptables (user space) to tell the kernel space filtering code (netfilter) what it needs to do with the TCP/IP packets it receives. When a TCP/IP packet is received by the kernel, it is passed and acted upon in kernel space by the netfilter code. The kernel filtering code uses chains to signify where a packet is in the kernel. Figure 23-1 gives an overview of how the kernel sees a TCP/IP packet. This also helps us to see how iptables interacts with these packets later in the chapter. Figure 23-1: Overview of the kernel chains Forward Kernel/Processes OutputInput Note Note 32_577395 ch23.qxd 12/15/04 12:23 AM Page 483 484 Part IV ✦ Implementing Network Services in SUSE Linux The filtering chains are extremely important to the operation of the filtering code because they determine whether or not a packet should be interpreted by the kernel. The chains themselves represent the final destination of the packet: ✦ INPUT— The packet is destined for the firewall itself. ✦ OUTPUT— The packet originated from the firewall. ✦ FORWARD— The packet is passing through the firewall (neither originates from nor is destined for the firewall). Consider these examples to show how the chains work in a normal firewall: ✦ My firewall at home is Linux based, and it does a few things that most small firewalls do: It provides my non-routable addresses with a public Internet address via Network Address Translation (NAT), and runs an SSH server for me to log in remotely to my network. When setting up a firewall appliance, you need to enable IP forwarding. IP forwarding allows packets to be routed from one network interface to another in the Linux machine. This is inte- gral to the whole process of routing packets and the Linux machine’s acting as a router. Most iptables firewalls that protect a network run on low-cost, low CPU–powered hardware. When a TCP/IP packet leaves my laptop, it is sent to the default route, which is my iptables firewall on my router. When the firewall receives the packet, it analyzes it to find its destination. As it sees that the packet is not destined for the machine itself, it is sent to the FORWARD chain. When in the FORWARD chain, the packet will traverse all firewall rules until it is either dropped or is sent to the outbound network interface (my ADSL router) for further processing. The important part of the scenario is that any non-local packets (destined or originat- ing from the machine) are passed to the forward chain (for forwarding!). ✦ When I SSH into my firewall from the Internet, a TCP/IP packet attempts to open an SSH connection for me. In the same way that the packet will reach the firewall as in the for- warding example, the kernel analyzes the packet to see where it is destined. As my machine is the final destination for the packet, it is inserted into the INPUT chain for further processing. If the packet is allowed through, it is passed over to the kernel to be handed over to user space (which is normal when no firewalling is used). ✦ The OUTPUT chain is slightly different because it does not deal with traffic from the network. An OUTPUT chain is triggered only when a packet originates from the machine itself. For example, if you are logged into the machine and initiate an FTP con- nection to the outside world, this is considered a packet that traverses the OUTPUT chain. Implementing an iptables firewall As a general rule of thumb when talking about network security, you should deny all and allow some. This means that by default you should not allow any network traffic at all to a machine, and then enable only what is needed for the operation of your firewall/network/server. Note 32_577395 ch23.qxd 12/15/04 12:23 AM Page 484 485 Chapter 23 ✦ Implementing Firewalls in SUSE Linux In the rest of the examples in this chapter, you must be logged in as root because you are changing memory belonging to the kernel through the iptables command, and that requires a privileged user. To make this easier, netfilter provides a default policy for each chain (INPUT, OUTPUT, FORWARD). You can set this policy to drop all packets that do not trigger a rule (that is, are not explicitly allowed). The Linux filtering code is always running, but by default, the policy for the chains is ACCEPT (see Listing 23-1). Listing 23-1: The Default Filtering Rules bible:~ # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination For each chain, the output of iptables -L (list rules) contains information on the target (ACCEPT, DROP, and REJECT are the most common targets), the TCP/IP protocol, and the packet source and destination. iptables targets When a TCP/IP packet is analyzed, a decision is made about what to do if that packet matches a rule. If the packet matches a rule, it is sent to a netfilter target, most likely ACCEPT, DROP, or REJECT. We’ll use an incoming SSH connection to a firewall as an example. It will be a TCP connection on port 22 on the INPUT rule at a bare minimum. If you have a rule that describes this packet, you need to tell the netfilter system to ACCEPT this packet into the TCP/IP stack for fur- ther processing by the kernel. However, you could tell netfilter to DROP or REJECT the packet: ✦ When a packet is sent to the DROP target, it simply disappears and the sending machine does not know this has happened until it times out. ✦ When a packet is subject to the REJECT target, the sending machine is notified via an Internet Control Message Protocol (ICMP) message that the port was not reachable (that is, it was stopped). If you configure the default policy of all chains to DROP/REJECT all non-triggered packets, it is unlikely you need to use these as targets because any packets that have not been explic- itly ACCEPTed will be subject to the DROP/REJECT target. Tip Note 32_577395 ch23.qxd 12/15/04 12:23 AM Page 485 486 Part IV ✦ Implementing Network Services in SUSE Linux Stateful firewall The netfilter firewalling code provides a stateful firewall, and this is a great new feature of the netfilter code. In the past, it was up to the administrator to track all connections through the firewall, which produced a lot of rules that were difficult to manage. With a state- ful firewall, netfilter keeps a record of connection states. With this information, netfilter can track a connection initiation and match up related network traffic. For example, previously, if you wanted to allow an incoming connection to SSH on the fire- wall, you had to first allow the incoming connection and also the return traffic from the SSH server to the client. With stateful firewalls, you can tell the firewall to manage the subsequent outgoing connection automatically because it is aware that an incoming connection to the machine will produce traffic in the opposite direction. It does this by storing the state of a connection and acting upon it with connection tracking. To enable the stateful connection tracking, you need to enable states in the firewall. We dis- cuss this in a small firewall script later in the chapter. Setting your first rules Before you touch upon setting more specific rules, you need to set the default policy for the firewall and enable some state rules (see Listing 23-2). Listing 23-2: Setting Initial Firewall Rules bible:~ # iptables -P INPUT DROP bible:~ # iptables -P OUTPUT DROP bible:~ # iptables -P FORWARD DROP bible:~ # iptables -A INPUT -m state state ESTABLISHED,RELATED -j ACCEPT bible:~ # iptables -A FORWARD -m state state ESTABLISHED,RELATED -j ACCEPT bible:~ # iptables -A OUTPUT -m state state NEW,ESTABLISHED,RELATED -j ACCEPT Here, you have set the default policy for all chains to DROP the packets. At this moment in time, all network connections, regardless of their originating address, will be dropped. To set or change the policy of a chain, you need to specify that this is a policy edit ( -P), the chain (INPUT, OUTPUT, or FORWARD), and also what to do with the packet. It’s a secure feeling knowing that any connection from the Internet that you do not need is dropped and the sender has to wait for a timeout before being notified. Imagine someone run- ning a port scan of all 64,000 available ports on a TCP/IP machine. If they have to wait for a timeout on each port, it will take them quite a few hours to complete the full scan. It provides a kind of tar pit for any malicious users. This is also true for internal connection, too. If your users are interested in what they can and cannot connect to, without reading the network rules, then making them wait will, one hopes, deter them from pushing the network too hard. You have also configured the stateful firewall with the -m state declaration. This tells the fire- wall that you will allow any established or related connections on the INPUT chain. This may seem like quite a big security hole, but bear in mind that it will allow only a connec- tion that has been established, not a new connection. For the stateful rules to kick in, you would have already had to allow a new connection through the chain. 32_577395 ch23.qxd 12/15/04 12:23 AM Page 486 487 Chapter 23 ✦ Implementing Firewalls in SUSE Linux Depending on how paranoid you are about security, you may not want to allow all new con- nections from the firewall itself. However, when you wish to use the firewall machine as a server, or want to be able to “bounce” from the machine to other hosts without the burden of setting up new rules for every protocol or TCP port you wish to connect to, it is quite useful. At this point, your firewall is locked down with the exception of allowing outgoing connections. Now, suppose you want to allow an incoming SSH connection to the firewall. Adding a rule When you add a rule proper, you need to specify as much information as possible to have full control over the TCP/IP you are allowing into the trusted network. At a minimum, you need the chain, protocol, and destination port. With just this information, you do not have a very good rule because it does not specify the interface you are allowing the SSH connection to. Another option that can be set is the connection type: ✦ NEW— This is a new connection; no other traffic is associated with this packet. ✦ ESTABLISHED — This packet is from a machine you already have a connection to (remember, you both send and receive data when a connection exists). ✦ RELATED — This packet is related to an existing connection. The FTP protocol, for example, makes a connection to the FTP server, and the FTP server actually makes a separate connection to the client. This separate connection from the server to the client is a RELATED connection. iptables –A INPUT –p tcp –dport ssh –i eth0 –j ACCEPT In this example, you have told netfilter that you want to append (-A) a rule to the INPUT chain, specifying the TCP protocol ( -p tcp), with a destination port (-dport) of ssh (port 22), incoming ( -i) on the eth0 interface, and finally that you want to ACCEPT the packet (-j ACCEPT). The -j parameter means “jump to a target.” Remember that netfilter rules are in a chain, so you are saying, “Stop processing this chain because you have a match and jump to the target.” In this case, ACCEPT. The -dport parameter can take either a numerical port number or a service name that is specified in /etc/services. When setting up a rule for connections, you really need to know how the protocol works. In the case of SSH, it is well known that it is a TCP protocol, running on port 22. With this in mind, it is relatively easy to write a rule for it. It is up to you as to how you want to write the rule regarding the state of the connection, but because the initial INPUT state rule has allowed all ESTABLISHED and RELATED connections, you do not need to explicitly set the state to NEW because you have effectively allowed all connection types for SSH by not explicitly setting them. When you do not specify something explicitly with an iptables rule, it is assumed that you want the default setting. For example, if you did not set the interface for the incoming con- nection, netfilter would have allowed an SSH connection on all network interfaces. This is indeed the same for the protocol type and the destination port. Be very careful how you write your rules, and make sure you explicitly set everything you wish to control; otherwise you will probably let in more than you think. Caution Note 32_577395 ch23.qxd 12/15/04 12:23 AM Page 487 488 Part IV ✦ Implementing Network Services in SUSE Linux For any incoming connections you wish to have on a firewall, you can append a rule in the same way you did with the SSH connection. The order of rules You must be very conscious of the order you set rules in a chain because netfilter passes the TCP/IP packet through the rules in the order they are inserted into the kernel. If you wish to insert a rule at the top of the list (that is, making it the first rule that is executed), you can use the -I (insert) parameter to iptables. For example, if you are allowing SSH into your firewall from the Internet, but you know that you do not want a certain IP address to have access to SSH, you have to insert the REJECT/DROP rule before the general SSH rule: iptables –A INPUT –p tcp –dport ssh –i eth0 –j ACCEPT iptables –I INPUT –p tcp –dport ssh –i eth0 –s 10.32.1.4 –j DROP In this example, using the -s option to specify a source IP address, we have inserted the DROP rule before the general SSH acceptance rule. When a TCP/IP packet has been inserted into a chain, it is checked in order with each rule. If one of the rules matches the TCP/IP packet, it is then sent to the target specified (ACCEPT, DROP, REJECT) immediately. In the case of our inserted SSH DROP rule, it fires off packets destined for the SSH port to the DROP target before it gets to the ACCEPT SSH rule. In essence, all the TCP/IP packets sequentially go through every rule in the chain until they are directed to a target. If none of the rules fires off a packet to a target, that packet is dealt with by the default policy, which is to kill the packet in this case. Network Address Translation While one of the main uses of netfilter is its packet filtering functions, another very impor- tant aspect of netfilter is its NAT functions. Network Address Translation (NAT) is the process whereby the source or destination IP address of a packet is seamlessly changed when it passes through the firewall. Chapter 6 contains some more information about NAT. Source NAT Source NAT (SNAT) works on packets forwarded through the firewall before a packet leaves for the outbound network. For this to work, you must deal with the packets before any rout- ing decisions have been made, and the POSTROUTING chain must be used to implement Source NAT. The main purpose of SNAT is to hide private networks behind a firewall with a public IP address. This drastically reduces the cost of acquiring public IP addresses and allows you to use non-routable addresses in your internal network. The POSTROUTING chain deals with any packets that are about to be sent out to the network card. This includes any packets that are routed onto other destinations. In the case of SNAT, this is the only chain that you want to use because, for example, it makes no sense to source NAT traffic coming into the firewall INPUT chain. Note Cross- Reference 32_577395 ch23.qxd 12/15/04 12:23 AM Page 488 489 Chapter 23 ✦ Implementing Firewalls in SUSE Linux Figure 23-2 details a home network that uses netfilter to SNAT our internal network. Figure 23-2: Network using a netfilter firewall In this scenario, all of the machines are behind a netfilter firewall that not only protects the machines, but also provides SNAT for outgoing connections. For SNAT to work, IP for- warding must be enabled. To do this, enter a “1” into /proc/sys/net/ipv4/ip_forward. bible:~ # echo 1 > /proc/sys/net/ipv4/ip_forward This will immediately enable IP forwarding on your Linux machine. This is a volatile opera- tion, and once your machine has been rebooted, IP forwarding will be turned off by default. To set IP forwarding on by default, edit the file /etc/sysconfig/sysctl and change IP_FORWARD from no to yes and re-run SuSEconfig. While editing the sysctl file, make sure that DISABLE_ECN is set to yes. ECN is Enhanced Congestion Notification. This is a new feature of TCP/IP that allows machines to notify you that a network route is congested. It is a great feature, but unfortu- nately is not in widespread circulation and can stop your network traffic from traversing the Internet correctly if it goes through a router that does not support ECN. We have been on customer sites where their network just stopped working for certain sites for no reason. Turning off ECN fixed this. When IP forwarding has been enabled, you can insert the SNAT rule into the POSTROUTING chain. In the home network, you need to source NAT all the internal traffic (192.168.1.0/24) to the firewall public address of 217.41.132.74. To do this, you need to insert a SNAT rule into the NAT table. Tip Internet 217.41.132.74 eth1 192.168.1.1 SUSE 9.1 192.168.1.3 AirPort OSX 192.168.1.0/24 DHCP eth0 Linux Firewall 32_577395 ch23.qxd 12/15/04 12:23 AM Page 489 490 Part IV ✦ Implementing Network Services in SUSE Linux The NAT table is used specifically for address translation rules. This includes source and des- tination address translation. bible:~ # iptables –t nat –A POSTROUTING –s 192.168.1.0/24 –o eth1 –j SNAT –to 217.41.132.74 Here, we have told iptables to edit the nat table (-t nat) by appending a rule to the POSTROUTING chain. We have stated that any traffic from the 192.168.1.0/24 network ( -s) and destined to leave the firewall through eth1 (-o) should be source address NAT’d to 217.41.132.74. In the example, note that we have tried to be as descriptive as possible concerning what traf- fic should be subject to the SNAT, detailing the source IP address (specifying the network address with netmask) and the network adaptor that the traffic will leave on. You know that the traffic you need to be SNAT’d will leave the eth1 interface because you want to SNAT only traffic that is heading out to the Internet. This can be through the eth1 interface only. Any traffic that is sent back to the machines behind the firewall (for example, during the three-way handshake) will be translated back by the firewall (it remembers connection states) and the destination address will automatically be set to the address of the machine on the private network that initiated the connection. Allowing the packets to be forwarded It is all well and good setting up SNAT, but the astute of you will probably realize that you have already told netfilter not to allow any forwarded traffic through the firewall (the default FORWARD policy is DROP). To correct this, you need to allow the firewall to forward these packets before they can be manipulated by the SNAT rule. To do this, you need to enable forwarding for traffic from the private network to the Internet: bible:~ # iptables –A FORWARD –s 192.168.1.0/24 –i eth0 -o eth1 –j ACCEPT Here, iptables is being used to append (-A) to the FORWARD chain (any traffic that enters and then leaves the firewall on separate interfaces). Any traffic from the 192.168.1.0/24 net- work entering the firewall on interface eth0 and leaving on interface eth1 will be allowed through. So, in this example, we have told netfilter that any traffic from the 192.168.1.0/24 network coming in on eth0 and leaving the firewall on eth1 should be allowed through. Again, we are relying on the fact that any traffic coming in on eth0 and leaving on eth1 that is from 192.168.1.0/24 will be traffic we want to be allowed out to the Internet. In this example, we have been quite liberal in what we are allowing our users to access on the Internet. It is usually the policy of most companies that IM clients, P2P, and IRC should not be allowed from the corporate network. As it stands, users can access anything on the Internet as if they were directly connected. For the home network example, this is fine because the users are trusted. However, if you are implementing a corporate firewall, you will probably need to have quite a few DROP rules in the FORWARD chain, or do the right thing and deny everything and allow only essential traffic (maybe only HTTP). Tip Note 32_577395 ch23.qxd 12/15/04 12:23 AM Page 490 491 Chapter 23 ✦ Implementing Firewalls in SUSE Linux Destination NAT Destination NAT (DNAT) is a nice feature when building netfilter firewalls. It does the exact opposite of the SNAT function by translating the destination address of a network packet into another address. Imagine in the example in Figure 23-2 that you had a mail server on your desktop machine. If you want to give access to that machine to Internet users, you can’t just tell the firewall that you want everyone to access the IP 192.168.1.3 over port 25; because this is a non-routable address, Internet users would never be able to reach it. To combat this, you can tell netfilter that any traffic destined for port 25 on the public firewall address should be redirected to the machine 192.168.1.3. Any return traffic to the initiating machine will have the source address of the firewall, making the connection routable. And as far as the initiating machine is con- cerned, it has no idea that the machine it is actually talking to is hidden behind a firewall and is on a non-routable address. To create the illusion, you need to add a DNAT rule to the NAT table for the Simple Mail Transport Protocol (SMTP) service. bible:~ # iptables –t nat –A PREROUTING –p tcp –-dport smtp –i eth1 –j DNAT –to- destination=192.168.1.3 Here, iptables has been told to work on the NAT table (-t nat) by appending to the PREROUTING chain. You have stated that any traffic that is TCP ( -p tcp)–based, with a destination port of SMTP (25), and entering the firewall on eth1 should be destination NAT’d to 192.168.1.3. In this case, all traffic for port 25 (SMTP) on the public network interface of the firewall will have its destination address changed to 192.168.1.3. The port destination of 25 will be untouched (we will come to this later). When enabling DNAT, you have to insert the rules into the PREROUTING chain because a routing decision has to be made on the final destination of the packet. At this point in the netfilter processing in the PREROUTING chain, the final destination address has not been inserted into the packet, so the routing decision is still yet to be made after this for suc- cessful delivery. In the same regard as SNAT, you still need to allow traffic destined on port 25 to 192.168.1.3 to be forwarded through the firewall. bible:~ # iptables –A FORWARD –p tcp –dport 25 –d 192.168.1.3 –i eth1 –o eth0 –j ACCEPT Here, iptables will append to the FORWARD chain, allowing through any TCP traffic that is destined for the SMTP port on 192.168.1.3 entering the firewall on eth1 and leaving on eth0. Once set, all traffic destined for port 25 on the firewall public interface is successfully for- warded to 192.168.1.3. Redirecting Traffic What if you want to redirect traffic to a different port on the firewall? This is very common when you are setting up a transparent HTTP proxy with something like Squid or another con- tent proxy. Note 32_577395 ch23.qxd 12/15/04 12:23 AM Page 491 [...]... filling up very quickly if you make this mistake Using SuSEfirewall2 SUSE includes its own sysconfig-based firewall script called SuSEfirewall2 The SuSEfirewall script has come a long way since its conception many years ago and provides a robust feature set that can be configured through YaST 493 494 Part IV ✦ Implementing Network Services in SUSE Linux For new users who need to set up a quick firewall,... objectClass: top objectClass: shadowAccount userPassword: {crypt}ESLp8vFJWpVEE shadowLastChange: 12572 shadowMax: 99 999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1000 gidNumber: 100 homeDirectory: /home/aimee telephoneNumber: 555-1027 o: Acme UK gecos: Aimee Davies Chapter 24 ✦ Working with LDAP in SUSE We have constructed an LDIF file for the administrator Aimee Davies, including account information... objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e2NyeXB0fUVTTHA4dkZKV3BWRUU= shadowLastChange: 12572 shadowMax: 99 999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1000 gidNumber: 100 Chapter 24 ✦ Working with LDAP in SUSE homeDirectory: /home/aimee telephoneNumber: 555-1027 o: Acme UK gecos: Aimee Davies # search result search: 2 result: 0 Success # numResponses:... 492 Part IV ✦ Implementing Network Services in SUSE Linux A redirection rule does not redirect to an IP, only a port This makes it a local rule to the firewall only With this in mind, any redirect rules must have a matching INPUT rule allowing the traffic to be accepted on the redirected port bible: ~ # iptables –t nat –A PREROUTING –p tcp -–dport 80 –i eth0 –s 192 .168.1.0/24 –j REDIRECT... Protect All Running Services • If you like to run traceroutes when you want to test network connectivity, turn on Allow Traceroute as well Figure 23-6: Enabling firewall features 497 498 Part IV ✦ Implementing Network Services in SUSE Linux 5 It is always a good idea to log any malicious packets that hit the firewall, and you can choose how verbose you want to be In Figure 23-7, you can see that we’ve chosen... documentation on the iptables web site at www netfilter.org/ ✦ ✦ ✦ 499 24 C H A P T E R Working with LDAP in SUSE ✦ ✦ ✦ ✦ In This Chapter B What is LDAP? NIS is capable of maintaining user account information, user groups, services, hosts, and many more pieces of information that, historically, needed to be managed on a local level Integrating Linux with LDAP ack in the day, the only way to centrally manage... Chapter 23 ✦ Implementing Firewalls in SUSE Linux Allowing Loopback It is advisable that you allow loopback traffic on your firewall because many services that you usually assume can communicate internally with each other will fail if you don’t To do this, you can specify that the loopback device should not be restricted: bible: ~ # iptables –A INPUT –i lo –j ACCEPT bible: ~ # iptables –A OUTPUT –o lo –j... eth0 as the internal network interface and eth1 as the external public interface, so set that here as well (see Figure 23-4) Figure 23-4: Selecting the protected interfaces 495 496 Part IV ✦ Implementing Network Services in SUSE Linux 3 You need to select what services are allowed into the firewall (see Figure 23-5) This is the same as defining an INPUT chain rule Be very careful what you want to allow... investigation for an attack To allow these types of ICMP traffic, you need to allow inbound ICMP and some outbound ICMP packets: bible: ~ # iptables -I INPUT -p icmp icmp-type destination-unreachable -j ACCEPT bible: ~ # iptables -I INPUT -p icmp icmp-type source-quench -j ACCEPT bible: ~ # iptables -I INPUT -p icmp icmp-type time-exceeded -j ACCEPT For each ICMP protocol type you have allowed, you are... access to the data, and the protocol used to talk to an LDAP server The Linux LDAP implementation is the extremely popular OpenLDAP server It has been around for a very long time and uses the LDAP specification as a base to implement new features Implementing OpenLDAP ✦ ✦ ✦ ✦ 502 Part IV ✦ Implementing Network Services in SUSE Linux Note LDAP is a part of many organizations although many people in . 9. 1 192 .168.1.3 AirPort OSX 192 .168.1.0/24 DHCP eth0 Linux Firewall 32_577 395 ch23.qxd 12/15/04 12:23 AM Page 4 89 490 Part IV ✦ Implementing Network Services in SUSE Linux The NAT table is used. the logs on your firewall for dropped packets. 32_577 395 ch23.qxd 12/15/04 12:23 AM Page 498 499 Chapter 23 ✦ Implementing Firewalls in SUSE Linux What Next? Firewalls are the first step in protecting. Firewall Rules bible: ~ # iptables -P INPUT DROP bible: ~ # iptables -P OUTPUT DROP bible: ~ # iptables -P FORWARD DROP bible: ~ # iptables -A INPUT -m state state ESTABLISHED,RELATED -j ACCEPT bible: ~