$IPCHAINS -A input -p tcp -d $OURNET $TCPIN ! -y -b -j accept # TCP - INCOMING CONNECTIONS # We will accept connection requests from the outside only on the # allowed TCP ports. $IPCHAINS -A input -p tcp -i $ANYDEV -d $OURNET $TCPIN -y -j accept # TCP - OUTGOING CONNECTIONS # We accept all outgoing TCP connection requests on allowed TCP ports. $IPCHAINS -A input -p tcp -i $OURDEV -d $ANYADDR $TCPOUT -y -j accept # UDP - INCOMING # We will allow UDP datagrams in on the allowed ports. $IPCHAINS -A input -p udp -i $ANYDEV -d $OURNET $UDPIN -j accept # UDP - OUTGOING # We will allow UDP datagrams out on the allowed ports. $IPCHAINS -A input -p udp -i $OURDEV -d $ANYADDR $UDPOUT -j accept # ICMP - INCOMING # We will allow ICMP datagrams in of the allowed types. $IPCHAINS -A input -p icmp -w $ANYDEV -d $OURNET $UDPIN -j accept # ICMP - OUTGOING # We will allow ICMP datagrams out of the allowed types. $IPCHAINS -A input -p icmp -i $OURDEV -d $ANYADDR $UDPOUT -j accept # 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 $IPCHAINS -A input -p tcp -l -j reject # Log barred UDP $IPCHAINS -A input -p udp -l -j reject # Log barred ICMP $IPCHAINS -A input -p icmp -l -j reject fi # # end. In our iptables example, we’ve switched to using the FORWARD ruleset because of the difference in meaning of the INPUT ruleset in the netfilter implementation. This has implications for us; it means that none of the rules protect the firewall host itself. To accurately mimic our ipchains example, we would replicate each of our rules
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
# 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 Input table rules $IPCHAINS -F input # We want to deny incoming access by default. $IPCHAINS -P input deny # SPOOFING # We should not accept any datagrams with a source address matching ours # from the outside, so we deny them. $IPCHAINS -A input -s $OURNET -i $ANYDEV -j deny # SMURF # Disallow ICMP to our broadcast address to prevent “Smurf” style attack. $IPCHAINS -A input -p icmp -w $ANYDEV -d $OURBCAST -j deny # We should accept fragments, in ipchains we must do this explicitly. $IPCHAINS -A input -f -j accept # TCP # 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.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
$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. 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″
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
# 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 # 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.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
Linux Network Administrators Guide Prev Chapter 9. TCP/IP Firewall Next 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: #!/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”
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services
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. Prev Home Next TOS Bit Manipulation Up A Sample Firewall Configuration
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services
Linux Network Administrators Guide Prev Chapter 9. TCP/IP Firewall Next 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, destination 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.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services
-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 Hexadecimal Normal-Service 0×00 Minimize-Cost 0×02 Maximize-Reliability 0×04 Maximize-Throughput 0×08 Minimize-Delay 0×10 Prev Home Next Netfilter and IP Tables (2.4 Kernels) Up Testing a Firewall Configuration
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
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: #NAME? 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 ipfwadm or ipchains. 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:
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
Linux Network Administrators Guide Prev Chapter 9. TCP/IP Firewall Next 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. 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.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services