Firewalling and packets accounting 11.. TTaasskkss For security reasons, most private networks are not connected directly to the Internet. The machine which acts as the router between the public and private networks is called the firewall. The firewall is like a car component which protects the passengers from a fire in the engine. The analogy of the word "firewall" for IP networks comes from the fact that the _I_n_t_e_r_n_e_t is a "hot" place -- sometimes too hot. Limiting the impact of the _I_n_t_e_r_n_e_t on your private network is a good idea. 22.. PPrriinncciipplleess 22..11.. PPaacckkeett ffiilltteerriinngg Packet filtering allows your computer to drop or accept IP packets based on the following criteria: +o Origin. +o Destination. +o Interface on which it was received. Origin and Destination are qualified by: +o IP number. +o Port number. +o Protocol. 22..22.. BBii--ddiirreeccttiioonnaall rruulleess The rules you are entering are bi-directional. In one screen, you qualify packets flowing from the origin to the destination and the reverse. This is why you are allowed to specify the interface twice. 22..33.. IInnppuuttiinngg rruulleess You can control the packets which are accepted by your computer. Inputing rules allow you to discard some packets at reception time. 22..44.. FFoorrwwaarrddiinngg rruulleess You can control packets going through your computer. One special case of forwarding rules are the masquerading rules. These are handled in the same user interface (a simple checkbox). Masquerading is generally used to hide computers on Intranets and provides them almost full connectivity to the Internet. All connections to the Internet seems to come from the firewall itself. 22..55.. OOuuttppuuttiinngg rruulleess You can control packets that are about to leave your computer. You can discard packets at delivery time. Most firewalls can be implemented using inputing rules. One special case of forwarding rules are the masquerading rules. These are handled in the same user interface (a simple checkbox). 22..66.. AAccttiivvaattiinngg rruulleess gglloobbaallllyy oorr sseelleeccttiivveellyy You can permanently deactivate a rule or all rules without erasing them. This is handy for testing firewalling capabilities and for establishing "switchable" policies. Each rule has a checkbox for activation. One screen is provided to activate/deactivate all blocking and forwarding rules at once. 22..77.. WWhheenn eevveerryytthhiinngg ggooeess wwrroonngg!! Firewalling in _L_i_n_u_x may be deadly. An improper configuration can bring the network to its knees. One command that may save your day is netconf --resetfw This command deactivates all firewalling rules. It does not affect the configuration -- it affects only the working set. netconf --update will reactivate the rules. You may need to use those two commands to check out if a network malfunction is caused by your firewalling rules or not. 33.. TThhee llooggiicc ooff ffiirreewwaalllliinngg wwiitthh lliinnuuxxccoonnff The firewalling in _L_i_n_u_x is highly flexible and can be very complicated. _L_i_n_u_x_c_o_n_f is proposing a simple logic that simplifies the composition of the firewalling rule. While this logic helps create and maintain a basic firewall, some configurations may not be created with linuxconf. Here is the logic: 33..11.. PPoossiittiivvee llooggiicc When you activate one of the three firewalling systems (input, forward, output), _L_i_n_u_x_c_o_n_f will set the default policy to _d_e_n_y. All rules you enter are indeed holes or openings in the firewall. If you enter no rules, then your machine will be pretty isolated, answering to nothing. 44.. TThhee vvaarriioouuss ffiieellddss Here is a run down of the various fields used to define a firewall rule. All inputing,forwarding and outputing rules share the same dialog with little differences. Unless specified, a field applies to all of them. In many fields, you are allowed to use negation. You do this by prefixing a value with the quotation mark character. You can use this for the following fields: +o Protocol +o Host(s) or network(s) +o Other ports +o Input or output interfaces 44..11.. TToopp sseeccttiioonn 44..11..11.. TThhiiss rruullee iiss aaccttiivvee This is a check-box to turn on and off a rule. Use this to comment out a rule temporarily. 44..11..22.. CCoommmmeenntt Put any useful comment to explain the purpose of a rule 44..11..33.. PPrroottooccooll Select the IP protocol. A help list present the available one. In general a rules will apply to protocol icmp, udp or tcp. The special entry "all" tells the rules is protocol neutral. 44..11..44.. RRuullee''ss ppoolliiccyy A paquet may be either accepted, denied or rejected. In general, paquet are accepted since the default policy denies everything else. Yet, you may want to stop something specific before enabling something more general. The "deny" policy means the paquet will simply be ignored. From an attacker point of view, it seems like the destination does not exist (no answer). A "reject" policy means a special paquet will be returned to the sender, telling him the service is not available. 44..22.. FFrroomm You qualify incoming paquets here. 44..22..11.. HHoosstt((ss)) oorr NNeettwwoorrkk((ss)) You enter a host or network. You can enter several, separated by commas. An entry may be: +o An IP number +o A name +o A logical name. Logical names refers to other linuxconf modules. A logical name is defined by a module key, a slash and a module specific name. For example, to reference the IP number associated with a user you enter "userfw/userid". This tells the firewall module to communicate with the userfirewall module and convert the userid entry into one or more IP numbers. 44..22..22.. nneettmmaasskk You enter the network mask if need. Linuxconf will compute the default network mask for a host or an IP network. If you provide several entries in "hosts or networks", they will share this netmask though. 44..22..33.. ppoorrtt rraannggee This defines a port range for TCP and UDP rules. A range is defined using a semi-colon to slit the start and the end of the range. The following example specifies the ports used by clients to reach a server. 1024:65535 44..22..44.. OOtthheerr ppoorrttss You enumerate the ports either by name or by number. You specify several delimited with spaces. 44..22..55.. AAcccceepptt TTCCPP SSYYNN This is a check-box to control the first paquet of a TCP session (the SYN paquet). In general, you accept SYN paquet coming from the client side and reject them from the server side. 44..22..66.. IInnppuutt iinntteerrffaaccee oorr OOuuppuutt iinntteerrffaaccee In inputing rules, you specify the network devices receiving the paquet. In forwarding and outputing rules, you specify the output interface. You can enter "any" to specify that you do not care (in general you do). Specifying the interface allows you to make sure accepted paquet really come from where you thing they should. Intruders may forge paquets to hit some internal servers this way. You can also enter logical interface by using the same syntax explained for logical host (module-id/key). This is useful for PPP connection where the interface is not known until connect time. For example dialout/my-isp specifies the interface allocated when the PPP configuration "my-isp" is active. A help list presents the logical devices available. 44..33.. TToo This is the same set of field as the "From" section. 44..44.. FFeeaattuurreess 44..44..11.. TThhiiss rruullee iiss bbii--ddiirreeccttiioonnaall Normally, linuxconf will generate the rules in both directions ("from -> to" and "to -> from"). You can restrict it to "from -> to" using this check-box. You do this either because you have special routing setup where you know paquet are flowing from one source and leaving from another. You are also using it for "reject" rules where only the incoming paquet is important. 44..44..22.. OOrrddeerriinngg ffaaccttoorr Linuxconf orders rules based on various criterion, such as the netmask interfaces and rule policy. Deny and Reject rules goes first. You can control the ordering by entering a factor. By default all rules have 50. Lower factor orders the rule before, higher, after. Linuxconf will immediatly sorts the rules in the dialog. Some are using this just to order the presentation. 44..44..33.. LLooggggiinn iiss eennaabbllee Turning on this check-box will write some log information in your system log (/var/log/messages on most distributions) whenever this rule match. 44..44..33..11.. AA ttrriicckk A nice trick to debug a firewall, when something fails to go through. Create a rule with a high ordering factor. It will go at the end. Accept everything from everywhere to anywhere (0.0.0.0 -> 0.0.0.0) on all protocol. Enable logging. Then test you firewall. Any paquet showing in the log probably correspond to a missing rule. 44..44..44.. CChhaaiinn ddiissppaattcchh ((ffrroomm -->> ttoo)) All the rule you enter ends up in the kernel as a list of rules. The kernel has to walk each rules one by one until it finds one that match or it reaches the end. For complex firewall, this can slow down the processing significantly. This is especially true with the userfirewall module, where firewalling rules are expressed per users and groups. One can easily generates thousands of firewall rules, almost killing performance. Linux firewall supports the concept of "chains". By default you have one chains for input, forward and output rules. It is possible to dispatch to sub-chains based on common criterion. For example, one may create a chain for all traffic targetted to a specific server. The main input chain would only contains dispatch rules pointing to the various "servers" chains. Using this chain mechanism effectivly may speed up your firewall to no end. But managing those chains may be tedious and error prone. The purpose of this field is to automate the creation of dispatch rules. You do this by entering a distribution pattern using the following keywords. You specify the keywords separated by commas. +o iface Interface (eth0, ppp0, ...) +o proto IP protocol (udp, tcp, ...) +o fromport TCP or UDP port. +o toport +o from +o from/netmask +o to +o to/netmask For example, if you specify the dispatch rule "iface,proto,to" you will end up with one dispatch rule working on the interface. This creates a new chains containing all rule with the same input (or output) interface. the the new chain will contain dispatch rules base on the protocol. The newly created chains will contains all the rules sharing the same protocol. Those chains will dispatch to one chain per destination (to). 44..44..44..11.. BBeewwaarree The "chain dispatch" mechanism is indeed very powerful. With little effort, a firewall with several thousands kernel rules will rock (we have tested one with 130,000 routing 300megabit/second). But there is a catch: If you use this, you have to use it in a consistant way in all rules. If you dispatch differently for different rules, your logic may be trapped by the first rule and fail. Once a path is taken (a sub-chain is selected), the kernel won't backtrack to try another path if no rule match. It will simply fall back to the default rule. So if you have a rule dispatching on the protocol first and the next dispatch on the source (from) then the first rule will probably match the paquet from the second rule. 44..44..55.. CChhaaiinn ddiissppaattcchh ((ttoo -->> ffrroomm)) This is the same thing, for paquet flowing in the other direction. 44..55.. RReeddiirreeccttiioonn 44..55..11.. RReeddiirreeccttiioonn ttoo llooccaall hhoosstt//ppoorrtt 44..55..22.. RReeddiirreecctt ttoo ppoorrtt 44..55..33.. RReeddiirreecctt ttoo hhoosstt 55.. AA pprree--ccooookkeedd ffiirreewwaallll ssoolluuttiioonn Here is an example for a simple network. Mostly, you have eth0 pointing to the local network. Nothing must be reachable from the outside on this network. eth1 points to a router on the Internet. 55..11.. IInnppuuttiinngg rruulleess:: aacccceeppttiinngg aallll iiccmmpp ppaacckkeettss Protocol icmp -----------From--------------- Host or Network 0.0.0.0 Netmask Port range Other ports Interface eth1 -----------To----------------- Host or Network eth1 Netmask Port range Other ports Interface Any 55..22.. IInnppuuttiinngg rruulleess:: aacccceeppttiinngg oonnllyy DDNNSS ppaacckkeett Ultimately only port Protocol udp -----------From--------------- Host or Network 0.0.0.0 Netmask 0.0.0.0 Port range Other ports Interface eth1 -----------To----------------- Host or Network eth1 Netmask Port range Other ports Interface Any 66.. PPoorrtt rreeddiirreeccttiioonn You can do various things with port redirection. You can either intercept traffic going out and feed it to a proxy. This "transparent" proxy may be used to hide the internal network, do some caching or some filtering of the protocol (A transparent pop-3 proxy could flag or delete email with special attachement for one). Port redirection may also be used to provide access to an internal server (behind a firewall) from outside. 66..11.. TTrraannssppaarreenntt pprrooxxyy In this case, you select the check-box "redirect to local port/host". Then you enter the port on which the proxy server is listening. The firewall rule generally defines a target port (in the "to" section) and looks like (to enable squid as a transparent proxy for example): Protocol tcp -----------From--------------- Host or Network 192.168.1.0 Netmask 255.255.255.0 Port range Other ports Interface eth0 -----------To----------------- Host or Network 0.0.0.0 Netmask Port range Other ports 80 Interface Any ---------features------------- [x] redirect to local port/host redirect to port 3128 66..22.. AAcccceessss ttoo aa llooccaall sseerrvveerr In this case, request come from anywhere (from the internet) and goes to one IP on the firewall (potentially an IP alias). We may want to "publish" a single port on the internal server, or many (even a port range). This is done by leaving the "Redirect to port" field empty. The firewalling rule specify the effective port range accepted. The following example is making an internal web server available on the internet. Protocol tcp -----------From--------------- Host or Network 0.0.0.0 Netmask Port range Other ports Interface eth0 -----------To----------------- Host or Network public_IP Netmask Port range Other ports 80 Interface Any ---------features------------- [x] redirect to local port/host redirect to port 80 redirect to host 192.168.1.2 The following example is publishing several services from the internal server. the trick is to leave "redirect to port" empty and specify which ports are accepted in the firewall rule. In the following example, ssh, www and pop-3 are handled. Protocol tcp -----------From--------------- Host or Network 0.0.0.0 Netmask Port range Other ports Interface eth0 -----------To----------------- Host or Network public_IP Netmask Port range Other ports 22 80 pop-3 Interface Any ---------features------------- [x] redirect to local port/host redirect to port redirect to host 192.168.1.2