terus terang masih bingung banget nih..seumur umur lum pernah mainan linux.. giliran pegang server problem yang terjadi sering banget karena ip tablesnya.. dr pada bingung skalian belajar dan sebagai dokumentasi terus terang aku copas dari
buat bahan bacaan .. moga moga cepet paham lah..
The first step in using iptables is to start the iptables service. Use the following command to start the iptables service:
[root@myServer ~] # service iptables start
The ip6tables service can be turned off if you intend to use the iptables service only. If you deactivate the ip6tables service, remember to deactivate the IPv6 network also. Never leave a network device active without the matching firewall.
To force iptables to start by default when the system is booted, use the following command:
[root@myServer ~] # chkconfig --level 345 iptables on
The following sample iptables command illustrates the basic command syntax:
[root@myServer ~ ] # iptables -A The -A option specifies that the rule be appended to . Each chain is comprised of one or more rules, and is therefore also known as a ruleset.
The three built-in chains are INPUT, OUTPUT, and FORWARD. These chains are permanent and cannot be deleted. The chain specifies the point at which a packet is manipulated.
The -j option specifies the target of the rule; i.e., what to do if the packet matches the rule. Examples of built-in targets are ACCEPT, DROP, and REJECT.
Refer to the iptables man page for more information on the available chains, options, and targets.
Establishing basic firewall policies creates a foundation for building more detailed, user-defined rules.
Each iptables chain is comprised of a default policy, and zero or more rules which work in concert with the default policy to define the overall ruleset for the firewall.
The default policy for a chain can be either DROP or ACCEPT. Security-minded administrators typically implement a default policy of DROP, and only allow specific packets on a case-by-case basis. For example, the following policies block all incoming and outgoing packets on a network gateway:
[root@myServer ~ ] # iptables -P INPUT DROP
Changes to iptables are transitory; if the system is rebooted or if the iptables service is restarted, the rules are automatically flushed and reset. To save the rules so that they are loaded when the iptables service is started, use the following command:
[root@myServer ~ ] # service iptables save The rules are stored in the file /etc/sysconfig/iptables and are applied whenever the service is started or the machine is rebooted.
Common IPTables Filtering
Preventing remote attackers from accessing a LAN is one of the most important aspects of network security. The integrity of a LAN should be protected from malicious remote users through the use of stringent firewall rules.
However, with a default policy set to block all incoming, outgoing, and forwarded packets, it is impossible for the firewall/gateway and internal LAN users to communicate with each other or with external resources.
To allow users to perform network-related functions and to use networking applications, administrators must open certain ports for communication.
For example, to allow access to port 80 on the firewall, append the following rule:
[root@myServer ~ ] # iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
This allows users to browse websites that communicate using the standard port 80. To allow access to secure websites (for example, https://www.example.com/), you also need to provide access to port 443, as follows:
[root@myServer ~ ] # iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
Important
When creating an iptables ruleset, order is important.
If a rule specifies that any packets from the 192.168.100.0/24 subnet be dropped, and this is followed by a rule that allows packets from 192.168.100.13 (which is within the dropped subnet), then the second rule is ignored.
The rule to allow packets from 192.168.100.13 must precede the rule that drops the remainder of the subnet.
To insert a rule in a specific location in an existing chain, use the -I option. For example:
[root@myServer ~ ] # iptables -I INPUT 1 -i lo -p all -j ACCEPT
This rule is inserted as the first rule in the INPUT chain to allow local loopback device traffic.
There may be times when you require remote access to the LAN. Secure services, for example SSH, can be used for encrypted remote connection to LAN services.
Administrators with PPP-based resources (such as modem banks or bulk ISP accounts), dial-up access can be used to securely circumvent firewall barriers. Because they are direct connections, modem connections are typically behind a firewall/gateway.
For remote users with broadband connections, however, special cases can be made. You can configure iptables to accept connections from remote SSH clients. For example, the following rules allow remote SSH access:
[root@myServer ~ ] # iptables -A INPUT -p tcp --dport 22 -j ACCEPT
FORWARD and NAT Rules
Most ISPs provide only a limited number of publicly routable IP addresses to the organizations they serve.
Administrators must, therefore, find alternative ways to share access to Internet services without giving public IP addresses to every node on the LAN. Using private IP addresses is the most common way of allowing all nodes on a LAN to properly access internal and external network services.
Edge routers (such as firewalls) can receive incoming transmissions from the Internet and route the packets to the intended LAN node. At the same time, firewalls/gateways can also route outgoing requests from a LAN node to the remote Internet service.
This forwarding of network traffic can become dangerous at times, especially with the availability of modern cracking tools that can spoof internal IP addresses and make the remote attacker's machine act as a node on your LAN.
To prevent this, iptables provides routing and forwarding policies that can be implemented to prevent abnormal usage of network resources.
The FORWARD chain allows an administrator to control where packets can be routed within a LAN. For example, to allow forwarding for the entire LAN (assuming the firewall/gateway is assigned an internal IP address on eth1), use the following rules:
[root@myServer ~ ] # iptables -A FORWARD -i eth1 -j ACCEPT [root@myServer ~ ] # iptables -A FORWARD -o eth1 -j ACCEPT
This rule gives systems behind the firewall/gateway access to the internal network. The gateway routes packets from one LAN node to its intended destination node, passing all packets through its eth1 device.
Note
By default, the IPv4 policy in Red Hat Enterprise Linux kernels disables support for IP forwarding. This prevents machines that run Red Hat Enterprise Linux from functioning as dedicated edge routers. To enable IP forwarding, use the following command:
[root@myServer ~ ] # sysctl -w net.ipv4.ip_forward=1
This configuration change is only valid for the current session; it does not persist beyond a reboot or network service restart. To permanently set IP forwarding, edit the /etc/sysctl.conf file as follows:
Locate the following line:
net.ipv4.ip_forward = 0
Edit it to read as follows:
net.ipv4.ip_forward = 1
Use the following command to enable the change to the sysctl.conf file:
[root@myServer ~ ] # sysctl -p /etc/sysctl.conf
Postrouting and IP Masquerading
Accepting forwarded packets via the firewall's internal IP device allows LAN nodes to communicate with each other; however they still cannot communicate externally to the Internet.
To allow LAN nodes with private IP addresses to communicate with external public networks, configure the firewall for IP masquerading, which masks requests from LAN nodes with the IP address of the firewall's external device (in this case, eth0):
[root@myServer ~ ] # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
This rule uses the NAT packet matching table (-t nat) and specifies the built-in POSTROUTING chain for NAT (-A POSTROUTING) on the firewall's external networking device (-o eth0).
POSTROUTING allows packets to be altered as they are leaving the firewall's external device.
The -j MASQUERADE target is specified to mask the private IP address of a node with the external IP address of the firewall/gateway.
Prerouting
If you have a server on your internal network that you want make available externally, you can use the -j DNAT target of the PREROUTING chain in NAT to specify a destination IP address and port where incoming packets requesting a connection to your internal service can be forwarded.
For example, if you want to forward incoming HTTP requests to your dedicated Apache HTTP Server at 172.31.0.23, use the following command:
[root@myServer ~ ] # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 172.31.0.23:80
This rule specifies that the
nat table use the built-in PREROUTING chain to forward incoming HTTP requests exclusively to the listed destination IP address of 172.31.0.23.
[root@myServer ~ ] # iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
These rules allow incoming and outbound access for an individual system, such as a single PC directly connected to the Internet or a firewall/gateway. However, they do not allow nodes behind the firewall/gateway to access these services. To allow LAN access to these services, you can use Network Address Translation (NAT) with iptables filtering rules.
[root@myServer ~ ] # iptables -P OUTPUT DROP
It is also recommended that any forwarded packets — network traffic that is to be routed from the firewall to its destination node — be denied as well, to restrict internal clients from inadvertent exposure to the Internet. To do this, use the following rule:
[root@myServer ~ ] # iptables -P FORWARD DROP
When you have established the default policies for each chain, you can create and save further rules for your particular network and security requirements.
The following sections describe how to save iptables rules and outline some of the rules you might implement in the course of building your iptables firewall.
Malicious Software and Spoofed IP Addresses
More elaborate rules can be created that control access to specific subnets, or even specific nodes, within a LAN. You can also restrict certain dubious applications or programs such as trojans, worms, and other client/server viruses from contacting their server.
For example, some trojans scan networks for services on ports from 31337 to 31340 (called the elite ports in cracking terminology).
Since there are no legitimate services that communicate via these non-standard ports, blocking them can effectively diminish the chances that potentially infected nodes on your network independently communicate with their remote master servers.
The following rules drop all TCP traffic that attempts to use port 31337:
[root@myServer ~ ] # iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP [root@myServer ~ ] # iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP You can also block outside connections that attempt to spoof private IP address ranges to infiltrate your LAN.
For example, if your LAN uses the 192.168.1.0/24 range, you can design a rule that instructs the Internet-facing network device (for example, eth0) to drop any packets to that device with an address in your LAN IP range.
Because it is recommended to reject forwarded packets as a default policy, any other spoofed IP address to the external-facing device (eth0) is rejected automatically.
[root@myServer ~ ] # iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP Note
There is a distinction between the DROP and REJECT targets when dealing with appended rules.
The REJECT target denies access and returns a connection refused error to users who attempt to connect to the service. The DROP target, as the name implies, drops the packet without any warning.
Administrators can use their own discretion when using these targets. However, to avoid user confusion and attempts to continue connecting, the REJECT target is recommended
IPTables and Connection Tracking
You can inspect and restrict connections to services based on their connection state. A module within iptables uses a method called connection tracking to store information about incoming connections. You can allow or deny access based on the following connection states:
-
NEW — A packet requesting a new connection, such as an HTTP request.
-
ESTABLISHED — A packet that is part of an existing connection.
-
RELATED — A packet that is requesting a new connection but is part of an existing connection. For example, FTP uses port 21 to establish a connection, but data is transferred on a different port (typically port 20).
-
INVALID — A packet that is not part of any connections in the connection tracking table.
You can use the stateful functionality of iptables connection tracking with any network protocol, even if the protocol itself is stateless (such as UDP). The following example shows a rule that uses connection tracking to forward only the packets that are associated with an established connection:
[root@myServer ~ ] # iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
IPv6
The introduction of the next-generation Internet Protocol, called IPv6, expands beyond the 32-bit address limit of IPv4 (or IP). IPv6 supports 128-bit addresses, and carrier networks that are IPv6 aware are therefore able to address a larger number of routable addresses than IPv4.
Red Hat Enterprise Linux supports IPv6 firewall rules using the Netfilter 6 subsystem and the ip6tables command. In Red Hat Enterprise Linux 5, both IPv4 and IPv6 services are enabled by default.
The ip6tables command syntax is identical to iptables in every aspect except that it supports 128-bit addresses. For example, use the following command to enable SSH connections on an IPv6-aware network server:
[root@myServer ~ ] # ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 --dport 22 -j ACCEPT
For more information about IPv6 networking, refer to the IPv6 Information Page at http://www.ipv6.org/.
tetep aja belum paham nih...
*#@???... hah.. :pusing:
