过程我们求淡化，心酸我们自己扛。带给心爱的永远是最轻松的拥抱和大笔的存款！ i hate gcd&gov u a son of a bitch
2009/07/26
2009/07/18
毛泽东是他妈的呆B 是土匪 是汉奸
毛泽东在1937年8月在陕北洛川会议上的讲话：
"要冷静，不要到前线去充当抗日英雄，要避开与日本的正面冲突，绕到日军后方去打游击，要想办法扩充八路军、建立抗日游击根据地，要千方百计地积蓄和壮大我党的武装力量。对政府方面催促的开赴前线的命令，要以各种借口予以推拖，只有在日军大大杀伤国军之后，我们才能坐收抗日成果，去夺取国民党的政权。"
"有的人认为我们应该多抗日，才爱国，但那爱的是蒋介石的国，我们中国共产党人祖国是全世界共产党人共同的祖国即苏维埃(苏联)。我们共产党人的方针是，要让日本军队多占地，形成蒋、日、我，三国志，这样的形势对我们才有利，最糟糕的情况不过是日本人占领了全中国，到时候我也还可以借助苏联的力量打回来嘛！"
"为了发展壮大我党的武装力量，在战后夺取全国政权。我们党必须严格遵循的总方针是"一分抗日，二分应付，七分发展"。任何人，任何组织都不得违背这个总体方针。"
摘抄文字均见于《毛泽东选集》人民出版社，1967年版。
2009/06/06
2009/05/26
2009/05/14
2009/05/03
精辟 太精辟了 没有成功的经验，只有被拒绝的经验
没有成功的经验，只有被拒绝的经验。哈哈哈，楼主你不觉得他很幽默吗？幽默中带着酸苦！追女人其实就一条原则，不要把女人看得太重，在物质与精神中提升自己，当提升到一定程度的时候，自然会把女人的目光吸引过来，这个时候男人就掌握了主动权，选那些女人中物质和精神条件好的，哪会像楼主故事中的那位那样，吃力还不讨好。不过这种方式有个缺陷，只能找个结婚的人，喜欢才会紧张，在乎才会黏人，男女适用。追女人本质上就是件劳命伤财的事情。
男人和女人之争，永远都会延续下去，有时男人会占上风，如褪去青涩，走向成熟时，男人世界里的竞争激烈得像一场战争，再单纯的人也会自发或不由自主的改变自己；有时女人会占上风，如双十年华，青春可人之时，同年龄段的男生大部分都还处于傻小子状态。
楼主的相亲之路估计也已经走了不少了吧，不知道修成正果没有？
2009/03/26
Linux系统Iptables规则执行顺序详细讲解
预备知识(转)： iptable有三种队列(表)规则，mangle queue， filter queue， nat queue。
1。The first is the mangle table which is responsible for the alteration of quality of service bits in the TCP header.
2。The second table is the filter queue which is responsible for packet filtering.
* Forward chain: Filters packets to servers protected by the firewall.
* Input chain: Filters packets destined for the firewall.
* Output chain: Filters packets originating from the firewall.
3。The third table is the nat queue which is responsible for network address translation. It has two built-in chains; these are:
* Pre-routing chain: NATs packets when the destination address of the packet needs to be changed.
* Post-routing chain: NATs packets when the source address of the packet needs to be changed
个人总结：
iptables执行规则时，是从从规则表中从上至下顺序执行的，如果没遇到匹配的规则，就一条一条往下执行，如果遇到匹配的规则后，那么就执行本规则，执行后根据本规则的动作(accept, reject, log等)，决定下一步执行的情况，后续执行一般有三种情况。
1。一种是继续执行当前规则队列内的下一条规则。比如执行过Filter队列内的LOG后，还会执行Filter队列内的下一条规则。
2。一种是中止当前规则队列的执行，转到下一条规则队列。比如从执行过accept后就中断Filter队列内其它规则，跳到nat队列规则去执行
3。一种是中止所有规则队列的执行。
iptables 是采用规则堆栈的方式来进行过滤，当一个封包进入网卡，会先检查 Prerouting，然后检查目的 IP 判断是否需要转送出去，接着就会跳到 INPUT 或 Forward 进行过滤，如果封包需转送处理则检查 Postrouting，如果是来自本机封包，则检查 OUTPUT 以及 Postrouting。过程中如果符合某条规则将会进行处理，处理动作除了 ACCEPT、REJECT、DROP、REDIRECT 和 MASQUERADE 以外，还多出 LOG、ULOG、DNAT、SNAT、MIRROR、QUEUE、RETURN、TOS、TTL、MARK 等，其中某些处理动作不会中断过滤程序，某些处理动作则会中断同一规则炼的过滤，并依照前述流程继续进行下一个规则炼的过滤（注意：这一点与 ipchains 不同），一直到堆栈中的规则检查完毕为止。透过这种机制所带来的好处是，我们可以进行复杂、多重的封包过滤，简单的说，iptables 可以进行纵横交错式的过滤（tables）而非炼状过滤（chains）。
ACCEPT 将封包放行，进行完此处理动作后，将不再比对其它规则，直接跳往下一个规则炼（nat:postrouting）。
REJECT 拦阻该封包，并传送封包通知对方，可以传送的封包有几个选择：ICMP port-unreachable、ICMP echo-reply 或是 tcp-reset（这个封包会要求对方关闭联机），进行完此处理动作后，将不再比对其它规则，直接 中断过滤程序。 范例如下：
iptables -A FORWARD -p TCP --dport 22 -j REJECT --reject-with tcp-reset
DROP 丢弃封包不予处理，进行完此处理动作后，将不再比对其它规则，直接中断过滤程序。
REDIRECT 将封包重新导向到另一个端口（PNAT），进行完此处理动作后，将 会继续比对其它规则。 这个功能可以用来实作通透式 porxy 或用来保护 web 服务器。例如：iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
MASQUERADE 改写封包来源 IP 为防火墙 NIC IP，可以指定 port 对应的范围，进行完此处理动作后，直接跳往下一个规则炼（mangle:postrouting）。这个功能与 SNAT 略有不同，当进行 IP 伪装时，不需指定要伪装成哪个 IP，IP 会从网卡直接读取，当使用拨接连线时，IP 通常是由 ISP 公司的 DHCP 服务器指派的，这个时候 MASQUERADE 特别有用。范例如下：
iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE --to-ports 1024-31000
LOG 将封包相关讯息纪录在 /var/log 中，详细位置请查阅 /etc/syslog.conf 组态档，进行完此处理动作后，将会继续比对其它规则。例如：
iptables -A INPUT -p tcp -j LOG --log-prefix "INPUT packets"
SNAT 改写封包来源 IP 为某特定 IP 或 IP 范围，可以指定 port 对应的范围，进行完此处理动作后，将直接跳往下一个规则炼（mangle:postrouting）。范例如下：
iptables -t nat -A POSTROUTING -p tcp-o eth0 -j SNAT --to-source 194.236.50.155-194.236.50.160:1024-32000
DNAT 改写封包目的地 IP 为某特定 IP 或 IP 范围，可以指定 port 对应的范围，进行完此处理动作后，将会直接跳往下一个规则炼（filter:input 或 filter:forward）。范例如下：
iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10:80-100
MIRROR 镜射封包，也就是将来源 IP 与目的地 IP 对调后，将封包送回，进行完此处理动作后，将会中断过滤程序。
QUEUE 中断过滤程序，将封包放入队列，交给其它程序处理。透过自行开发的处理程序，可以进行其它应用，例如：计算联机费用.......等。
RETURN 结束在目前规则炼中的过滤程序，返回主规则炼继续过滤，如果把自订规则炼看成是一个子程序，那么这个动作，就相当于提早结束子程序并返回到主程序中。
MARK 将封包标上某个代号，以便提供作为后续过滤的条件判断依据，进行完此处理动作后，将会继续比对其它规则。范例如下：
iptables -t mangle -A PREROUTING -p tcp --dport 22 -j MARK --set-mark 2
iptables 小例子
iptables
来源: ChinaUnix博客 日期： 2008.08.31 09:29 (共有0条评论) 我要评论
网络安全
* 防火墙原理
* netfilter架构
* iptables命令
* NAT地址转换
-----------------
防火墙在接入点过滤数据包保护内网,支持包过滤技术,由linux内核的netfilter支持
INPUT,OUTPUT保护本机;FORWARD转发,保护网络[内网]
条件的叠加称为链
INPUT进入本机的数据包
OUTPUT本机发送的数据包
FORWARD本机路由的数据包
数据包:源地址,目标地址,协议类型->本机路由决定怎么走->INPUT,OUTPUT,FORWARD
处理方式:DROP,ACCEPT,REJECT,LOG
# iptables -A INPUT -j icmp DROP
# iptables --help |less
# iptables -L -n --line-numbers #显示条件编号
----------------------------
过滤
# iptables -A INPUT -p tcp -d 192.168.0.101 --dport 22 -j ACCEPT
# iptables -A OUTPUT -p tcp -s 192.168.0.101 --sport 22 -j ACCEPT
# iptables -P INPUT DROP
# iptables -P OUTPUT DROP
# iptables -P FORWARD DROP
# iptables -A INPUT -p tcp -d 192.168.0.101 --dport 80 -j ACCEPT
# iptables -A OUTPUT -p tcp -s 192.168.0.101 --sport 80 -j ACCEPT
# grep domain /etc/services #域名解析53
# iptables -A OUTPUT -p udp -s 192.168.0.101 --dport 53 -j ACCEPT #client
# iptables -A INPUT -p udp -d 192.168.0.101 --sport 53 -j ACCEPT #client
# host
www.baidu.com
# iptables -A INPUT -p udp -d 192.168.0.101 --dport 53 -j ACCEPT #server
# iptables -A INPUT -p udp -s 192.168.0.101 --sport 53 -j ACCEPT #server
# iptables -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT#已连接的行
# iptables -D OUTPUT 1 #确定了再弄
# iptables -A OUTPUT -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
# iptables -D OUTPUT 1
这样22,80只匹配已连接的;如果只是客户机,ssh的input也应匹配ESTABLISHED
# service iptables save
# iptables-save>/root/fw/1.rule
----------------------------
日志 数据包没被丢弃,通过的情况下记录
# iptables -A INPUT -p tcp --dport 22 -j LOG --log-level 5 --log-prefix "IPTABLES:"
# vi /etc/syslog.conf #+
kern.=notice /var/log/firewall.log
#kern 消息产生来源,=notice man syslog; man syslog.conf #notic=5
# service syslog restart
# iptables -I INPUT 1 -p tcp --dport 22 -j LOG --log-level 5 --log-prefix "iptables:"
# 要放在ssh前边
# tail -f /var/log/firewall.log #现在就有实时记录
关于iptables DNS端口开放的问题。
For DNS can work:
-----cut------
-A INPUT -p udp -m udp -s 192.168.0.0/24 --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp -m state -s 192.168.0.0/24 --dport 53 --state NEW -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp -m state --dport 53 --state NEW -j ACCEPT
-----cut-------
Deployment_Guide-en-US/ch-fw.html
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">http://www.w3.org/1999/xhtml">
42.8. Firewalls
Information security is commonly thought of as a process and not a product. However, standard security implementations usually employ some form of dedicated mechanism to control access privileges and restrict network resources to users who are authorized, identifiable, and traceable. Red Hat Enterprise Linux includes several tools to assist administrators and security engineers with network-level access control issues.
Firewalls are one of the core components of a network security implementation. Several vendors market firewall solutions catering to all levels of the marketplace: from home users protecting one PC to data center solutions safeguarding vital enterprise information. Firewalls can be stand-alone hardware solutions, such as firewall appliances by Cisco, Nokia, and Sonicwall. Vendors such as Checkpoint, McAfee, and Symantec have also developed proprietary software firewall solutions for home and business markets.
Apart from the differences between hardware and software firewalls, there are also differences in the way firewalls function that separate one solution from another. Table 42.2, “Firewall Types” details three common types of firewalls and how they function:
| Method | Description | Advantages | Disadvantages | ||||||
|---|---|---|---|---|---|---|---|---|---|
| NAT | Network Address Translation (NAT) places private IP subnetworks behind one or a small pool of public IP addresses, masquerading all requests to one source rather than several. The Linux kernel has built-in NAT functionality through the Netfilter kernel subsystem. |
|
| ||||||
| Packet Filter | A packet filtering firewall reads each data packet that passes through a LAN. It can read and process packets by header information and filters the packet based on sets of programmable rules implemented by the firewall administrator. The Linux kernel has built-in packet filtering functionality through the Netfilter kernel subsystem. |
|
| ||||||
| Proxy | Proxy firewalls filter all requests of a certain protocol or type from LAN clients to a proxy machine, which then makes those requests to the Internet on behalf of the local client. A proxy machine acts as a buffer between malicious remote users and the internal network client machines. |
|
|
Table 42.2. Firewall Types
The Linux kernel features a powerful networking subsystem called Netfilter. The Netfilter subsystem provides stateful or stateless packet filtering as well as NAT and IP masquerading services. Netfilter also has the ability to mangle IP header information for advanced routing and connection state management. Netfilter is controlled using the iptables tool.
The power and flexibility of Netfilter is implemented using the iptables administration tool, a command line tool similar in syntax to its predecessor, ipchains.
A similar syntax does not mean similar implementation, however. ipchains requires intricate rule sets for: filtering source paths; filtering destination paths; and filtering both source and destination connection ports.
By contrast, iptables uses the Netfilter subsystem to enhance network connection, inspection, and processing. iptables features advanced logging, pre- and post-routing actions, network address translation, and port forwarding, all in one command line interface.
This section provides an overview of iptables. For more detailed information, refer to Section 42.9, “IPTables”.
Just as a firewall in a building attempts to prevent a fire from spreading, a computer firewall attempts to prevent malicious software from spreading to your computer. It also helps to prevent unauthorized users from accessing your computer.
In a default Red Hat Enterprise Linux installation, a firewall exists between your computer or network and any untrusted networks, for example the Internet. It determines which services on your computer remote users can access. A properly configured firewall can greatly increase the security of your system. It is recommended that you configure a firewall for any Red Hat Enterprise Linux system with an Internet connection.
During the Firewall Configuration screen of the Red Hat Enterprise Linux installation, you were given the option to enable a basic firewall as well as to allow specific devices, incoming services, and ports.
After installation, you can change this preference by using the Security Level Configuration Tool.
To start this application, use the following command:
[root@myServer ~] # system-config-selinux
Note
The Security Level Configuration Tool only configures a basic firewall. If the system needs more complex rules, refer to Section 42.9, “IPTables” for details on configuring specific iptables rules.
Select one of the following options for the firewall:
Disabled — Disabling the firewall provides complete access to your system and does no security checking. This should only be selected if you are running on a trusted network (not the Internet) or need to configure a custom firewall using the iptables command line tool.
Warning
Firewall configurations and any customized firewall rules are stored in the /etc/sysconfig/iptables file. If you choose Disabled and click OK, these configurations and firewall rules will be lost.
Enabled — This option configures the system to reject incoming connections that are not in response to outbound requests, such as DNS replies or DHCP requests. If access to services running on this machine is needed, you can choose to allow specific services through the firewall.
If you are connecting your system to the Internet, but do not plan to run a server, this is the safest choice.
Enabling options in the Trusted services list allows the specified service to pass through the firewall.
- WWW (HTTP)
The HTTP protocol is used by Apache (and by other Web servers) to serve web pages. If you plan on making your Web server publicly available, select this check box. This option is not required for viewing pages locally or for developing web pages. This service requires that the httpd package be installed.
Enabling WWW (HTTP) will not open a port for HTTPS, the SSL version of HTTP. If this service is required, select the Secure WWW (HTTPS) check box.
- FTP
The FTP protocol is used to transfer files between machines on a network. If you plan on making your FTP server publicly available, select this check box. This service requires that the vsftpd package be installed.
- SSH
Secure Shell (SSH) is a suite of tools for logging into and executing commands on a remote machine. To allow remote access to the machine via ssh, select this check box. This service requires that the openssh-server package be installed.
- Telnet
Telnet is a protocol for logging into remote machines. Telnet communications are unencrypted and provide no security from network snooping. Allowing incoming Telnet access is not recommended. To allow remote access to the machine via telnet, select this check box. This service requires that the telnet-server package be installed.
- Mail (SMTP)
SMTP is a protocol that allows remote hosts to connect directly to your machine to deliver mail. You do not need to enable this service if you collect your mail from your ISP's server using POP3 or IMAP, or if you use a tool such as fetchmail. To allow delivery of mail to your machine, select this check box. Note that an improperly configured SMTP server can allow remote machines to use your server to send spam.
- NFS4
The Network File System (NFS) is a file sharing protocol commonly used on *NIX systems. Version 4 of this protocol is more secure than its predecessors. If you want to share files or directories on your system with other network users, select this check box.
- Samba
Samba is an implementation of Microsoft's proprietary SMB networking protocol. If you need to share files, directories, or locally-connected printers with Microsoft Windows machines, select this check box.
The Security Level Configuration Tool includes an Other ports section for specifying custom IP ports as being trusted by iptables. For example, to allow IRC and Internet printing protocol (IPP) to pass through the firewall, add the following to the Other ports section:
194:tcp,631:tcp
Click OK to save the changes and enable or disable the firewall. If Enable firewall was selected, the options selected are translated to iptables commands and written to the /etc/sysconfig/iptables file. The iptables service is also started so that the firewall is activated immediately after saving the selected options. If Disable firewall was selected, the /etc/sysconfig/iptables file is removed and the iptables service is stopped immediately.
The selected options are also written to the /etc/sysconfig/system-config-selinux file so that the settings can be restored the next time the application is started. Do not edit this file by hand.
Even though the firewall is activated immediately, the iptables service is not configured to start automatically at boot time. Refer to Section 42.8.2.6, “Activating the IPTables Service” for more information.
The firewall rules are only active if the iptables service is running. To manually start the service, use the following command:
[root@myServer ~] # service iptables restart
To ensure that iptables starts when the system is booted, use the following command:
[root@myServer ~] # chkconfig --level 345 iptables on
The ipchains service is not included in Red Hat Enterprise Linux. However, if ipchains is installed (for example, an upgrade was performed and the system had ipchains previously installed), the ipchains and iptables services should not be activated simultaneously. To make sure the ipchains service is disabled and configured not to start at boot time, use the following two commands:
[root@myServer ~] # service ipchains stop[root@myServer ~] # chkconfig --level 345 ipchains off
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
Note
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
This forces iptables to start whenever the system is booted into runlevel 3, 4, or 5.
The following sample iptables command illustrates the basic command syntax:
[root@myServer ~ ] # iptables -A <chain> -j <target>
The -A option specifies that the rule be appended to <chain>. 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 <target> 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[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.
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.
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[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.
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
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.
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.
Note
If you have a default policy of DROP in your FORWARD chain, you must append a rule to forward all incoming HTTP requests so that destination NAT routing is possible. To do this, use the following command:
[root@myServer ~ ] # iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j ACCEPT
This rule forwards all incoming HTTP requests from the firewall to the intended destination; the Apache HTTP Server behind the firewall.
You can create iptables rules to route traffic to certain machines, such as a dedicated HTTP or FTP server, in a demilitarized zone (DMZ). A DMZ is a special local subnetwork dedicated to providing services on a public carrier, such as the Internet.
For example, to set a rule for routing incoming HTTP requests to a dedicated HTTP server at 10.0.4.2 (outside of the 192.168.1.0/24 range of the LAN), NAT uses the PREROUTING table to forward the packets to the appropriate destination:
[root@myServer ~ ] # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.0.4.2:80
With this command, all HTTP connections to port 80 from outside of the LAN are routed to the HTTP server on a network separate from the rest of the internal network. This form of network segmentation can prove safer than allowing HTTP connections to a machine on the network.
If the HTTP server is configured to accept secure connections, then port 443 must be forwarded as well.
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.
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
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/.
There are several aspects to firewalls and the Linux Netfilter subsystem that could not be covered in this chapter. For more information, refer to the following resources.
Refer to Section 42.9, “IPTables” for more detailed information on the iptables command, including definitions for many command options.
The iptables man page contains a brief summary of the various options.
http://www.netfilter.org/ — The official homepage of the Netfilter and iptables project.
http://www.tldp.org/ — The Linux Documentation Project contains several useful guides relating to firewall creation and administration.
http://www.iana.org/assignments/port-numbers — The official list of registered and common service ports as assigned by the Internet Assigned Numbers Authority.
Red Hat Linux Firewalls, by Bill McCarty; Red Hat Press — a comprehensive reference to building network and server firewalls using open source packet filtering technology such as Netfilter and iptables. It includes topics that cover analyzing firewall logs, developing firewall rules, and customizing your firewall using various graphical tools.
Linux Firewalls, by Robert Ziegler; New Riders Press — contains a wealth of information on building firewalls using both 2.2 kernel ipchains as well as Netfilter and iptables. Additional security topics such as remote access issues and intrusion detection systems are also covered.
Note: This documentation is provided {and copyrighted} by Red Hat®, Inc. and is released via the Open Publication License. The copyright holder has added the further requirement that Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. The CentOS project redistributes these original works (in their unmodified form) as a reference for CentOS-5 because CentOS-5 is built from publicly available, open source SRPMS. The documentation is unmodified to be compliant with upstream distribution policy. Neither CentOS-5 nor the CentOS Project are in any way affiliated with or sponsored by Red Hat®, Inc.
CentOs iptables abc
window.google_render_ad();
Login
FrontPage
Help
Tips and Tricks
How To
FAQs
Events
Contribute
Changelog
HowTos/Network/IPTables
Search:
HowTos
Network
IPTables
IPTables HOWTO
Contents
Introduction
Getting Started
Writing a Simple Rule Set
Interfaces
IP Addresses
Ports and Protocols
Putting It All Together
Summary
Links
1. Introduction
CentOS has an extremely powerful firewall built in, commonly referred to as iptables, but more accurately is iptables/netfilter. Iptables is the userspace module, the bit that you, the user, interact with at the command line to enter firewall rules into predefined tables. Netfilter is a kernel module, built into the kernel, that actually does the filtering. There are many GUI front ends for iptables that allow users to add or define rules based on a point and click user interface, but these often lack the flexibility of using the command line interface and limit the users understanding of what's really happening. We're going to learn the command line interface of iptables.
Before we can really get to grips with iptables, we need to have at least a basic understanding of the way it works. Iptables uses the concept of IP addresses, protocols (tcp, udp, icmp) and ports. We don't need to be experts in these to get started (as we can look up any of the information we need), but it helps to have a general understanding.
Iptables places rules into predefined chains (INPUT, OUTPUT and FORWARD) that are checked against any network traffic (IP packets) relevant to those chains and a decision is made about what to do with each packet based upon the outcome of those rules, i.e. accepting or dropping the packet. These actions are referred to as targets, of which the two most common predefined targets are DROP to drop a packet or ACCEPT to accept a packet.
Chains
These are 3 predefined chains in the filter table to which we can add rules for processing IP packets passing through those chains. These chains are:
INPUT - All packets destined for the host computer.
OUTPUT - All packets originating from the host computer.
FORWARD - All packets neither destined for nor originating from the host computer, but passing through (routed by) the host computer. This chain is used if you are using your computer as a router.
For the most part, we are going to be dealing with the INPUT chain to filter packets entering our machine - that is, keeping the bad guys out.
Rules are added in a list to each chain. A packet is checked against each rule in turn, starting at the top, and if it matches that rule, then an action is taken such as accepting (ACCEPT) or dropping (DROP) the packet. Once a rule has been matched and an action taken, then the packet is processed according to the outcome of that rule and isn't processed by further rules in the chain. If a packet passes down through all the rules in the chain and reaches the bottom without being matched against any rule, then the default action for that chain is taken. This is referred to as the default policy and may be set to either ACCEPT or DROP the packet.
The concept of default policies within chains raises two fundamental possibilities that we must first consider before we decide how we are going to organize our firewall.
1. We can set a default policy to DROP all packets and then add rules to specifically allow (ACCEPT) packets that may be from trusted IP addresses, or for certain ports on which we have services running such as bittorrent, FTP server, Web Server, Samba file server etc.
or alternatively,
2. We can set a default policy to ACCEPT all packets and then add rules to specifically block (DROP) packets that may be from specific nuisance IP addresses or ranges, or for certain ports on which we have private services or no services running.
Generally, option 1 above is used for the INPUT chain where we want to control what is allowed to access our machine and option 2 would be used for the OUTPUT chain where we generally trust the traffic that is leaving (originating from) our machine.
2. Getting Started
Working with iptables from the command line requires root privileges, so you will need to become root for most things we will be doing.
IMPORTANT: We will be turning off iptables and resetting your firewall rules, so if you are reliant on your Linux firewall as your primary line of defense you should be aware of this.
Iptables should be installed by default on all CentOS 3.x, 4.x and 5.x installations. You can check to see if iptables is installed on your system by:
$ rpm -q iptables
iptables-1.3.5-1.2.1
And to see if iptables is actually running, we can check that the iptables modules are loaded and use the -L switch to inspect the currently loaded rules:
# lsmod grep ip_tables
ip_tables 29288 1 iptable_filter
x_tables 29192 6 ip6t_REJECT,ip6_tables,ipt_REJECT,xt_state,xt_tcpudp,ip_tables
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Above we see the default set of rules in addition to access to the SSH service.
If iptables is not running, you can enable it by running:
# system-config-securitylevel
3. Writing a Simple Rule Set
IMPORTANT: At this point we are going to clear the default rule set. If you are connecting remotely to a server via SSH for this tutorial then there is a very real possibility that you could lock yourself out of your machine. You must set the default input policy to accept before flushing the current rules, and then add a rule at the start to explicitly allow yourself access to prevent against locking yourself out.
We will use an example based approach to examine the various iptables commands. In this first example, we will create a very simple set of rules to set up a Stateful Packet Inspection (SPI) firewall that will allow all outgoing connections but block all unwanted incoming connections:
# iptables -P INPUT ACCEPT
# iptables -F
# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P OUTPUT ACCEPT
# iptables -A INPUT -i lo -j ACCEPT
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -L -v
which should give the following output:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo any anywhere anywhere
0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Now lets look at each of the 8 commands above in turn and understand exactly what we've just done:
iptables -P INPUT ACCEPT If connecting remotely we must first temporarily set the default policy on the INPUT chain to ACCEPT otherwise once we flush the current rules we will be locked out of our server.
iptables -F We used the -F switch to flush all existing rules so we start with a clean state from which to add new rules.
iptables -A INPUT -p tcp --dport 22 -j ACCEPT Here we add a rule allowing SSH connections over tcp port 22. This is to prevent accidental lockouts when working on remote systems over an SSH connection. We will explain this rule in more detail later.
iptables -P INPUT DROP The -P switch sets the default policy on the specified chain. So now we can set the default policy on the INPUT chain to DROP. This means that if an incoming packet does not match one of the following rules it will be dropped. If we were connecting remotely via SSH and had not added the rule above, we would have just locked ourself out of the system at this point.
iptables -P FORWARD DROP Similarly, here we've set the default policy on the FORWARD chain to DROP as we're not using our computer as a router so there should not be any packets passing through our computer.
iptables -P OUTPUT ACCEPT and finally, we've set the default policy on the OUTPUT chain to ACCEPT as we want to allow all outgoing traffic (as we trust our users).
iptables -A INPUT -i lo -j ACCEPT Now it's time to start adding some rules. We use the -A switch to append (or add) a rule to a specific chain, the INPUT chain in this instance. Then we use the -i switch (for interface) to specify packets matching or destined for the lo (localhost, 127.0.0.1) interface and finally -j (jump) to the target action for packets matching the rule - in this case ACCEPT. So this rule will allow all incoming packets destined for the localhost interface to be accepted. This is generally required as many software applications expect to be able to communicate with the localhost adaptor.
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT This is the rule that does most of the work, and again we are adding (-A) it to the INPUT chain. Here we're using the -m switch to load a module (state). The state module is able to examine the state of a packet and determine if it is NEW, ESTABLISHED or RELATED. NEW refers to incoming packets that are new incoming connections that weren't initiated by the host system. ESTABLISHED and RELATED refers to incoming packets that are part of an already established connection or related to and already established connection.
iptables -L -v Finally, we can list (-L) the rules we've just added to check they've been loaded correctly.
Finally, the last thing we need to do is save our rules so that next time we reboot our computer our rules are automatically reloaded:
# /sbin/service iptables save
This executes the iptables init script, which runs /sbin/iptables-save and writes the current iptables configuration to /etc/sysconfig/iptables. Upon reboot, the iptables init script reapplies the rules saved in /etc/sysconfig/iptables by using the /sbin/iptables-restore command.
Obviously typing all these commands at the shell can become tedious, so by far the easiest way to work with iptables is to create a simple script to do it all for you. The above commands may be entered into your favourite text editor and saved as myfirewall, for example:
#!/bin/bash
#
# iptables example configuration script
#
# Flush all current rules from iptables
#
iptables -F
#
# Allow SSH connections on tcp port 22
# This is essential when working on remote servers via SSH to prevent locking yourself out of the system
#
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
#
# Set default policies for INPUT, FORWARD and OUTPUT chains
#
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
#
# Set access for localhost
#
iptables -A INPUT -i lo -j ACCEPT
#
# Accept packets belonging to established and related connections
#
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#
# Save settings
#
/sbin/service iptables save
#
# List rules
#
iptables -L -v
Note: We can also comment our script to remind us what were doing.
now make the script executable:
# chmod +x myfirewall
We can now simply edit our script and run it from the shell with the following command:
# ./myfirewall
4. Interfaces
In our previous example, we saw how we could accept all packets incoming on a particular interface, in this case the localhost interface:
iptables -A INPUT -i lo -j ACCEPT
Suppose we have 2 separate interfaces, eth0 which is our internal LAN connection and ppp0 dialup modem (or maybe eth1 for a nic) which is our external internet connection. We may want to allow all incoming packets on our internal LAN but still filter incoming packets on our external internet connection. We could do this as follows:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT
But be very careful - if we were to allow all packets for our external internet interface (for example, ppp0 dialup modem):
iptables -A INPUT -i ppp0 -j ACCEPT
we would have effectively just disabled our firewall!
5. IP Addresses
Opening up a whole interface to incoming packets may not be restrictive enough and you may want more control as to what to allow and what to reject. Lets suppose we have a small network of computers that use the 192.168.0.x private subnet. We can open up our firewall to incoming packets from a single trusted IP address (for example, 192.168.0.4):
# Accept packets from trusted IP addresses
iptables -A INPUT -s 192.168.0.4 -j ACCEPT # change the IP address as appropriate
Breaking this command down, we first append (-A) a rule to the INPUT chain for the source (-s) IP address 192.168.0.4 to ACCEPT all packets (also note how we can use the # symbol to add comments inline to document our script with anything after the # being ignored and treated as a comment).
Obviously if we want to allow incoming packets from a range of IP addresses, we could simply add a rule for each trusted IP address and that would work fine. But if we have a lot of them, it may be easier to add a range of IP addresses in one go. To do this, we can use a netmask or standard slash notation to specify a range of IP address. For example, if we wanted to open our firewall to all incoming packets from the complete 192.168.0.x (where x=1 to 254) range, we could use either of the following methods:
# Accept packets from trusted IP addresses
iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT # using standard slash notation
iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT # using a subnet mask
Finally, as well as filtering against a single IP address, we can also match against the MAC address for the given device. To do this, we need to load a module (the mac module) that allows filtering against mac addresses. Earlier we saw another example of using modules to extend the functionality of iptables when we used the state module to match for ESTABLISHED and RELATED packets. Here we use the mac module to check the mac address of the source of the packet in addition to it's IP address:
# Accept packets from trusted IP addresses
iptables -A INPUT -s 192.168.0.4 -m mac --mac-source 00:50:8D:FD:E6:32 -j ACCEPT
First we use -m mac to load the mac module and then we use --mac-source to specify the mac address of the source IP address (192.168.0.4). You will need to find out the mac address of each ethernet device you wish to filter against. Running ifconfig (or iwconfig for wireless devices) as root will provide you with the mac address.
This may be useful for preventing spoofing of the source IP address as it will allow any packets that genuinely originate from 192.168.0.4 (having the mac address 00:50:8D:FD:E6:32) but will block any packets that are spoofed to have come from that address. Note, mac address filtering won't work across the internet but it certainly works fine on a LAN.
6. Ports and Protocols
Above we have seen how we can add rules to our firewall to filter against packets matching a particular interface or a source IP address. This allows full access through our firewall to certain trusted sources (host PCs). Now we'll look at how we can filter against protocols and ports to further refine what incoming packets we allow and what we block.
Before we can begin, we need to know what protocol and port number a given service uses. For a simple example, lets look at bittorrent. Bittorrent uses the tcp protocol on port 6881, so we would need to allow all tcp packets on destination port (the port on which they arrive at our machine) 6881:
# Accept tcp packets on destination port 6881 (bittorrent)
iptables -A INPUT -p tcp --dport 6881 -j ACCEPT
Here we append (-A) a rule to the INPUT chain for packets matching the tcp protocol (-p tcp) and entering our machine on destination port 6881 (--dport 6881).
Note: In order to use matches such as destination or source ports (--dport or --sport), you must first specify the protocol (tcp, udp, icmp, all).
We can also extend the above to include a port range, for example, allowing all tcp packets on the range 6881 to 6890:
# Accept tcp packets on destination ports 6881-6890
iptables -A INPUT -p tcp --dport 6881:6890 -j ACCEPT
7. Putting It All Together
Now we've seen the basics, we can start combining these rules.
A popular UNIX/Linux service is the secure shell (SSH) service allowing remote logins. By default SSH uses port 22 and again uses the tcp protocol. So if we want to allow remote logins, we would need to allow tcp connections on port 22:
# Accept tcp packets on destination port 22 (SSH)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
This will open up port 22 (SSH) to all incoming tcp connections which poses a potential security threat as hackers could try brute force cracking on accounts with weak passwords. However, if we know the IP addresses of trusted remote machines that will be used to log on using SSH, we can limit access to only these source IP addresses. For example, if we just wanted to open up SSH access on our private lan (192.168.0.x), we can limit access to just this source IP address range:
# Accept tcp packets on destination port 22 (SSH) from private LAN
iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -j ACCEPT
Using source IP filtering allows us to securely open up SSH access on port 22 to only trusted IP addresses. For example, we could use this method to allow remote logins between work and home machines. To all other IP addresses, the port (and service) would appear closed as if the service were disabled so hackers using port scanning methods are likely to pass us by.
8. Summary
We've barely scratched the surface of what can be achieved with iptables, but hopefully this HOWTO has provided a good grounding in the basics from which one may build more complicated rule sets.
9. Links
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-fw.html
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-iptables.html
HowTos/Network/IPTables (last edited 2009-02-27 14:47:18 by NedSlider)
FrontPage
Help
Tips and Tricks
How To
FAQs
Events
Contribute
Changelog
HowTos/Network/IPTables
This wiki is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.
2009/02/04
丑女之殇
丑女之殇
丑女之殇 类型：都市·言情 作者：丑女又咋滴 发表于 MSN图书频道
引子
为什么用了“曾经”两字？因为现在虽然依旧称不上美女，却也告别了“丑女”这个称呼。中等，但胜在气质，这是很多朋友对我现在的评价。已经很知足，毕竟我们只是匆匆过客里头的小人物，不可能像《丑女大翻身》的女主角那样来个翻天覆地的大变化。
最近周围一个姐妹遭遇了情感创伤，原因是她的男朋友抛弃了外表并不咋滴的她，而转向了一个美女的怀抱。这样的故事很多，男人是爱美女的，最起码也要顺眼，这点我很理解，很多男性朋友都声称虽然并不是十分看重外表，但首要条件就是顺眼、舒服、能接受，这也决定了是否来电的前提。
可是，顺眼的要求是什么呢？我想一个体态臃肿，发型老土，衣着out的人是绝对不会让了看了很顺眼的。可很抱歉，这就是曾经的我，以至于这样的造型、这样的称谓陪伴了我可以很美好却变得很压抑的少女时代。
一、最糟糕的时代
其实我小时候并不难看，甚至还十分讨大人们的喜欢，白白嫩嫩嘴唇红红的。
这样的骄傲一直持续到青春期，那一场可以称的上浩劫的变化，直接影响了我少女时代的一切。青春期，身高始终是缓慢增长，可体重却直线飙升，这样的比例，你是可以想象的，接近120的体重，身高却在153左右徘徊，终年扎着万年不变的马尾辫，头发容易出油却因为懒一礼拜才洗一次看上去油腻腻的，脸也是胡乱擦几下就直接奔去学校的，肥硕的身体套在一套很过时的xl的童装里。虽然那已经是少女时代，从小学后半段一直到高中毕业，夸张的是那套超大的童装
一直没从衣柜里离开过。
这样的我，绝对是一个别人眼中不折不扣的丑女。
小学后半段的时候，因为大家年龄都不大，对丑不丑还不是十分在意，所以跟同学相处也比较融洽，毕竟那时候我比较活泼，学习也不错。
初中时代，已经慢慢的觉察出男同学不是很高兴跟我说话了，我的个性也由活泼变得沉默，上课时候睡睡觉，下课时候发发呆，所幸的是，学习成绩还是很不错，跟女同学关系也很好，所以也就这么打发着过日子。
高中时代，也是最为压抑的时代，因为那时候心智相对比较明白了，至少敏感的我，关于别人的讽刺和嘲笑还是听得懂看得明的。而且随着年龄的增长，对异性有种朦胧的期待，可这方面，总是最受打击的。那时候班级十分流行用班级里最丑的女生，作为羞辱别人的词汇，比如说：
某某某，那个谁（丑女名字）是你老婆吧？
放屁，是你老婆。
又比如说，某某（丑女名字）来了，然后大家恶作剧似的把一个戏弄对象推到那个丑女身上，哄堂大笑。
还有，骂别人就说某某（丑女名字）喜欢你，然后那个被骂的就作出呕吐状。
这样的事情，经历过的人，应该不会陌生吧，不管你是那个丑女也好，是那个被戏弄的也好，是那个戏弄别人的也罢。可
我很不幸，一直担当的是那个丑女的角色，被人呕吐着，辱骂着，甚至被自己暗恋的人所鄙视、嘲笑、讽刺，那样的滋味，简直就是欲哭无泪。
二、漫长的暗恋
情窦初开时候的爱情，也许还称不上是爱情，总是很刻骨铭心的。很多年过去了，也许你已经记不得他长什么样子，叫什么名字，却还能真真切切的怀念起自己的那份忽上忽下，就算能讲上一句话也会乐上半天的心境。
我是个早熟的孩子。
小学五年级的时候，那个暑假，我十分镇定的判断出自己的mc来了，因为平时看过相关的书籍，完全没有别的女孩的慌乱。
所以说，我是个心理上，生理上，都早熟的孩子。
小学四年级的时候，宇是我的同桌，他叫我肥妞，是个非常顽皮但又非常聪明的小男孩。
我们会分三八线，但他会在做手工课的时候帮我做手工；他叫我肥妞，却会帮我抄作业；我们会在学习中暗自较劲，也会为一点点小事打打闹闹追追跑跑；他喜欢找我说话，发现一点新鲜的事情，总是第一时间告诉我。
有一天，坐我们后排的一个小女生悄悄对我说，你，是不是喜欢宇？
当时肯定是否定了。可后来，因为这个问题，让我发现，我真的是好喜欢他。
我会为了跟他多走一段回家的路，谎称自己家的位置，其实这个谎言是那么不堪一击，只是那时候根本没有想到那么多；我会因为另一个女孩子跟他走的很近，而跟这个女孩子反目；我会努力跟上他的步伐，努力努力的学习，使得能让他对我刮目相看；我会在纸上写满他的名字，一遍又一遍。。。。。。
如果这都不算爱，还有什么好悲哀。
后来，上了初中，就不跟宇一个学校了。那时候，我总觉得心里的某个角落依然很温暖，就因为回忆起和宇一点一滴的事情，我总觉得，虽然我是肥妞，但他还是在乎我的，因为我是多么喜欢他啊。我常常想，当我在想他的时候，他会不会有一点点的想念我呢。
没有联系，一直到初2下半学期。有一次，全市组织的学科竞赛在我们学校举行，我知道，宇凭他的聪明一定会被选拔参赛的，所以，我也不能落后。很顺利，我进入了比赛。赛前，我在赛场外面焦急的张望，看着各个学校来的选手，希望能在人海中看到一个熟悉的身影。
此时，一个同学（我们共同的小学同学）叫我的名字，喊，宇找你呢。我转过头去，看见宇微笑的站在远处，似乎想说什么，可此时，铃声响了，大家匆匆走进试场。
就这样，这样的回眸成为初中三年唯一的定格，因为比赛结束后，我再也没找着他。如果就这样的错过，虽然会有遗憾，但总比高中发生的事情来的好，接着高中时期和宇的再次相遇，却成为记忆中永恒的噩梦。
三、关于初中生活的其他
初中三年，我给老师的印象大概就是爱睡觉，但是成绩还不错，所以也没怎么为难我。
初中三年，跟班里的男生讲过的话大概可以用手指头数的清楚了。我看见那些渐渐青涩的男生，跟漂亮的美女同学搭讪，互相打闹，很开心。由于内心一直还是渴望融合进集体的，所以我也会偶尔插几句话，但是往往我的搭话对男生来说是透明的，很少来理会我。渐渐的，我也慢慢接受了我是不受男生待见的这个事实，毕竟我有敏感的心，有自知之明。
故正如现在我老妈常唠叨的，读书时候，从没见男生打电话给你什么的，看来你是天生不会谈恋爱的，要嫁不出去了啊。我不辩解，只是笑，说，这还不是遗传的么？
我不知道你们有没有跟美女做过朋友的经历。初中时代曾经有2个美女朋友，一个让我满受打击，直至现在丝毫不联系，她是我小学同学兼初中同学，自从初中我开始慢慢变得自闭（其实在女生面前还是比较开朗的），尤其跟男生几乎没有交集，故有一天她很直接的跟说我，从今天起，我不跟你一起回去了（以前一直是一起骑车回家的），我说噢，知道了。然后中午我就看见她跟另一个美女一起回去了，旁边还有2个男同学，一起有说又笑的骑车回去了。我想，大概是她觉得我拖累她了吧。
另一个美女朋友，称她为可可吧，至今一直偶尔联系。她人还是不错的，至少对我不错，那就足够了，虽然也有其他朋友告诉我她喜欢跟你在一起只是为了衬托她的美。虽然后来事实验证了她后来找的女性朋友的确是那些貌中等偏下甚至有些抱歉的，但我不在乎，因为对我好，我已经很感激了。
后来发生了一点小插曲，初中三年唯一跟我讲话比较多的就是坐我后面的男生，立，喜欢上了可可。虽然后来他们没在一起，但我却似乎有种像失恋一样的痛，后来很多年过去了我才明白那时候我的心里竟然寂寞到为一个多讲了几句话的男生就吃醋的地步了，那是多么封闭和压抑的青春啊。
四、小小的幸福
中考虽然没发挥出自己的水平，但还是超市重点30几分，顺利地进入了本地最有名的a中。
在a中学校门口，张贴着录取名单，人群里三层外三层地围着看，多数是家长，可以说是比学生自己还焦急。
我其实家里已经通过关系得知被分配进了a中，其实没有什么悬念了。可我这次去看名单，就是为了寻找一个熟悉的名字。
终于，在榜单的第二张的名单里，我看到了我希望的答案。
宇，我们终于可以在同一个高中再次相遇了。
五、小计谋
高中新学期前，还面临着分班的问题。一般分班也不挑什么，就挑老师，那些口碑好的老师比较受欢迎。其实口碑好不好，就取决于他们以前带的那届毕业生最后高考成绩好不好，几个上清华北大，几个上重点，这才是大家关心的。
我猜想宇肯定会进所谓最好的班级，就是老师名气比较好，大家都趋之若鹜的班级。不为别的，因为宇家在我们当地算是名声显赫，有权有势的，所以进最好的班级肯定不成问题。
而我爸有个好兄弟在教育局当领导，所以拖一下关系，也能进最好的班级。我极力鼓吹爸妈给我找下关系，进最好的班级，借口为想好好学习，老师还是满重要的。爸妈自然是不知道我的真正动机的，所以我的小小计谋也很顺利的得逞了。
结果，很自然的，我跟宇，成了高一同班同学。
六、噩梦的开始
单纯的我曾经认为，能跟宇一个班级，一切都会变得美妙起来，我曾经平淡得压抑的青春岁月，也能丰富起来吧。倒不是希望宇也喜欢我，因为我的理智告诉我这是不可能的，我那么卑微，这不是我奢望的，我只是希望能偶尔说上几句话，那样该有多么美好呢。
但往往期望越大，失望越大。高一第一天开学典礼后是大扫除，我负责擦窗，宇是负责走廊的拖地。这时候，我才时隔3年第一次近距离看到宇，他依旧谈不上帅，但明显高了许多，173左右，想当年小学的时候才150几。宇的聪慧气质仍然保持着，这也是最吸引我的，所以使得我今后选择bf的标准曾经一度加了这么一条——不一定要帅，但一定要聪明。
和宇擦肩而过的那一刹那，我以为他会叫我，因为毕竟曾经是同桌啊，毕竟他曾经被我的笑话逗乐了对我说“你真可爱”，毕竟在参加我们学校的比赛时还曾经想跟我打招呼，但是，一切都没有，哪怕一个微笑。我清晰的记得他的表情，冷冷的，就像没看到一样，走过去。我看着他的背影，什么话也说不出来了。
我的期待，等了3年的期待，原来只是一个冰冷的转身。
可学习还得继续，生活还得继续，分位子的时候，我的同桌是一个圆脸的很开朗的女生，暂时称呼为丽吧。丽也不能称得上美女，略胖，当然比我瘦，但笑起来甜甜的。
我们后面坐了一个全班最搓的男生，还有一个全班最顽皮的男生。
可可高中还是跟我一个班，可以说有缘。
我的前面是个戴眼镜的看上去很斯文的女生，可其实相反，她的个性活跃的不得了，叫敏，她跟宇是初中同学，据她说她初中时常跟宇吵嘴。
相比初中时候男同学的淡漠，高中时代男生的反应就激烈的多了。他们会光明正大的指着我，嘲笑我，很享受似的排出班级最难看前3名，我很光荣的虽没得桂冠但也进入榜单了。我的试卷，本子，从来就是飞过来的，不是传过来的，要是谁不小心碰到下，就会去洗洗手什么的。最可恶的是，他们竟然把我和那后面的搓男配成一对，说什么很配的。
总之，这是噩梦的开始，心，真的很痛，我不需要什么爱情，难道，一点点自尊都不可以么？
七、梦碎——安排好的邂逅
虽然跟宇在同一个班，也常常抬头不见低头见的，可每次，都只是无穷无尽的忽略。其实，我的要求很低，只希望能讲上一两句话。
这样下去是不行的，所以我得想办法，我在想是不是因为全班男同学都在嘲笑我，他才随大流不理睬我的啊。现在想起来，那时候我真是单纯的可以。所以我经常刻意安排跟他的单独相遇，比如在无人路过时候的走廊的突然相遇，比如在值日打扫卫生的无人角落，比如在上下学的路上，可是，每次的答案还是一样的。
终于有一次，我鼓足了勇气，早上在停自行车的车棚刻意等他，当车棚里只有我们2个人的时候，我用尽浑身的力气，颤抖的说，你也这么早来啊？可是，无尽的沉默，他像没听见一样，走了，只留下茫然的我。
也许，我真该照照镜子。
从此，我就没跟他说过一句话。因为，我的勇气已经耗尽了。
2009/01/25
如果一个男人在他什么都有的情况下喜欢你，才是真的喜欢你
爸爸曾经对我说过
没有任何一个男人可以让你依赖一辈子。
妈妈曾经对我说过
如果一个男人在他什么都有的情况下喜欢你，才是真的喜欢你，变数不大，如果他一开始一无所有，后来有了很多，那一般会抛弃你。
妈妈还说
以后不要找比我家差的，不行，如果家里比我们好太多，绝对不行。
阿姨说
男人要顾家，如果不顾家，再好再风光，也是别人的老公，不是你的。
还有别人对我说的那句话，女人失去自己的那一天，就是男人离开你的那一天。
有些东西是骨子里的，留着自己慢慢体会了。 -----------------以上摘自某女同學的BLOG 沒錢的男人靠邊站
Subscribe to:
Comments (Atom)