Iptables (1)

Iptables configuration file:/etc/sysconfig/iptables

Confirm that the route forwarding function is turned on
Method 1:/sbin/sysctl-w Net.ipv4.ip_forward=1
Method 2:echo 1 >/proc/sys/net/ipv4/ip_forward
Method 3: Modify/etc/sysctl.conf, set Net.ipv4.ip_forward = 1

Set up route forwarding
[[email protected] ~]# vim/etc/sysctl.conf modified:
Net.ipv4.ip_forward = 1
[Email protected] ~]# sysctl-p Note: This setting is permanently active or:
[Email protected] ~]# echo 1 >/proc/sys/net/ipv4/ip_forward
Or:
[Email protected] ~]# sysctl-w net.ipv4.ip_forward=1
Note: This setting is for temporary health

[[email protected] ~]# iptables-a input-p tcp--dport 22-m limit--limit 3/minute--limit-burst 8-j LOG
[[E Mail protected] ~]# iptables-a input-p tcp--dport 22-j DROP
[[email protected] ~]# iptables-t filter-n MyLAN1
[[email protected] ~]# iptables-a forward-s 192.168.1.0/24-j MyLAN1
[[email protected] ~]# Iptables-a forward-d 192.168.1.0/24-j MyLAN1
[[email protected] ~]# iptables-a mylan1-p icmp-j DROP
[[Emai L protected] ~]# iptables-a MyLAN1 ...
[[email protected] ~]# iptables-x MyLAN1

[[email protected] ~]# iptables-t filter-a input-p tcp-j ACCEPT
[[email protected] ~]# Iptables-I INPU T-p udp-j Accept
[[email protected] ~]# iptables-i INPUT 2-p icmp-j Accept
[[email protected] ~]# Ipta bles-p input Drop
[[email protected] ~]# iptables-l input--line-numbers
Chain input (policy DROP)
Num Target prot opt source destination
1 accept UDP-anywhere anywhere
2 accept ICMP-anywhere anywhere
3 accept TCP-Anywhere anywhere

[[email protected] ~]# iptables-d INPUT 2
[[email protected] ~]# iptables-f
[[email  Protected] ~]# iptables-t nat-f
[[email protected] ~]# iptables-t raw-ntcp_packets
[[email protected ] ~]# iptables-t raw-l
Chain prerouting (Policy ACCEPT)
...
Chain OUTPUT (Policy ACCEPT)
...
Chain tcp_packets (0 references)
Target prot opt source destination
custom chain, which ultimately applies to the default chain, will work.
Custom chain, allow only fixed IP access to the destination IP ssh
#iptables-N testssh--Custom chain name
#iptables-A testssh-s 192.168.10.10/32-j ACCEPT
# Iptables-a input-p TCP--dport 22-j testssh--Apply a custom chain to the INPUT chain
Nat table, use the custom chain
#iptables-n test-t Nat
#iptables -A test-t nat-d 192.168.10.0/24-j SNAT--to 192.168.100.10
#iptables-A postrouting-t nat-s 192.168.21.0/24-j tes T

[[email protected] ~]# iptables-a forward-p TCP--dport 22-j ACCEPT
[[email protected] ~]# iptables-a output-p TCP--sport 20:80-j ACCEPT
[Email protected] ~]# iptables-i input-i eth1-p tcp--tcp-flags syn,rst,ack syn-j REJECT
[Email protected] ~]# iptables-a input-i eth0-p ICMP--icmp-type echo-request-j DROP
[[email protected] ~]# iptables-a input-p ICMP--icmp-type echo-reply-j ACCEPT

[[email protected] ~]# iptables-a forward-m mac--mac-source 00:0c:29:27:55:3f-j DROP
[Email protected] ~]# iptables-a input-p tcp-m multiport--dport 20,21,25,110,1250:1280-j ACCEPT
[Email protected] ~]# iptables-a forward-p tcp-m iprange--src-range 192.168.1.20-192.168.1.99-j DROP
New (a packet unrelated to any connection that typically represents a newly initiated data connection request)
Established (in response to a request or a connected packet, typically representing the server's normal response data)
Related (data packets that are related to an existing connection, such as the need to create a new data connection when uploading/downloading a file using FTP), the connection exists with the previous FTP control connection
Correlation
INVALID (indicates a packet of unknown origin, other than the above state, considered a dangerous package, all discarded. ）
? When someone is risking sending data with another host's IP address, the status of the server response packet received by the victim host is also "NEW" (because the machine has not sent a request), this class
Types of packets are generally discarded
The use of--syn is in the form of compatibility with older versions of Iptables
[Email protected] ~]# iptables-a forward-m State--state new-p TCP! --syn-j DROP
[Email protected] ~]# iptables-a input-p tcp-m State--state new-j DROP
[Email protected] ~]# iptables-a input-p tcp-m State--state established,related-j ACCEPT
? Export rules
–iptables-save
– Save rule information in conjunction with redirection output ">" Symbol
? Import Rules
–iptables-restore
– Combined with redirect input "<" symbol Recovery rule information
[Email protected] ~]# iptables-save >/etc/sysconfig/iptables
[Email protected] ~]# service iptables restart
[Email protected] ~]# chkconfig--level iptables on
[Email protected] ~]# Iptables-restore </etc/sysconfig/iptables
--------------------------Understand established
Vm1
# iptables-p INPUT DROP
Ping 192.168.56.201
SSH 192.168.56.201
All failed
# iptables-a input-p all-m State--state established-j ACCEPT
Ping 192.168.56.201
SSH 192.168.56.201
All success
VM2 shutting down the firewall
Successfully crossed the reverse firewall.
Tracerout 192.168.56.201 failure, the reason to see below
--------------------------Understand Relate
Vm1
# iptables-p INPUT DROP
# iptables-f
# iptables-a input-p all-m State--state related-j ACCEPT
Tracerout 192.168.56.201 success. The other packages produced by the first package belong to the relate state.
--------------------------Understand New
Vm1
The output default policy is drop. Other policies are accept
# iptables-p INPUT ACCEPT
# iptables-p OUTPUT DROP
# iptables-f
Ping 192.168.56.201
SSH 192.168.56.201
All failed
# iptables-a output-p all-m State--state established,new-j ACCEPT
--------------------------Understand invalid
He needs a special first hack tool to produce, so here's the urgent usage below.
Usually applied to the first of the input tables.
# iptables-a input-p all-m State--state invalid-j DROP
mangle table
Policy Routing
Policy Routing is now required on the intranet, all packets that access 80 ports through the TCP protocol are out of the chinanet line, and all packets that access UDP protocol port 53rd are
Get out of the cernet line.
Hit Mark:
Iptables-t mangle-a prerouting-i eth0-p tcp--dport 80-j MARK--set-mark 1
Iptables-t mangle-a prerouting-i eth0-p UDP--dprot 53-j MARK--set-mark 2
Note: After creating the routing rule, the #ip route flush cache must be executed if immediate effect is required; flush the route buffer
Build table
IP rule add from all fwmark 1 table 10
IP rule add from all fwmark 2 Table 20
(Fwmark 1 is the tag, table 1 is Route table 1.) It means that everything is tagged with 1 of the data using the TABLE10 routing table)
IP rule Show Show routing rules
Add a route rule
IP rule add from 192.168.1.10/32 table 1 pref 100
If the Pref value (priority) is not specified, it will be inserted before the existing rule minimum ordinal
Note: After creating the routing rule, the #ip route flush cache must be executed if immediate effect is required; flush the route buffer
Policy Routing:
IP route add default via 10.10.1.1 dev eth1 table 10
IP route add default via 10.10.2.1 dev eth2 table 20
Raw table
The priority of 4 tables is from high to low in order: Raw-->mangle-->nat-->filter
For example: If there is a mangle table on the prrouting chain, and there is a NAT table, then the mangle is processed and then processed by the NAT table
Raw tables are used only on prerouting chains and output chains, because the highest priority is available, allowing the packets received to be processed before connection tracking. One but the user uses
Raw table, on a chain, after the raw table is processed, the NAT table and the Ip_conntrack processing are skipped, that is, the address translation and link tracking of the packet is not processed.
Raw tables can be applied in situations where there is no need to do NAT to improve performance. such as a large number of access to the Web server, you can let the 80 port no longer let iptables do the packet tracking
Processing to increase the user's access speed.
How to execute instructions
Iptables-t raw-a prerouting-p TCP--dport 80-j notrack
Iptables-t raw-a prerouting-p TCP--sport 80-j notrack
Iptables-a forward-m State--state untracked-j ACCEPT
--------------------------------------------
Environment:
The live Web server provides a read of the display data by means of the Nginx+memcache mode, which is disconnected after each request to get the data.
Fault:
Cache server, cannot create new connection, message log error ip_conntrack:table full, dropping packet.
Cause the live web to fail, the same error ip_conntrack:table full, dropping packet.
Cause of failure: the link Tracking table is full, resulting in the inability to create a new connection.
A similar failure has occurred before, the solution is
Vi/etc/sysctl.conf
Net.ipv4.ip_conntrack_max = 65000 Increase link Tracking table size (Increase maximum tracking connection entry)
But after a period of time and the above problem, this shows that the number of visits really increased, resulting in the tracking table full, but also that the only increase this parameter can only solve the immediate problem,
A solution to the problem must be found.
The temporary adjustment of this failure
Vi/etc/sysctl.conf
Net.ipv4.ip_conntrack_max = 855360
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 1000 (Connection trace table time-out is not significant by testing this parameter, and the trace table is automatically cleared
Time does not have much to do with it, but it is reduced first, the default value is 7 days)
Vi/etc/modprobe.conf
Options Ip_conntrack hashsize=855360
Sets the number of buckets. Improves performance to reduce kernel traversal time.
Simple explanation:
The parameters above are all parameters iptables, iptables to handle the packet, the packet is tracked.
If Iptables is turned off, the above failure will not occur, but is unlikely.
-Maximum allowed tracking connection entry, Conntrack_max
-Stores the number of Hassi that track the list of connection entries, Hashsize, the number of buckets
To access a trace connection entry for a particular package, the kernel must:
Calculates the Hasi value for some of the characters already defined in a package. This is an uninterrupted calculation.
This value will be used as an index to Hassi, and the list of trace connection entries is stored here.
Repeatedly view the trace connection entries in the list of links to find the one that matches.
This is a resource-intensive operation that relies on the size of the list (and also on the location of the tracked connection entries that are manipulated in the list).
This list is a bucket, hashsize is the number of these buckets, the number of entries in each bucket is conntrack_max/hashsize
If Conntrack_max=hashsize then the list size is one, you can reduce the number of traversal, improve performance, if the memory is large enough
Iptables The concept of this bucket is similar to the concept of the LVS kernel bucket.
Complete resolution: Turn off tracing.
Live Web Server
Vi/etc/sysconfig/iptables
*raw
:P rerouting ACCEPT [0:0]
: OUTPUT ACCEPT [0:0]
-A prerouting-p tcp-m tcp--dport 80-j notrack
-A prerouting-p tcp-m tcp--dport 10240:65000-j notrack
-A output-p tcp-m tcp--sport 80-j notrack
-A output-p tcp-m tcp--sport 10240:65000-j notrack
COMMIT
Note that the filter should add this sentence.
-A rh-firewall-1-input-m state--state established,related,untracked-j ACCEPT
Back-End cache server
Vi/etc/sysconfig/iptables
*raw
:P rerouting ACCEPT [0:0]
: OUTPUT ACCEPT [0:0]
-A prerouting-p tcp-m tcp--dport 80-j notrack
-A output-p tcp-m tcp--sport 80-j notrack
-A prerouting-p tcp-m tcp--dport 11211-j notrack
-A output-p tcp-m tcp--sport 11211-j notrack
COMMIT
Remove the trace from Port 80 and port 11211.
Using Apache AB test to observe the/proc/net/ip_conntrack effect is obvious
If the web-side configuration
-A prerouting-p tcp-m tcp--dport 11211-j notrack
-A output-p tcp-m tcp--sport 11211-j notrack
is meaningless, the link tracking table will also record the connection to the backend cache entries, if you want to add a source IP address such as-s, then the connection to the back end 11211 packets will be sealed, (measured
Result) So the rules are definitely not so, the specific rules have to be studied.
For the cache server, the above configuration is very complete.
By observing the contents of the Link Tracking table (/proc/net/ip_conntrack), we found a large number of connection entries in the back-end cache 11211 Port of the live Web connection, the source port is 10,000
Above the port. And the Web server also has a large number of 80 port connections, which do not
Need to be processed, so do not follow these links.
Because the output priority of raw is higher than filter input, if set to 1024:65000-j Notrack, then these ports will be allowed access, so set to
10240:65000, filter input is not blocked, but applications that are launched later
Port of service Note that you must select a port below 10240 to define it yourself. Although 10,240:65,000 of these ports can be scanned on the public network, but because there is no service correspondence, so
There will be no problem.
Also investigate how the ports that access the backend can be accurately removed from the trace.
The above thinking is quite chaotic, the key point wants to reverse, the following is correct
By observing the study
Cat/proc/net/ip_conntrack
TCP 6 431946 established src=192.168.0.18 dst=192.168.0.17 sport=52292 dport=3306 packets=1 bytes=52 src=192.168.0.17
dst=192.168.0.18 sport=3306 dport=52292 Packets=1
bytes=52 use=1
TCP 6 431999 established src=192.168.0.18 dst=192.168.0.165 sport=22 dport=2676 packets=27 bytes=2128 src=192.168.0.165
dst=192.168.0.18 sport=2676 dport=22 packets=26
bytes=1664 [assured] use=1
After a test study, and after several iptables-tutorial, the accurate removal of the tracking results
Web server
*raw
:P rerouting ACCEPT [0:0]
: OUTPUT ACCEPT [0:0]
-A prerouting-p tcp-m tcp--dport 80-j notrack
-A prerouting-p tcp-m TCP--sport 11211-j notrack the rule returned to 18 from 17 of 11211 ports
-A output-p tcp-m tcp--sport 80-j notrack
-A output-p tcp-m tcp--dport 11211-j notrack 11211-port rule from 18 out to 17
COMMIT
The test results show that if the output is set to the relevant port, then the prerouting must make rules for the port set on the output, otherwise the packet cannot go out. (Actually is
Not come back)
The reasons are as follows
The status of connection tracking is triggered mainly in two places, one is prerouting, the other is output, they correspond to foreign messages and this level of generation of messages. For example I
Send a message from this level, then in the output chain, its status will become new, when we receive the response message, the connection state is prerouting
Change to established, and so on. To join the first message is not what we tried, then the prerouting out is set to new, and then we send a reply,
The output is set to established.

Iptables (1)