|
s i s t e m a o p e r a c i o n a l m a g n u x l i n u x | ~/ · documentação · suporte · sobre |
Next
Previous
Contents
6. Other IP Masquerade Issues and Software Support
6.1 Problems with IP MasqueradeSome TCP/IP application protocols will not currently work with Linux IP Masquerading because they either assume things about port numbers or encode TCP/IP addresses and/or port numbers in their data stream. These latter protocols need specific proxies or IP MASQ modules built into the masquerading code to make them work.
6.2 Incoming servicesBy default, Linux IP Masquerading cannot handle incoming services at all but there are a few ways of allowing them. If you do not require high levels of security then you can simply forward or redirect IP ports. There are various ways of doing this though the most stable method is to use IPPORTFW. For more information, please see the Forwarders section. If you wish to have some level of authorization on incoming connections then you will need to either configure TCP-wrappers or Xinetd to then allow only specific IP addresses through. The TIS Firewall Toolkit is a good place to look for tools and information. More details on incoming security can be found in the TrinityOS document and at IP Masquerade Resource.
6.3 Supported Client Software and Other Setup Notes
** The Linux Masquerade Application list has a lot of good information regarding applications that work through Linux IP masquerading. This site was recently taken over by Steve Grevemeyer who implimented it with a full database backend. Its a great resource! Generally, any application that uses standard TCP and UDP should work. If you have any suggestion, hints, etc., please see the IP Masquerade Resource for more details.
Network Clients that -Work- with IP MasqueradeGeneral Clients:
Multimedia and Communication Clients:
Games - See the LooseUDP section for more details on the LooseUDP patch
Other Clients:
Clients that do not have full support in IP MASQ:
6.4 Stronger IP Firewall (IPFWADM) Rulesets
This section provides a more in-depth guide on using the 2.0.x firewall tool, IPFWADM. See below for IPCHAINS rulesets This example is for a firewall/masquerade system behind a PPP link with a static PPP address (dynamic PPP instructions are included but disabled). The trusted interface is 192.168.0.1 and the PPP interface IP address has been changed to protect the guilty :). I have listed each incoming and outgoing interface individually to catch IP spoofing as well as stuffed routing and/or masquerading. Anything not explicitly allowed is FORBIDDEN (well.. rejected actually). If your IP MASQ box breaks after implementing this rc.firewall script, be sure that you edited it for your configuration and check your /var/log/messages or /var/adm/messages SYSLOG file for any firewall errors. For more comprehensive examples of a strong IP Masqueraded IPFWADM rulesets for PPP, Cablemodem users, etc., please see TrinityOS - Section 10 and GreatCircle's Firewall WWW page NOTE: If you get a dynamically assigned TCP/IP address from your ISP (PPP, ADSL, Cablemodems, etc.), you CANNOT load this strong ruleset upon boot. You will either need to reload this firewall ruleset EVERY TIME you get a new IP address or make your /etc/rc.d/rc.firewall ruleset more intelligent. To do this for PPP users, carefully read and un-comment out the properly lines in the "Dynamic PPP IP fetch" section below. You can also find more details in the TrinityOS - Section 10 doc for more details on Strong rulesets and Dynamic IP addresses. Please also be aware that there are several GUI Firewall creation tools available as well. Please see the FAQ section for full details. Lastly, if you are using a STATIC PPP IP address, change the "ppp_ip="your.static.PPP.address"" line to reflect your address. ----------------------------------------------------------------
#!/bin/sh
#
# /etc/rc.d/rc.firewall: An example of a semi-STRONG IPFWADM firewall ruleset
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# testing, wait a bit then clear all firewall rules.
# uncomment following lines if you want the firewall to automatically
# disable after 10 minutes.
# (sleep 600; \
# ipfwadm -I -f; \
# ipfwadm -I -p accept; \
# ipfwadm -O -f; \
# ipfwadm -O -p accept; \
# ipfwadm -F -f; \
# ipfwadm -F -p accept; \
# ) &
# Load all required IP MASQ modules
#
# NOTE: Only load the IP MASQ modules you need. All current IP MASQ modules
# are shown below but are commented from loading.
# Needed to initially load modules
#
/sbin/depmod -a
# Supports the proper masquerading of FTP file transfers using the PORT method
#
/sbin/modprobe ip_masq_ftp
# Supports the masquerading of RealAudio over UDP. Without this module,
# RealAudio WILL function but in TCP mode. This can cause a reduction
# in sound quality
#
#/sbin/modprobe ip_masq_raudio
# Supports the masquerading of IRC DCC file transfers
#
#/sbin/modprobe ip_masq_irc
# Supports the masquerading of Quake and QuakeWorld by default. This modules is
# for for multiple users behind the Linux MASQ server. If you are going to
# play Quake I, II, and III, use the second example.
#
# NOTE: If you get ERRORs loading the QUAKE module, you are running an old
# ----- kernel that has bugs in it. Please upgrade to the newest kernel.
#
#Quake I / QuakeWorld (ports 26000 and 27000)
#/sbin/modprobe ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#/sbin/modprobe ip_masq_quake 26000,27000,27910,27960
# Supports the masquerading of the CuSeeme video conferencing software
#
#/sbin/modprobe ip_masq_cuseeme
#Supports the masquerading of the VDO-live video conferencing software
#
#/sbin/modprobe ip_masq_vdolive
#CRITICAL: Enable IP forwarding since it is disabled by default since
#
# Redhat Users: you may try changing the options in /etc/sysconfig/network from:
#
# FORWARD_IPV4=false
# to
# FORWARD_IPV4=true
#
echo "1" > /proc/sys/net/ipv4/ip_forward
#CRITICAL: Enable automatic IP defragmenting since it is disabled by default
# in 2.2.x kernels
#
# This used to be a compile-time option but the behavior was changed
# in 2.2.12
#
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
# Dynamic IP users:
#
# If you get your IP address dynamically from SLIP, PPP, or DHCP, enable this
# following option. This enables dynamic-ip address hacking in IP MASQ,
# making the life with Diald and similar programs much easier.
#
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# Specify your Static IP address here.
#
# If you have a DYNAMIC IP address, you need to make this ruleset understand
# your IP address everytime you get a new IP. To do this, enable the
# following one-line script. (Please note that the different single and
# double quote characters MATTER).
#
#
# DHCP users:
# -----------
# If you get your TCP/IP address via DHCP, **you will need ** to enable the
# #ed out command below underneath the PPP section AND replace the word
# "ppp0" with the name of your EXTERNAL Internet connection (eth0, eth1,
# etc). It should be also noted that the DHCP server can change IP
# addresses on you. To fix this, users should configure their DHCP client
# to re-run the firewall ruleset everytime the DHCP lease is renewed.
#
# NOTE #1: Some DHCP clients like the older version of "pump" (the newer
# versions have been fixed) did NOT have the ability to run
# scripts after a lease-renew. Because of this, you need to
# replace it with something like "dhcpcd" or "dhclient".
#
# NOTE #2: The syntax for "dhcpcd" has changed in recent versions.
#
# Older versions used syntax like:
# dhcpcd -c /etc/rc.d/rc.firewall eth0
#
# Newer versions use syntax like:
# dhcpcd eth0 /etc/rc.d/rc.firewall
#
# NOTE #3: For Pump users, put the following line in /etc/pump.conf:
#
# script /etc/rc.d/rc.firewall
#
# PPP users:
# ----------
# If you aren't already aware, the /etc/ppp/ip-up script is always run when
# a PPP connection comes up. Because of this, we can make the ruleset go
# and get the new PPP IP address and update the strong firewall ruleset.
#
# If the /etc/ppp/ip-up file already exists, you should edit it and add a line
# containing "/etc/rc.d/rc.firewall" near the end of the file.
#
# If you don't already have a /etc/ppp/ip-up sccript, you need to create the
# following link to run the /etc/rc.d/rc.firewall script.
#
# ln -s /etc/rc.d/rc.firewall /etc/ppp/ip-up
#
# * You then want to enable the #ed out shell command below *
#
#
# PPP and DHCP Users:
# -------------------
# Remove the # on the line below and place a # in front of the line after that.
#
#ppp_ip="`/sbin/ifconfig ppp0 | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`"
#
ppp_ip="your.static.PPP.address"
# MASQ timeouts
#
# 2 hrs timeout for TCP session timeouts
# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received
# 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a 30sec firewall timeout in ICQ itself)
#
/sbin/ipfwadm -M -s 7200 10 60
#############################################################################
# Incoming, flush and set default policy of reject. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p reject
# local interface, local machines, going anywhere is valid
#
/sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0
# remote interface, claiming to be local machines, IP spoofing, get lost
#
/sbin/ipfwadm -I -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o
# remote interface, any source, going to permanent PPP address is valid
#
/sbin/ipfwadm -I -a accept -V $ppp_ip -S 0.0.0.0/0 -D $ppp_ip/32
# loopback interface is valid.
#
/sbin/ipfwadm -I -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# catch all rule, all other incoming is denied and logged. pity there is no
# log option on the policy but this does the job instead.
#
/sbin/ipfwadm -I -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#############################################################################
# Outgoing, flush and set default policy of reject. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
/sbin/ipfwadm -O -f
/sbin/ipfwadm -O -p reject
# local interface, any source going to local net is valid
#
/sbin/ipfwadm -O -a accept -V 192.168.0.1 -S 0.0.0.0/0 -D 192.168.0.0/24
# outgoing to local net on remote interface, stuffed routing, deny
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o
# outgoing from local net on remote interface, stuffed masquerading, deny
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o
# outgoing from local net on remote interface, stuffed masquerading, deny
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o
# anything else outgoing on remote interface is valid
#
/sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0
# loopback interface is valid.
#
/sbin/ipfwadm -O -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# catch all rule, all other outgoing is denied and logged. pity there is no
# log option on the policy but this does the job instead.
#
/sbin/ipfwadm -O -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#############################################################################
# Forwarding, flush and set default policy of deny. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p deny
# Masquerade from local net on local interface to anywhere.
#
/sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0
#
# catch all rule, all other forwarding is denied and logged. pity there is no
# log option on the policy but this does the job instead.
#
/sbin/ipfwadm -F -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#End of file.
With IPFWADM, you can block traffic to a particular site using the -I, -O or -F rules. Remember that the set of rules are scanned top to bottom and "-a" tells IPFWADM to "append" this new rule to the existing set of rules. So with this in mind, any specific restrictions need to come before global rules. For example: Using -I (input ) rules: Probably the fastest and most efficient method to block traffic but it only stops the MASQed machines and NOT the the firewall machine itself. Of course you might want to allow that combination. Anyway, to block 204.50.10.13:
In the /etc/rc.d/rc.firewall ruleset: ... start of -I rules ... # reject and log local interface, local machines going to 204.50.10.13 # /sbin/ipfwadm -I -a reject -V 192.168.0.1 -S 192.168.0.0/24 -D 204.50.10.13/32 -o # local interface, local machines, going anywhere is valid # /sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0 ... end of -I rules ...
Using -O (output) rules: This is the slower method to block traffic because the packets go through masquerading first before they are dropped. Yet, this rule even stops the firewall machine from accessing the forbidden site.
... start of -O rules ... # reject and log outgoing to 204.50.10.13 # /sbin/ipfwadm -O -a reject -V $ppp_ip -S $ppp_ip/32 -D 204.50.10.13/32 -o # anything else outgoing on remote interface is valid # /sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0 ... end of -O rules ... Using -F (forward) rules: Probably slower than -I (input) rules for blocking traffic, this still only stops masqueraded machines (e.g. internal machines). The firewall machine can still reach forbidden site(s).
... start of -F rules ... # Reject and log from local net on PPP interface to 204.50.10.13. # /sbin/ipfwadm -F -a reject -W ppp0 -S 192.168.0.0/24 -D 204.50.10.13/32 -o # Masquerade from local net on local interface to anywhere. # /sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0 ... end of -F rules ... There is no need for a special rule to allow machines on the 192.168.0.0/24 network to go to 204.50.11.0. Why? It is already covered by the global MASQ rule. NOTE: There is more than one way of coding the interfaces in the above rules. For example instead of "-V 192.168.255.1" you can code "-W eth0", instead of "-V $ppp_ip" , you can use "-W ppp0". The "-V" method was phased out with the imgration to IPCHAINS but for IPFWADM users, its personal choice and documentation more than anything.
6.5 Stronger IP Firewall (IPCHAINS) rulesets
This section provides a more in-depth guide on using the 2.2.x firewall tool, IPCHAINS. See above for IPFWADM rulesets. This example is for a firewall/masquerade system behind a PPP link with a static PPP address (dynamic PPP instructions are included but disabled). The trusted interface is 192.168.0.1 and the PPP interface IP address has been changed to protect the guilty :). I have listed each incoming and outgoing interface individually to catch IP spoofing as well as stuffed routing and/or masquerading. A nything not explicitly allowed is FORBIDDEN (well.. rejected actually). If your IP MASQ box breaks after implementing this rc.firewall script, be sure that you edited it for your configuration and check your /var/log/messages or /var/adm/messages SYSLOG file for any firewall errors. For more comprehensive examples of a strong IP Masqueraded IPFWADM rulesets for PPP, Cablemodem users, etc., please see TrinityOS - Section 10 and GreatCircle's Firewall WWW page NOTE #1: Linux 2.2.x kernels less than 2.2.16 have a TCP root exploit vunerability and versions less than 2.2.11 have a IPCHAINS fragmentation bug. Because of this, people running strong IPCHAINS rulesets are open to attack. Please upgrade your kernel to a fixed version. NOTE #2: If you get a dynamically assigned TCP/IP address from your ISP (PPP, ADSL, Cablemodems, etc.), you CANNOT load this strong ruleset upon boot. You will either need to reload this firewall ruleset EVERY TIME you get a new IP address or make your /etc/rc.d/rc.firewall ruleset more intelligent. To do this for PPP users, carefully read and un-comment out the properly lines in the "Dynamic PPP IP fetch" section below. You can also find more details in the TrinityOS - Section 10 doc for more details on Strong rulesets and Dynamic IP addresses. Please also be aware that there are several GUI Firewall creation tools available as well. Please see the FAQ section for full details. Lastly, if you are using a STATIC PPP IP address, change the "ppp_ip="your.static.PPP.address"" line to reflect your address. ----------------------------------------------------------------
#!/bin/sh
#
# /etc/rc.d/rc.firewall: An example of a Semi-Strong IPCHAINS firewall ruleset.
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# Load all required IP MASQ modules
#
# NOTE: Only load the IP MASQ modules you need. All current IP MASQ modules
# are shown below but are commented from loading.
# Needed to initially load modules
#
/sbin/depmod -a
# Supports the proper masquerading of FTP file transfers using the PORT method
#
/sbin/modprobe ip_masq_ftp
# Supports the masquerading of RealAudio over UDP. Without this module,
# RealAudio WILL function but in TCP mode. This can cause a reduction
# in sound quality
#
/sbin/modprobe ip_masq_raudio
# Supports the masquerading of IRC DCC file transfers
#
#/sbin/modprobe ip_masq_irc
# Supports the masquerading of Quake and QuakeWorld by default. This modules is
# for for multiple users behind the Linux MASQ server. If you are going to
# play Quake I, II, and III, use the second example.
#
# NOTE: If you get ERRORs loading the QUAKE module, you are running an old
# ----- kernel that has bugs in it. Please upgrade to the newest kernel.
#
#Quake I / QuakeWorld (ports 26000 and 27000)
#/sbin/modprobe ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#/sbin/modprobe ip_masq_quake 26000,27000,27910,27960
# Supports the masquerading of the CuSeeme video conferencing software
#
#/sbin/modprobe ip_masq_cuseeme
#Supports the masquerading of the VDO-live video conferencing software
#
#/sbin/modprobe ip_masq_vdolive
#CRITICAL: Enable IP forwarding since it is disabled by default since
#
# Redhat Users: you may try changing the options in
# /etc/sysconfig/network from:
#
# FORWARD_IPV4=false
# to
# FORWARD_IPV4=true
#
echo "1" > /proc/sys/net/ipv4/ip_forward
#CRITICAL: Enable automatic IP defragmenting since it is disabled by default
# in 2.2.x kernels
#
# This used to be a compile-time option but the behavior was changed
# in 2.2.12. It should also be noted that some distributions have
# removed this option from the /proc table. If this entry isn't
# present in your /proc, don't worry about it.
#
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
# Dynamic IP users:
#
# If you get your IP address dynamically from SLIP, PPP, or DHCP, enable this # following option. This enables dynamic-ip address hacking in IP MASQ,
# making the life with Diald and similar programs much easier.
#
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# Enable the LooseUDP patch which some Internet-based games require
#
# If you are trying to get an Internet game to work through your IP MASQ box,
# and you have set it up to the best of your ability without it working, try
# enabling this option (delete the "#" character). This option is disabled
# by default due to possible internal machine UDP port scanning
# vunerabilities.
#
#echo "1" > /proc/sys/net/ipv4/ip_masq_udp_dloose
# Specify your Static IP address here.
#
# If you have a DYNAMIC IP address, you need to make this ruleset understand
# your IP address everytime you get a new IP. To do this, enable the
# following one-line script. (Please note that the different single and
# double quote characters MATTER).
#
#
# DHCP users:
# -----------
# If you get your TCP/IP address via DHCP, **you will need ** to enable the
# #ed out command below underneath the PPP section AND replace the word
# "ppp0" with the name of your EXTERNAL Internet connection (eth0, eth1, etc)
# on the lines for "ppp-ip" and "extip". It should be also noted that the
# DHCP server can change IP addresses on you. To fix this, users should
# configure their DHCP client to re-run the firewall ruleset everytime the
# DHCP lease is renewed.
#
# NOTE #1: Some DHCP clients like the original "pump" (the newer
# versions have been fixed) did NOT have the ability to run
# scripts after a lease-renew. Because of this, you need to
# replace it with something like "dhcpcd" or "dhclient".
#
# NOTE #2: The syntax for "dhcpcd" has changed in recent versions.
#
# Older versions used syntax like:
# dhcpcd -c /etc/rc.d/rc.firewall eth0
#
# Newer versions use syntax like:
# dhcpcd eth0 /etc/rc.d/rc.firewall
#
# NOTE #3: For Pump users, put the following line in /etc/pump.conf:
#
# script /etc/rc.d/rc.firewall
#
# PPP users:
# ----------
# If you aren't already aware, the /etc/ppp/ip-up script is always run when
# a PPP connection comes up. Because of this, we can make the ruleset go and
# get the new PPP IP address and update the strong firewall ruleset.
#
# If the /etc/ppp/ip-up file already exists, you should edit it and add a line
# containing "/etc/rc.d/rc.firewall" near the end of the file.
#
# If you don't already have a /etc/ppp/ip-up sccript, you need to create the
# following link to run the /etc/rc.d/rc.firewall script.
#
# ln -s /etc/rc.d/rc.firewall /etc/ppp/ip-up
#
# * You then want to enable the #ed out shell command below *
#
#
# PPP and DHCP Users:
# -------------------
# Remove the # on the line below and place a # in front of the line after that.
#
#extip="`/sbin/ifconfig ppp0 | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`"
# For PPP users with STATIC IP addresses:
#
extip="your.static.PPP.address"
# ALL PPP and DHCP users must set this for the correct EXTERNAL interface name
extint="ppp0"
# Assign the internal IP
intint="eth0"
intnet="192.168.0.0/24"
# MASQ timeouts
#
# 2 hrs timeout for TCP session timeouts
# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received
# 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a 30sec firewall timeout in ICQ itself)
#
ipchains -M -S 7200 10 60
#############################################################################
# Incoming, flush and set default policy of reject. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
ipchains -F input
ipchains -P input REJECT
# local interface, local machines, going anywhere is valid
#
ipchains -A input -i $intint -s $intnet -d 0.0.0.0/0 -j ACCEPT
# remote interface, claiming to be local machines, IP spoofing, get lost
#
ipchains -A input -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT
# remote interface, any source, going to permanent PPP address is valid
#
ipchains -A input -i $extint -s 0.0.0.0/0 -d $extip/32 -j ACCEPT
# loopback interface is valid.
#
ipchains -A input -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# catch all rule, all other incoming is denied and logged. pity there is no
# log option on the policy but this does the job instead.
#
ipchains -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#############################################################################
# Outgoing, flush and set default policy of reject. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
ipchains -F output
ipchains -P output REJECT
# local interface, any source going to local net is valid
#
ipchains -A output -i $intint -s 0.0.0.0/0 -d $intnet -j ACCEPT
# outgoing to local net on remote interface, stuffed routing, deny
#
ipchains -A output -i $extint -s 0.0.0.0/0 -d $intnet -l -j REJECT
# outgoing from local net on remote interface, stuffed masquerading, deny
#
ipchains -A output -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT
# anything else outgoing on remote interface is valid
#
ipchains -A output -i $extint -s $extip/32 -d 0.0.0.0/0 -j ACCEPT
# loopback interface is valid.
#
ipchains -A output -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# catch all rule, all other outgoing is denied and logged. pity there is no
# log option on the policy but this does the job instead.
#
ipchains -A output -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#############################################################################
# Forwarding, flush and set default policy of deny. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
ipchains -F forward
ipchains -P forward DENY
# Masquerade from local net on local interface to anywhere.
#
ipchains -A forward -i $extint -s $intnet -d 0.0.0.0/0 -j MASQ
#
# catch all rule, all other forwarding is denied and logged. pity there is no
# log option on the policy but this does the job instead.
#
ipchains -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#End of file.
With IPCHAINS, you can block traffic to a particular site using the "input", "output", and/or "forward" rules. Remember that the set of rules are scanned t op to bottom and "-A" tells IPCHIANS to "append" this new rule to the existing set of rules. So with this in mind, any specific restrictions need to come bef ore global rules. For example: Using "input" rules: Probably the fastest and most efficient method to block traffic but it only stops the MASQed machines and NOT the firewall machine itself. Of course you might want to allow that combination. Anyway, to block 204.50.10.13: In the /etc/rc.d/rc.firewall ruleset: ... start of "input" rules ... # reject and log local interface, local machines going to 204.50.10.13 # ipchains -A input -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT # local interface, local machines, going anywhere is valid # ipchains -A input -s 192.168.0.0/24 -d 0.0.0.0/0 -l -j ACCEPT ... end of "input" rules ...
Using "output" rules: This is the slower method to block traffic because the packets must go through masquerading first before they are dropped. Yet, this rule even stops the firewall machine from accessing the forbidden site.
... start of "output" rules ... # reject and log outgoing to 204.50.10.13 # ipchains -A output -s $ppp_ip/32 -d 204.50.10.13/32 -l -j REJECT # anything else outgoing on remote interface is valid # ipchains -A output -s $ppp_ip/32 -d 0.0.0.0/0 -l -j ACCEPT ... end of "output" rules ... Using "forward" rules: Probably slower than "input" rules for blocking traffic, this still only stops masqueraded machines (e.g. internal machines). The firewall machine can still reach forbidden site(s).
... start of "forward" rules ... # Reject and log from local net on PPP interface to 204.50.10.13. # ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT # Masquerade from local net on local interface to anywhere. # ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 0.0.0.0/0 -j MASQ ... end of "forward" rules ... No need for a special rule to allow machines on the 192.168.0.0/24 network to go to 204.50.11.0. Why? It is already covered by the global MASQ rule. NOTE: Unlike IPFWADM, IPCHIANS has only one way of coding the interfaces name. IPCHAINS uses the "-i eth0" option where as IPFWADM had both "-W" for the interface name and "-V" for the interface's IP address.
6.6 IP Masquerading multiple internal networksMasquerading more than one internal network is fairly simple. You need to first make sure that all of your networks are running correctly (both internal and external). You then need to enable traffic to pass to both the other internal interfaces and to be MASQed to the Internet. Next, you need to enable Masquerading on the INTERNAL interfaces. This example uses a total of THREE interfaces: eth0 is the EXTERNAL connection to the Internet, eth1 is the 192.168.0.0 network, and eth2 is the 192.168.1.0 network. Both eth1 and eth2 will be MASQed out of interface eth0. In your rc.firewall ruleset next to the existing MASQ enable line, add the following:
Please note that it is CORRECT to have "eth0" specified multiple times for the exmples shown above. The reason for this is the Linux kernel needs to know which interface is used for OUTGOING traffic. Since eth0 in the above examples is the Internet connection, it is listed for each internal interface.
6.7 IP Masquerade and Dial-on-Demand Connections
6.8 IPPORTFW, IPMASQADM, IPAUTOFW, REDIR, UDPRED, and other Port Forwarding tools
IPPORTFW, IPAUTOFW, REDIR, UDPRED, and other programs are generic TCP and/or UDP port forwarding tools for Linux IP Masquerade. These tools are typically used with or as a replacement for specific IP MASQ modules like the current ones for FTP, Quake, etc. With port forwarders, you can now re-direct data connections from the Internet to an internal, privately addressed machine behind your IP MASQ server. This forwarding ability includes network protocols such as TELNET, WWW, SMTP, FTP (with a special patch - see below), ICQ, and many others. NOTE: If you are just looking to do simple port forwarding without IP Masquerading support, you will STILL NEED to enable IP Masquerading in both the kernel AND in either your IPFWADM or IPCHAINS ruleset to then be able to use Linux's port forwarding tools. So why all the different choices? IPAUTOFW, REDIR, and UDPRED (all URLs are in the 2.0.x-Requirements section) were the first tools available to IP MASQ users to allow this functionality. Later, as Linux IP Masquerade matured, these tools were eventually replaced by IPPORTFW which is a more intelligent solution. Because of the availablity of the newer tools, it is *HIGHLY DISCOURAGED* to use the old tools such as IPAUTOFW and REDIR because they don't properly notify the Linux kernel of their presence and can ultimately CRASH your Linux server with extreme use. It should also be noted that there is also the newest method, MFW. MFW's major benefit its its tigher integration with the IPCHAINS tool. With this solution, you use a IPCHAINS ruleset to "Mark" a specific packet and then create a different chain to then do the proper forwarding. Currently, this method isn't covered in the HOWTO. NOTE #2: With PORTFW in 2.2.x kernels, internal machines CANNOT use the same PORTFWed IP address to access an internal machine though it works fine with external computers on the Internet. If this is an issue for you, you can ALSO impliment the REDIR portfw tool to let internal machines get redirected to the internal server. One good think to note is the upcoming NetFilter toolset solves this issue. If you would like a technical explination of why this internal/external forwarding doesn't work, please page down towards the bottom of the 2.2.x PORTFW section for a note from Juan. NOTE #3: The forwarding of FTP server traffic to an internal MASQed FTP server, known as PORTFW FTP, is now supported for both the 2.2.x and 2.2.x kernels. This is possible either through the patching the Linux kernel sources though the support is not currently built into the main Linux kernel or using an external FTP proxy program. It should be noted that the kernel module code is still experimental and some people get better results with ACTIVE FTP sessions compared to PASSIVE connections. Interestingly enough, other people have seen the exact opposite behavior. Please let us know what your results are like. More about this is covered below in both the 2.2.x and 2.0.x sections as the solutions use different patches.
Before jumping right into installing either the 2.0.x IPPORTFW or 2.2.x version of IPMASQADM with IPPORTFW support, network security can be an issue with any port forwarder. The reason for this is because these tools basically create a hole in the packet firewall for the forwarded TCP/UDP ports. Though this doesn't pose any threat to your Linux machine, it might be an issue to the internal machine that this traffic is being forwarded to. No worries though, this is what Steven Clarke (the author of IPPORTFW) had to say about that:
With this said, it's important to have a strong firewall ruleset. Please see the Strong-IPFWADM-Rulesets and Strong-IPCHAINS-Rulesets sections for more details on strong rulesets.
So, to install IPPORTFW forwarding support for either a 2.2.x or 2.0.x kernel, you need to re-compile the Linux kernel to support IPPORTFW.
IPMASQADM with IPPORTFW support on 2.2.x kernels
First, make sure you have the newest 2.2.x kernel uncompressed into /usr/src/linux. If you haven't already done this, please see the Kernel-Compile section for full details. Next, download the "ipmasqadm.c" program from the 2.2.x-Requirements section into the /usr/src/ directory. Next, you'll need to compile the 2.2.x kernel as shown in the Kernel-Compile section. Be sure to say YES to the IPPORTFW option when you configure the kernel. Once the kernel compile is complete and you have rebooted, return to this section. Now, compile and install the IPMASQADM tool:
Now, for this example, we are going to allow ALL WWW Internet traffic (port 80) hitting your Internet TCP/IP address to then be forwarded to the internal Masqueraded machine at IP address 192.168.0.10. PORTFW FTP: As mentioned above, there are two solutions for forwarding FTP server traffic to an internal MASQed PC. The first solution *IS* a BETA level IP_MASQ_FTP module for 2.2.x kernels to PORT Forward FTP connections to an internal MASQed FTP server. The other method is using a FTP proxy program (the URL is in the 2.2.x-Requirements section. It should also be noted that the FTP kernel module also supports the adding of additional PORTFW FTP ports on the fly without the requirement of unloading and reloaded the IP_MASQ_FTP module and thus breaking any existing FTP transfers. You can find more about this new code at the IPMASQ WWW site at http://ipmasq.cjb.net. There is also examples and some more information about PORTFWed FTP connection below in the 2.0.x. kernel section. NOTE: Once you enable a port forwarder on port 80, that port can no longer be used by the Linux IP Masquerade server. To be more specific, if you have a WWW server already running on the MASQ server, a port forward will now give all Internet users the WWW pages from the -INTERNAL- WWW server and not the pages on your IP MASQ server. Anyway, to enable port forwarding, edit the /etc/rc.d/rc.firewall ruleset. Add the follow lines but be sure to replace the word "$extip" with your Internet IP address. NOTE: If you use get a DYNAMIC TCP/IP address from your ISP (PPP, ADSL, Cablemodems, etc.), you will NEED to make your /etc/rc.d/rc.firewall ruleset more intelligent. To do this, please see the Strong-IPCHAINS-Rulesets section from above or TrinityOS - Section 10 for more details on strong rulesets and Dynamic IP addresses. I'll give you a hint though: /etc/ppp/ip-up for PPP users.
That's it! Just re-run your /etc/rc.d/rc.firewall ruleset and test it out! If you get the error message "ipchains: setsockopt failed: Protocol not available", you AREN'T running your new kernel. Make sure that you moved the new kernel over, re-run LILO, and then reboot again. If you are sure you are running your new kernel, run the command "ls /proc/net/ip_masq" and make sure the "portfw" file exists. If it doesn't, you must have made an error when configuring your kernel. Try again.
For those who want to understand why PORTFW cannot redirect traffic for both external and internal interfaces, here is an email from Juanjo that better explains it:
From Juanjo Ciarlante
--
>If I use:
>
> ipmasqadm portfw -a -P tcp -L 1.2.3.4 80 -R 192.168.2.3 80
>
>Everything works great from the outside but internal requests for the same
>1.2.3.4 address fail. Are there chains that will allow a machine on localnet
>192.168.2.0 to accesss www.periapt.com without using a proxy?
Actually not.
I usually setup a ipmasqadm rule for outside, *AND* a port
redirector for inside. This works because ipmasqadm hooks before
redir will get the eventual outside connection, _but_ leaves things
ok if not (stated by APPROPIATE rules).
The actual "conceptual" problem comes from the TRUE client (peer) IP
goal (thanks to masq) being in same net as target server.
The failing scenario for "local masq" is :
client: 192.168.2.100
masq: 192.168.2.1
serv: 192.168.2.10
1)client->server packet
a) client: 192.168.2.100:1025 -> 192.168.2.1:80 [SYN]
b) (masq): 192.168.2.100:1025 -> 192.168.2.10:80 [SYN]
(and keep 192.168.2.1:61000 192.168.2.100:1025 related)
c) serv: gets masqed packet (1b)
2)server->client packet
a) serv: 192.168.2.10:80 -> 192.168.2.100:1025 [SYN,ACK]
b) client: 192.168.2.100:1025 -> 192.168.2.10:80 [RST]
Now take a moment to compare (1a) with (2a).
You see, the server replied DIRECTLY to client bypassing masq (not
letting masq to UNDO the packet hacking) because it is in SAME net, so
the client resets the connection.
hope I helped.
Warm regards
Juanjo
IPPORTFW on 2.0.x kernels
First, make sure you have the newest 2.0.x kernel uncompressed into /usr/src/linux. If you haven't already done this, please see the Kernel-Compile section for full details. Next, download the "ipportfw.c" program and the "subs-patch-x.gz" kernel patch from the 2.0.x-Requirements section into the /usr/src/ directory. NOTE: Please replace the "x" in the "subs-patch-x.gz" file name with the most current version available on the site. Next, if you plan on port forwarding FTP traffic to an internal server, you will have to apply an additional NEW IP_MASQ_FTP module patch found in the 2.0.x-Requirements section. More details regarding this are later in this section. Please note that this is NOT the same patch as for the 2.2.x kernels so some functionality such as the dynamic FTP PORT functionality is not present.
Now, copy the IPPORTFW patch (subs-patch-x.gz) into the Linux directory Next, apply the kernel patch to create the IPPORTFW kernel option:
Ok, time to compile the kernel as shown in the Kernel-Compile section. Be sure to say YES to the IPPORTFW option now available when you configure the kernel. Once the compile is complete and you have rebooted, return to this section. Now with a newly compiled kernel, please compile and install the actual "IPPORTFW" program
Now, for this example, we are going to allow ALL WWW Internet traffic (port 80) hitting your Internet TCP/IP address to then be forwarded to the internal Masqueraded machine at IP address 192.168.0.10. NOTE: Once you enable a port forwarder on port 80, that port can no longer be used by the Linux IP Masquerade server. To be more specific, if you have a WWW server already running on the MASQ server and then you port forward port 80 to an internal MASQed computer, ALL internet users will see the WWW pages pages from the -INTERNAL- WWW server and not the pages on your IP MASQ server. The only work around for this is to port forward some other port, say 8080, to your internal MASQ machine. Though this will work, all Internet users will have to append :8080 to the URL to then contact the internal MASQed WWW server. Anyway, to enable port forwarding, edit the /etc/rc.d/rc.firewall ruleset. Add the follow lines but be sure to replace the word "$extip" with your Internet IP address. NOTE: If you use get a DYNAMIC TCP/IP address from your ISP (PPP, ADSL, Cablemodems, etc.), you will NEED to make your /etc/rc.d/rc.firewall ruleset more intelligent. To do this, please see the Strong-IPCHAINS-Rulesets section from above or TrinityOS - Section 10 for more details on strong rulesets and Dynamic IP addresses. I'll give you a hint though: /etc/ppp/ip-up for PPP users.
That's it! Just re-run your /etc/rc.d/rc.firewall ruleset and test it out! If you get the error message "ipfwadm: setsockopt failed: Protocol not available", you AREN'T running your new kernel. Make sure that you moved the new kernel over, re-run LILO, and then reboot again.
Port Forwarding FTP servers: If you plan on port forwarding FTP to an internal machine, things get more complicated. The reason for this is because the standard IP_MASQ_FTP kernel module wasn't written for this though some users report that it works without any problems. Personally, without the patch, I've heard that extended file transfers in excess of 30 minutes will fail without the patch while other people swear that it works flawlessly. Anyway, I recommend that you try the following PORTFW instruction with the STOCK ip_masq_ftp module and see if it works for you. If it doesn't, try using the modified ip_masq_ftp module. For those who need the module, Fred Viles wrote a modified IP_MASQ_FTP module to make things work. If you are curious what EXACTLY is the issues, download the following archive since Fred documents it quite well. Also understand that this patch is somewhat experimental and should be treated as such. It should be also noted that this patch is ONLY available for the 2.0.x kernels though there is a different patch available for 2.2.x kernels. So, to get the 2.0.x patch working, you need to:
Once this is complete, edit the /etc/rc.d/rc.firewall ruleset and add the follow lines but be sure to replace the word "$extip" with your Internet IP address. This example, like above, will allow ALL FTP Internet traffic (port 21) hitting your Internet TCP/IP address to then be forwarded to the internal Masqueraded machine at IP address 192.168.0.10. NOTE: Once you enable a port forwarder on port 21, that port can no longer be used by the Linux IP Masquerade server. To be more specific, if you have a FTP server already running on the MASQ server, a port forward will now give all Internet users the FTP files from the -INTERNAL- FTP server and not the files on your IP MASQ server.
That's it! Just re-run your /etc/rc.d/rc.firewall ruleset and test it out! If you get the error message "ipchains: setsockopt failed: Protocol not available", you AREN'T running your new kernel. Make sure that you moved the new kernel over, re-run LILO, and then reboot again. If you are sure you are running your new kernel, run the command "ls /proc/net" and make sure the "ip_portfw" file exists. If it doesn't, you must have made an error when configuring your kernel. Try again.
6.9 CU-SeeMe and Linux IP-Masquerade
Linux IP Masquerade supports CuSeeme via the "ip_masq_cuseeme" kernel module. This kernel modules should be loaded in the /etc/rc.d/rc.firewall script. Once the "ip_masq_cuseeme" module is installed, you should be able to both initiate and receive CuSeeme connections to remote reflectors and/or users. NOTE: It is recommended to use the IPPORTFW tool instead of the old IPAUTOFW tool for running CuSeeme. If you need more explicit information on configuring CuSeeme, see Michael Owings's CuSeeMe page for a Mini-HOWTO or The IP Masquerade Resources for a mirror of the Mini-HOWTO.
6.10 Mirabilis ICQThere are two methods of getting ICQ to work behind a Linux MASQ server. One solution is to use a new ICQ Masq module and the other solution is to use IPPORTFW. The ICQ module has some benefits. It allows for simple setup of multiple ICQ users behind a MASQ server. It also doesn't require any special changes to the ICQ client(s). Recently, the 2.2.x version of the module was updated to support file transfer and read-time chat. Yet, for the 2.0.x kernel module, file transfers and real-time chat still isn't fully supported. Anyway, I now feel this is the PREFERRED method to get ICQ working with IP Masq running on 2.2.x+ kernels.
With the IPPORTFW setup, you will have to make some changes on both Linux and ICQ clients but all ICQ messaging, URLs, chat, file transfer, etc. work. If you are interested in Andrew Deryabin's djsf@usa.net ICQ IP Masq module for the 2.2.x kernels. Please see the 2.2.x-Requirements section for details. If you rather use the classic method of getting ICQ to run behind a MASQ server, follow these steps:
6.11 Gamers: The LooseUDP patch
The LooseUDP patch allows NAT-friendly games that usually use UDP connections to both WORK and perform quite well behind a Linux IP Masquerade server. Currently, LooseUDP is available as a patch for 2.0.36+ kernels and it is already built into 2.2.3+ kernels though it is now DISABLED by DEFAULT in 2.2.16+. To get LooseUDP running on a 2.0.x kernel, follow the following steps:
To get LooseUDP running on a 2.2.x kernel, follow the following steps:
Once you are running the new LooseUDP enabled kernel, you should be good to go for most NAT-friendly games. Some URLs have been given for patches to make games like BattleZone and others NAT friendly. Please see the Game-Clients section for more details.
Next Previous Contents |