Ftp Web Hosting - J2Ee Hosting Sun Java Developing Blog

# We will accept all TCP datagrams belonging to an existing connection # (i.e. having the ACK bit set) for the TCP ports we’re allowing through. # This should catch more than 95 % of all valid TCP packets. $IPFWADM -I -a accept -P tcp -D $OURNET $TCPIN -k -b # TCP -INCOMING CONNECTIONS # We will accept connection requests from the outside only on the # allowed TCP ports. $IPFWADM -I -a accept -P tcp -W $ANYDEV -D $OURNET $TCPIN -y # TCP -OUTGOING CONNECTIONS # We accept all outgoing tcp connection requests on allowed TCP ports. $IPFWADM -I -a accept -P tcp -W $OURDEV -D $ANYADDR $TCPOUT -y # UDP -INCOMING # We will allow UDP datagrams in on the allowed ports. $IPFWADM -I -a accept -P udp -W $ANYDEV -D $OURNET $UDPIN # UDP -OUTGOING # We will allow UDP datagrams out on the allowed ports. $IPFWADM -I -a accept -P udp -W $OURDEV -D $ANYADDR $UDPOUT # ICMP -INCOMING # We will allow ICMP datagrams in of the allowed types. $IPFWADM -I -a accept -P icmp -W $ANYDEV -D $OURNET $UDPIN # ICMP -OUTGOING # We will allow ICMP datagrams out of the allowed types. $IPFWADM -I -a accept -P icmp -W $OURDEV -D $ANYADDR $UDPOUT # DEFAULT and LOGGING # All remaining datagrams fall through to the default # rule and are dropped. They will be logged if you’ve # configured the LOGGING variable above. # if [ “$LOGGING” ] then # Log barred TCP $IPFWADM -I -a reject -P tcp -o # Log barred UDP $IPFWADM -I -a reject -P udp -o # Log barred ICMP $IPFWADM -I -a reject -P icmp -o fi # # end. Now we’ll reimplement it using the ipchains command: #!/bin/bash ########################################################################## # IPCHAINS VERSION # This sample configuration is for a single host firewall configuration # with no services supported by the firewall machine itself. ########################################################################## # USER CONFIGURABLE SECTION # The name and location of the ipchains utility. IPCHAINS=ipchains # The path to the ipchains executable.

#!/bin/bash ########################################################################## # IPFWADM VERSION # This sample configuration is for a single host firewall configuration # with no services supported by the firewall machine itself. ########################################################################## # USER CONFIGURABLE SECTION # The name and location of the ipfwadm utility. Use ipfwadm-wrapper for # 2.2.* kernels. IPFWADM=ipfwadm # The path to the ipfwadm executable. PATH=”/sbin” # Our internal network address space and its supporting network device. OURNET=”172.29.16.0/24″ OURBCAST=”172.29.16.255″ OURDEV=”eth0″ # The outside address and the network device that supports it. ANYADDR=”0/0″ ANYDEV=”eth1″ # The TCP services we wish to allow to pass -”" empty means all ports # note: space separated TCPIN=”smtp www” TCPOUT=”smtp www ftp ftp-data irc” # The UDP services we wish to allow to pass -”" empty means all ports # note: space separated UDPIN=”domain” UDPOUT=”domain” # The ICMP services we wish to allow to pass -”" empty means all types # ref: /usr/include/netinet/ip_icmp.h for type numbers # note: space separated ICMPIN=”0 3 11″ ICMPOUT=”8 3 11″ # Logging; uncomment the following line to enable logging of datagrams # that are blocked by the firewall. # LOGGING=1 # END USER CONFIGURABLE SECTION ########################################################################### # Flush the Incoming table rules $IPFWADM -I -f # We want to deny incoming access by default. $IPFWADM -I -p deny # SPOOFING # We should not accept any datagrams with a source address matching ours # from the outside, so we deny them. $IPFWADM -I -a deny -S $OURNET -W $ANYDEV # SMURF # Disallow ICMP to our broadcast address to prevent “Smurf” style attack. $IPFWADM -I -a deny -P icmp -W $ANYDEV -D $OURBCAST # TCP

tion address, protocol, and interface to be used for the test. Other arguments, such as port numbers or TOS bit settings, are optional. 4. Execute each test command and note the output. The output of each test will be a single word indicating the final target of the datagram after running it through the firewall configuration — that is, where the processing ended. For ipchains and iptables, user-specified chains will be tested in addition to the built-in ones. 5. Compare the output of each test against the desired result. If there are any discrepancies, you will need to analyse your ruleset to determine where you’ve made the error. If you’ve written your test commands into a script file, you can easily rerun the test after correcting any errors in your firewall configuration. It’s a good practice to flush your rulesets completely and rebuild them from scratch, rather than to make changes dynamically. This helps ensure that the active configuration you are testing actually reflects the set of commands in your configuration script. Let’s take a quick look at what a manual test transcript would look like for our na ve example with ipchains. You will remember that our local network in the example was 172.16.1.0 with a netmask of 255.255.255.0, and we were to allow TCP connections out to web servers on the net. Nothing else was to pass our forward chain. Start with a transmission that we know should work, a connection from a local host to a web server outside: # ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 accepted Note the arguments had to be supplied and the way they’ve been used to describe a datagram. The output of the command indicates that that the datagram was accepted for forwarding, which is what we hoped for. Now try another test, this time with a source address that doesn’t belong to our network. This one should be denied: # ipchains -C forward -p tcp -s 172.16.2.0 1025 -d 44.136.8.2 80 -i eth0 denied Try some more tests, this time with the same details as the first test, but with different protocols. These should be denied, too: # ipchains -C forward -p udp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied # ipchains -C forward -p icmp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied Try another destination port, again expecting it to be denied: # ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 23 -i eth0 denied You’ll go a long way toward achieving peace of mind if you design a series of exhaustive tests. While this can sometimes be as difficult as designing the firewall configuration, it’s also the best way of knowing that your design is providing the security you expect of it. A Sample Firewall Configuration We’ve discussed the fundamentals of firewall configuration. Let’s now look at what a firewall configuration might actually look like. The configuration in this example has been designed to be easily extended and customized. We’ve provided three versions. The first version is implemented using the ipfwadm command (or the ipfwadm-wrapper script), the second uses ipchains, and the third uses iptables. The example doesn’t attempt to exploit user-defined chains, but it will show you the similarities and differences between the old and new firewall configuration tool syntaxes:

Rather than the complicated two-mask configuration of ipfwadm and ipchains, iptables uses the simpler approach of plainly specifying what the TOS bits should match, or to what the TOS bits should be set. Additionally, rather than having to remember and use the hexadecimal value, you may specify the TOS bits using the more friendly mnemonics listed in the upcoming table. The general syntax used to match TOS bits looks like: -m tos –tos mnemonic [other-args]-j target The general syntax used to set TOS bits looks like: [other-args] -j TOS –set mnemonic Remember that these would typically be used together, but they can be used quite independently if you have a configuration that requires it. Mnemonic Normal-Service Minimize-Cost Maximize-Reliability Maximize-Throughput Minimize-Delay Hexadecimal 0×00 0×02 0×04 0×08 0×10 Testing a Firewall Configuration After you’ve designed an appropriate firewall configuration, it’s important to validate that it does in fact do what you want it to do. One way to do this is to use a test host outside your network to attempt to pierce your firewall: this can be quite clumsy and slow, though, and is limited to testing only those addresses that you can actually use. A faster and easier method is available with the Linux firewall implementation. It allows you to manually generate tests and run them through the firewall configuration just as if you were testing with actual datagrams. All varieties of the Linux kernel firewall software, ipfwadm, ipchains, and iptables, provide support for this style of testing. The implementation involves use of the relevant check command. The general test procedure is as follows: 1. Design and configure your firewall using ipfwadm, ipchains, or iptables. 2. Design a series of tests that will determine whether your firewall is actually working as you intend. For these tests you may use any source or destination address, so choose some address combinations that should be accepted and some others that should be dropped. If you’re allowing or disallowing only certain ranges of addresses, it is a good idea to test addresses on either side of the boundary of the range -one address just inside the boundary and one address just outside the boundary. This will help ensure that you have the correct boundaries configured, because it is sometimes easy to specify netmasks incorrectly in your configuration. If you’re filtering by protocol and port number, your tests should also check all important combinations of these parameters. For example, if you intend to accept only TCP under certain circumstances, check that UDP datagrams are dropped. 3. Develop ipfwadm, ipchains, or iptables rules to implement each test. It is probably worthwhile to write all the rules into a script so you can test and re-test easily as you correct mistakes or change your design. Tests use almost the same syntax as rule specifications, but the arguments take on slightly differing meanings. For example, the source address argument in a rule specification specifies the source address that datagrams matching this rule should have. The source address argument in test syntax, in contrast, specifies the source address of the test datagram that will be generated. For ipfwadm, you must use the -c option to specify that this command is a test, while for ipchains and iptables, you must use the -C option. In all cases you must always specify the source address, destina

Maximum throughput Used when the volume of data transmitted in any period of time is important. There are many types of network applications for which latency is not particularly important but the network throughput is; for example, bulk-file transfers. A network provider might choose to route datagrams with this type of service set via high-latency, high-bandwidth routes, such as satellite connections. Maximum reliability Used when it is important that you have some certainty that the data will arrive at the destination without retransmission being required. The IP protocol may be carried over any number of underlying transmission mediums. While SLIP and PPP are adequate datalink protocols, they are not as reliable as carrying IP over some other network, such as an X.25 network. A network provider might make an alternate network available, offering high reliability, to carry IP that would be used if this type of service is selected. Minimum cost Used when it is important to minimize the cost of data transmission. Leasing bandwidth on a satellite for a transpacific crossing is generally less costly than leasing space on a fiber-optical cable over the same distance, so network providers may choose to provide both and charge differently depending on which you use. In this scenario, your “minimum cost” type of service bit may cause your datagrams to be routed via the lower-cost satellite route. Setting the TOS Bits Using ipfwadm or ipchains The ipfwadm and ipchains commands deal with the TOS bits in much the same manner. In both cases you specify a rule that matches the datagrams with particular TOS bits set, and use the -t argument to specify the change you wish to make. The changes are specified using two-bit masks. The first of these bit masks is logically ANDed with the IP options field of the datagram and the second is logically eXclusive-ORd with it. If this sounds complicated, we’ll give you the recipes required to enable each of the types of service in a moment. The bit masks are specified using eight-bit hexadecimal values. Both ipfwadm and ipchains use the same argument syntax: -t andmask xormask Fortunately the same mask arguments can be used each time you wish to set a particular type of service, to save you having to work them out. They are presented with some suggested uses in Table 9.3. Table 9.3: Suggested Uses for TOS Bitmasks TOS ANDmask XORmask Suggested Use Minimum Delay 0×01 0×10 ftp, telnet, ssh Maximum Throughput 0×01 0×08 ftp-data, www Maximum Reliability 0×01 0×04 snmp, dns Minimum Cost 0×01 0×02 nntp, smtp Setting the TOS Bits Using iptables The iptables tool allows you to specify rules that capture only datagrams with TOS bits matching some predetermined value using the -m tos option, and for setting the TOS bits of IP datagrams matching a rule using the -j TOS target. You may set TOS bits only on the FORWARD and OUTPUT chains. The matching and the setting occur quite independently. You can configure all sort of interesting rules. For example, you can configure a rule that discads all datagrams with certain TOS bit combinations, or a rule that sets the TOS bits of datagrams only from certain hosts. Most often you will use rules that contain both matching and setting to perform TOS bit translations, just as you could for ipfwadmor ipchains.

ICMP Extensions: used with -m icmp -p icmp - -icmp-type [!] typename Specifies the ICMP message type that this rule will match. The type may be specified by number or name. Some valid names are: echo-request, echo-reply, source-quench, time- exceeded, destination-unreachable, network-unreachable, host-unreachable, protocol-unreachable, and port-unreachable. MAC Extensions: used with -m mac - -mac-source [!] address Specifies the host’s Ethernet address that transmitted the datagram that this rule will match. This only makes sense in a rule in the input or forward chains because we will be transmitting any datagram that passes the output chain. Our Na ve Example Revisited, Yet Again To implement our na ve example using the netfilter, you could simply load the ipchains.o module and pretend it is the ipchains version. Instead, we’ll reimplement it using iptables to illustrate how similar it is. Yet again, let’s suppose that we have a network in our organization and that we are using a Linux-based firewall machine to allow our users to be able to access WWW servers on the Internet, but to allow no other traffic to be passed. If our network has a 24-bit network mask (class C) and has an address of 172.16.1.0, then we’d use the following iptables rules: # modprobe ip_tables # iptables -F FORWARD # iptables -P FORWARD DROP # iptables -A FORWARD -m tcp -p tcp -s 0/0 –sport 80 -d 172.16.1.0/24 / –syn -j DROP # iptables -A FORWARD -m tcp -p tcp -s 172.16.1.0/24 –sport / 80 -d 0/0 -j ACCEPT # iptables -A FORWARD -m tcp -p tcp -d 172.16.1.0/24 –dport 80 -s 0/0 -j / ACCEPT In this example the iptables commands are interpreted exactly as the equivalent ipchains commands. The major exception that the ip_tables.o module must load. Note that iptables doesn’t support the -b option, so we must supply a rule for each direction. TOS Bit Manipulation The Type Of Service (TOS) bits are a set of four-bit flags in the IP header. When any one of these bit flags is set, routers may handle the datagram differently than datagrams with no TOS bits set. Each of the four bits has a different purpose and only one of the TOS bits may be set at any time, so combinations are not allowed. The bit flags are called Type of Service bits because they enable the application transmitting the data to tell the network the type of network service it requires. The classes of network service available are: Minimum delay Used when the time it takes for a datagram to travel from the source host to destination host (latency) is most important. A network provider might, for example, use both optical fiber and satellite network connections. Data carried across satellite connections has farther to travel and their latency is generally therefore higher than for terrestrial-based network connections between the same endpoints. A network provider might choose to ensure that datagrams with this type of service set are not carried by satellite.

-v causes iptables to be verbose in its output; it will supply more information. -n causes iptables to display IP address and ports as numbers without attempting to resolve them to their corresponding names. -x causes any numbers in the iptables output to be expanded to their exact values with no rounding. - -line-numbers causes line numbers to be displayed when listing rulesets. The line number will correspond to the rule’s position within the chain. Extensions We said earlier that the iptables utility is extensible through optional shared library modules. There are some standard extensions that provide some of the features ipchains provided. To make use of an extension, you must specify its name through the -m name argument to iptables. The following list shows the -m and -p options that set up the extension’s context, and the options provided by that extension. TCP Extensions: used with -m tcp -p tcp - -sport [!] [port[:port]] Specifies the port that the datagram source must be using to match this rule. Ports may be specified as a range by specifying the upper and lower limits of the range using the colon as a delimiter. For example, 20:25 described all of the ports numbered 20 up to and including 25. Again, the ! character may be used to negate the values. - -dport [!] [port[:port]] Specifies the port that the datagram destination must be using to match this rule. The argument is coded identically to the - -sport option. - -tcp-flags [!] mask comp Specifies that this rule should match when the TCP flags in the datagram match those specified by mask and comp. mask is a comma-separated list of flags that should be examined when making the test. comp is a comma-separated list of flags that must be set for the rule to match. Valid flags are: SYN, ACK, FIN, RST, URG, PSH, ALL or NONE. This is an advanced option: refer to a good description of the TCP protocol, such as RFC-793, for a description of the meaning and implication of each of these flags. The ! character negates the rule. [!] - -syn Specifies the rule to match only datagrams with the SYN bit set and the ACK and FIN bits cleared. Datagrams with these options are used to open TCP connections, and this option can therefore be used to manage connection requests. This option is shorthand for: –tcp-flags SYN,RST,ACK SYN When you use the negation operator, the rule will match all datagrams that do not have both the SYN and ACK bits set. UDP Extensions: used with -m udp -p udp - -sport [!] [port[:port]] Specifies the port that the datagram source must be using to match this rule. Ports may be specified as a range by specifying the upper and lower limits of the range using the colon as a delimiter. For example, 20:25 describes all of the ports numbered 20 up to and including 25. Again, the ! character may be used to negate the values. - -dport [!] [port[:port]] Specifies the port that the datagram destination must be using to match this rule. The argument is coded identically to the - -sport option.

-X [chain] Delete the specified user-defined chain, or all user-defined chains if no chain is specified. For this command to be successful, there must be no references to the specified chain from any other rules chain. -P chain policy Set the default policy of the specified chain to the specified policy. Valid firewalling policies are ACCEPT, DROP, QUEUE, and RETURN. ACCEPT allows the datagram to pass. DROP causes the datagram to be discarded. QUEUE causes the datagram to be passed to userspace for further processing. The RETURN target causes the IP firewall code to return to the Firewall Chain that called the one containing this rule, and continue starting at the rule after the calling rule. Rule specification parameters There are a number of iptables parameters that constitute a rule specification. Wherever a rule specification is required, each of these parameters must be supplied or their default will be assumed. -p [!]protocol Specifies the protocol of the datagram that will match this rule. Valid protocol names are tcp, udp, icmp, or a number, if you know the IP protocol number.64 For example, you might use 4 to match the ipip encapsulation protocol. If the ! character is supplied, the rule is negated and the datagram will match any protocol other than the specified protocol. If this parameter isn’t supplied, it will default to match all protocols. -s [!]address[/mask] Specifies the source address of the datagram that will match this rule. The address may be supplied as a hostname, a network name, or an IP address. The optional mask is the netmask to use and may be supplied either in the traditional form (e.g., /255.255.255.0) or in the modern form (e.g., /24). -d [!]address[/mask] Specifies the destination address and port of the datagram that will match this rule. The coding of this parameter is the same as that of the -s parameter. -j target Specifies what action to take when this rule matches. You can think of this parameter as meaning “jump to.” Valid targets are ACCEPT, DROP, QUEUE, and RETURN. We described the meanings of each of these previously in the “Commands” section. You may also specify the name of a user-defined chain where processing will continue. You may also supply the name of a target supplied by an extension. We’ll talk about extensions shortly. If this parameter is omitted, no action is taken on matching data- grams at all, other than to update the datagram and byte counters of this rule. -i [!]interface-name Specifies the interface on which the datagram was received. Again, the ! inverts the result of the match. If the interface name ends with “+” then any interface that begins with the supplied string will match. For example, -i ppp+ would match any PPP network device and -i ! eth+ would match all interfaces except ethernet devices. -o [!]interface-name Specifies the interface on which the datagram is to be transmitted. This argument has the same coding as the -i argument. [!] -f Specifies that this rule applies only to the second and later fragments of a fragmented datagram, not to the first fragment. Options The following iptables options are more general in nature. Some of them control rather esoteric features of the netfilter software. Take a look at /etc/protocols for protocol names and numbers.

tionality can be extended without recompiling it. It manages this trick by using shared libraries. There are standard extensions and we’ll explore some of them in a moment. Before you can use the iptables command, you must load the netfilter kernel module that provides support for it. The easiest way to do this is to use the modprobe command as follows: modprobe ip_tables The iptables command is used to configure both IP filtering and Network Address Translation. To facilitate this, there are two tables of rules called filter and nat. The filter table is assumed if you do not specify the -t option to override it. Five built-in chains are also provided. The INPUT and FORWARD chains are available for the filter table, the PREROUTING and POSTROUTING chains are available for the nat table, and the OUT- PUT chain is available for both tables. In this chapter we’ll discuss only the filter table. We’ll look at the nat table in Chapter 11 The general syntax of most iptables commands is: iptables command rule-specification extensions Now we’ll take a look at some options in detail, after which we’ll review some examples. Commands There are a number of ways we can manipulate rules and rulesets with the iptables command. Those relevant to IP firewalling are: -A chain Append one or more rules to the end of the nominated chain. If a hostname is supplied as either a source or destination and it resolves to more than one IP address, a rule will be added for each address. -I chain rulenum Insert one or more rules to the start of the nominated chain. Again, if a hostname is supplied in the rule specification, a rule will be added for each of the addresses to which it resolves. -D chain Delete one or more rules from the specified chain matching the rule specification. -D chain rulenum Delete the rule residing at position rulenum in the specified chain. Rule positions start at 1 for the first rule in the chain. -R chain rulenum Replace the rule residing at position rulenum in the specific chain with the supplied rule specification. -C chain Check the datagram described by the rule specification against the specific chain. This command will return a message describing how the chain processed the datagram. This is very useful for testing your firewall configuration and we will look at it in detail later. -L [chain] List the rules of the specified chain, or for all chains if no chain is specified. -F [chain] Flush the rules of the specified chain, or for all chains if no chain is specified. -Z [chain] Zero the datagram and byte counters for all rules of the specified chain, or for all chains if no chain is specified. -N chain Create a new chain with the specified name. A chain of the same name must not already exist. This is how user-defined chains are created.

Consider the case of a configuration for which the default policy for each of the input, forward, and output chains is deny. In IP chains, six rules would be needed to allow any session through a firewall host: two each in the input, forward, and output chains (one would cover each forward path and one would cover each return path). You can imagine how this could easily become extremely complex and difficult to manage when you want to mix sessions that could be routed and sessions that could connect to the local host without being routed. IP chains allow you to create chains that would simplify this task a little, but the design isn’t obvious and requires a certain level of expertise. In the netfilter implementation with iptables, this complexity disappears completely. For a service to be routed across the firewall host, but not terminate on the local host, only two rules are required: one each for the forward and the reverse directions in the forward chain. This is the obvious way to design firewalling rules, and will serve to simplify the design of firewall configurations immensely. Figure 9.9: Datagram processing chain in netfilter The PACKET-FILTERING-HOWTO offers a detailed list of the changes that have been made, so let’s focus on the more practical aspects here. Backward Compatability with ipfwadm and ipchains The remarkable flexibility of Linux netfilter is illustrated by its ability to emulate the ipfwadm and ipchains interfaces. Emulation makes transition to the new generation of firewall software a little easier. The two netfilter kernel modules called ipfwadm.o and ipchains.o provide backward compatibility for ipfwadm and ipchains. You may load only one of these modules at a time, and use one only if the ip_tables.o module is not loaded. When the appropriate module is loaded, netfilter works exactly like the former firewall implementation. netfilter mimics the ipchains interface with the following commands: rmmod ip_tables modprobe ipchains ipchains … Using iptables The iptables utility is used to configure netfilter filtering rules. Its syntax borrows heavily from the ipchains command, but differs in one very significant respect: it is extensible. What this means is that its func