[ Pobierz całość w formacie PDF ]
.Since both of these protocols are complex protocols, they needseparate code (ie, the modules) that knows how to figure out which connections arerelated to the actual main connection.Active FTP uses port 21 as a standard port.When the other end wants to open up a data transfer (ie, download a file) it tellsthe other end that it wants this and that file.The FTP server then tells the clientwhich port to connect to.Since all of this happens within the data part of the connec-tion, the state engine would not know anything about this normally.However, theip_conntrack_ftp module adds the possibility for the state engine to look inside theactual data part of the FTP sessions and figure out that "this port connection is relatedto this FTP session".DCC connections in IRC works the same way, ports used for filetransfers are negotiated within the actual IRC connection and hence it needs a kerneladd-on to know how this works.Note that you also need to load the ip_nat_irc and ip_nat_ftp if you want NetworkAdress Translation to work properly on any of these protocols.They are used thesame way as the conntrack modules, but it will make it possible for the computer todo NAT on these two protocols.The main need for these two modules, are that boththe protocols send IP adresses within the data part of the connection, which are used35 Chapter 5.rc.firewall filefor the other end of the connection to know where to connect.For example, when youwant to establish a DCC connection over IRC, the client sends a DCC request whichcontains both an IP adress and a port to connect to.If the IRC client sits on a LAN,and is NAT ed by a firewall, it will send the IP adress it uses on the LAN.The LANIP will not be recognised by the other host, or the packets being sent from the otherend will just not be properly routed and hence the packets will be lost somewhere inbetween and the DCC request will time out.What the ip_nat_irc module will do, isto actually NAT these IP adresses and ports within the IRC packets, as needed.Initiating the kernel for IP forwarding and othersAfter this we start the IP forwarding by echoing a 1 to/proc/sys/net/ipv4/ip_forwardin this fashion :echo "1" > /proc/sys/net/ipv4/ip_forwardIn case you need dynamicIPsupport, for example if you use SLIP,PPPor DHCPyoumay enable the next option,ip_dynaddrby doing the following :echo "1" > /proc/sys/net/ipv4/ip_dynaddretc, if there s any other options you might need to turn on you should follow thatstyle, there s other documentations on how to do these things and this isn t eitherwhat this document is supposed to help you with.Actually starting the masqueradingSo, our first mission would be to get the MASQUERADEing up, correct? Well, at leastto me.First of all we add a rule to the nat table, in the POSTROUTING chain that willmasquerade all packets going out on our interface connected to the Internet.For methis would be eth0, -t tells us which table to use, in this case nat, -A tells us thatwe want to Add a new rule to an existing chain named POSTROUTING and -o eth0tells us to match all outgoing packets on eth0 and finally we target the packet forMASQUERADE ing.So all packets that match this rule will be masqueraded to look as itcame from your Internet interface.Simple, isn t it?=)The next step we take is to ACCEPT all packets traversing the FORWARD chain in thedefault table filter that come from the input interface eth1 which is my interfaceconnecting to the internal network.All packets that are being forwarded on our boxtraverse theFORWARDchain in thefiltertable.The next thing we do is to ACCEPT all packets from anywhere that are ESTABLISHEDand/or RELATED to some connection.In other words, we first send a packet fromour local box behind eth1, and since it comes from eth1 weACCEPTit, then when theInternet box replies, it gets caught by this rule since the connection has seen packetsin both directions.The last thing we do is to log all traffic that gets dropped over the border, and hits thedefault policy.In some cases these might be packets that should have gotten throughbut didn t, in other cases it might be packets that definitely shouldn t get through andyou want to be notified about this.We allow this rule to be matched a maximum of 3times per minute with a burst limit of 3.This means we get maximally 3 log entriesper minute from this specific line, and the burst is also set to 3 so if we get 3 logentries in 2 seconds, it ll have to wait for another 1 minute for the next log entry.Thisis good if someone starts to flood you with crap stuff that otherwise would generatemany megabytes of logs.We also set a prefix to the log with the log-prefix and setthe log level with the log-level.Log level tells the syslogd, or logging facility whatkind of importance this log entry has.Displacement of rules to different chainsI ve displaced all the different chains in the fashion I ve done to save as much CPUas possible but at the same time put the main weight on security.Instead of lettinga TCP packet traverse ICMP, UDP and TCP rules, I just simply match all TCP packetsand then let the TCP packet traverse another chain.This way we don t get too muchoverhead out of it all.The following picture will try and explain the basics of how an36 Chapter 5.rc.firewall fileincoming packet traverses netfilter.This picture was pretty much stolen straight offfrom the packet-filtering-HOWTO2.First a routing decision is made, if it s destined for your host, it s sent to INPUT, ifit s destined for some box on the localnet it s sent to FORWARD.Then they traversewhichever of those chains.When and if your local box replies to the packets destinedfor the server, they will traverse theOUTPUTchain.Here is a picture of how they would traverse the INPUT and FORWARD and OUTPUTchains separately since the picture would be way to large if we would fit them alltogether in one :When a packet hits theINPUTchain, it will first be checked to see if it s anICMPpacket,if it is, it s sent toicmp_packetsand checked if it s allowed or not.If it is, we just dropout of theINPUTchain and tell it toACCEPTthe packet.If it is not, it will reach the endof the icmp_packets chain get back to INPUT chain and reach the end with somemore checks to see if it s from localhost or localnet, if it is it will beACCEPT ed.Finallywe check to see if the packet somehow belongs to any other connection by checkingif it is part of anESTABLISHEDorRELATEDconnection, in this case we shouldACCEPTthem.If it doesn t match anything, it will finally hit the chain policy which is set toDROPeverything that reaches it.If the packet would instead be a TCP packet, it would not match the rule as an ICMPpacket and hence be sent to the next rule which checks for TCP packets.Since it is aTCP packet it will match and be sent to the tcp_packets chain.Here we will checkif it s destined for one of the ports we d like to allow or not, if it is, we send it on tothe allowed chain to do some final checks on it.If it fails at some stage in this check,it ll be passed down to theINPUTchain and traverse the same way as theICMPpacketdid
[ Pobierz całość w formacie PDF ]