May 2001 - openSUSE Security - openSUSE Mailing Lists

Re: [suse-security] SuSEfirewall2 & port forwarding
by Oscar Garcia 09 May '01

09 May '01

>From: "Greisberger Christophe" <greisby(a)zenon-media.com> >To: <suse-security(a)suse.com> >Subject: [suse-security] SuSEfirewall2 & port forwarding >Date: Wed, 9 May 2001 14:26:00 +0200 > >Hi! > >I have 4 web servers, and want to move them behind a firewall. >I want to give their IP to the firewall, and then redirect >the incoming requests to the servers, which would have >non-official IP addresses (e.g. 192.168.0.x) >Is there any possibility to do this with SuSEfirewall2? > >Backward masquerading doesn't allow to specify interfaces, so >that the traffic on one interface would be redirected to an IP, >and the traffic on another interface should be redirected to >another one. > >Else, is there any possibility to add user rules to SuSEfirewall? >I think that something like this should work, right? > > iptables -t nat -A POSTROUTING -o eth1 \ > --to-source <public_address_1>:80 > --to-destination <private_addr_1>:80 -j SNAT > >Thanks in advance >Christophe > >--------------------------------------------------------------------- >To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com >For additional commands, e-mail: suse-security-help(a)suse.com Next Previous Contents -------------------------------------------------------------------------------- 6. Other IP Masquerade Issues and Software Support 6.1 Problems with IP Masquerade Some 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 services By 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 Masquerade General Clients: Archie all supported platforms, file searching client (not all archie clients are supported) FTP all supported platforms, with the ip_masq_ftp.o kernel module for active FTP connections. Gopher client all supported platforms HTTP all supported platforms, WWW surfing IRC all IRC clients on various supported platforms, DCC is supported via the ip_masq_irc.o module NNTP (USENET) all supported platforms, USENET news client PING all platforms, with ICMP Masquerading kernel option POP3 all supported platforms, email clients SSH all supported platforms, Secure TELNET/FTP clients SMTP all supported platforms, email servers like Sendmail, Qmail, PostFix, etc. TELNET all supported platforms, remote session TRACEROUTE UNIX and Windows based platforms , some variations may not work VRML Windows(possibly all supported platforms), virtual reality surfing WAIS client all supported platforms Multimedia and Communication Clients: All H.323 programs - MS Netmeeting, Intel Internet Phone Beta , and other H.323 applications - There are now two solutions to get this to work through IPMASQed connections: There is a stable BETA module available on the MASQ WWW site or at http://www.coritel.it/projects/sofia/nat.html to work with Microsoft Netmeeting v3.x code on 2.2.x kernels. There is also another module version on the MASQ WWW site specifically for Netmeeting 2.x with 2.0.x kernels but it doesn't support Netmeeting v3.x. Another commercial solution is the Equivalence's PhonePatch H.323 gateway. Alpha Worlds Windows, Client-Server 3D chat program CU-SeeMe all supported platforms, with the ip_masq_cuseeme module loaded, please see the CuSeeme section for more details. ICQ all supported clients. Requires the Linux kernel to be compiled with IPPORTFW support and ICQ is configured to be behind a NON-SOCKS proxy. A full description of this configuration is in the ICQ section. Internet Phone 3.2 Windows, Peer-to-peer audio communications, people can reach you only if you initiate the call, but people cannot call you without a specific port forwarding setup. See the Forwarders section for more details. Internet Wave Player Windows, network streaming audio Powwow Windows, Peer-to-peer Text audio whiteboard communications, people can reach you only if you initiate the call, but people cannot call you without a specific port forwarding setup. See the Forwarders se ction for more details. Real Audio Player Windows, network streaming audio, higher quality available with the ip_masq_raudio UDP module True Speech Player 1.1b Windows, network streaming audio VDOLive Windows, with the ip_masq_vdolive patch Worlds Chat 0.9a Windows, Client-Server 3D chat program Games - See the LooseUDP section for more details on the LooseUDP patch Battle.net Works but requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. See the Forwarders section for more details. Please note that FSGS and Bnetd servers still require IPPORTFW since they haven't been re-written to be NAT-friendly. BattleZone 1.4 Works with LooseUDP patch and new NAT-friendly .DLLs from Activision Dark Reign 1.4 Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. See the Forwarders section for more details. Diablo Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. Newer versions of Diablo use only TCP port 6112 and UDP port 6112. See the Forwarders section for more details. Heavy Gear 2 Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. See the Forwarders section for more details. Quake I/II/III Works right out of the box but requires the ip_masq_quake module if there are more than one Quake I/II/III player behind a MASQ box. Also, this module only supports Quake I and QuakeWorld by default. If you need to support Quake II or non-default server ports, please see the module install section of the rc.firewall-2.0.x and rc.firewall-2.2.x rulesets. StarCraft Works with the LooseUDP patch and IPPORTFWing TCP and UDP ports 6112 to the internal MASQed game machine. See the Forwarders section for more details. WorldCraft Works with LooseUDP patch Other Clients: Linux net-acct package Linux, network administration-account package NCSA Telnet 2.3.08 DOS, a suite containing telnet, ftp, ping, etc. PC-anywhere for Windows MS-Windows, Remotely controls a PC over TCP/IP, only work if it is a client but not a host without a specific port forwarding setup. See the Forwarders section for more details. Socket Watch uses NTP - network time protocol Clients that do not have full support in IP MASQ: Intel Streaming Media Viewer Beta 1 Cannot connect to server Netscape CoolTalk Cannot connect to opposite side WebPhone Cannot work at present (it makes invalid assumptions about addresses). 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 networks Masquerading 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: 2.2.x kernels with IPCHAINS #Enable internal interfaces to communication between each other /sbin/ipchains -A forward -i eth1 -d 192.168.0.0/24 /sbin/ipchains -A forward -i eth2 -d 192.168.1.0/24 #Enable internal interfaces to MASQ out to the Internet /sbin/ipchains -A forward -j MASQ -i eth0 -s 192.168.0.0/24 -d 0.0.0.0/0 /sbin/ipchains -A forward -j MASQ -i eth0 -s 192.168.1.0/24 -d 0.0.0.0/0 2.0.x kernels with IPFWADM #Enable internal interfaces to communication between each other /sbin/ipfwadm -F -a accept -V 192.168.0.1 -D 192.168.1.0/24 /sbin/ipfwadm -F -a accept -V 192.168.1.1 -D 192.168.0.0/24 #Enable internal interfaces to MASQ out to the Internet /sbin/ipfwadm -F -a masq -W eth0 -S 192.168.0.0/24 -D 0.0.0.0/0 /sbin/ipfwadm -F -a masq -W eth0 -S 192.168.1.0/24 -D 0.0.0.0/0 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 If you would like to setup your network to automatically dial up the Internet, ether the Diald demand dial-up or new versions of the PPPd packages will be of great utility. Diald is the recommended solution due to its more granular configuration. To setup Diald, please check out the Setting Up Diald for Linux Page or TrinityOS - Section 23 Once Diald and IP Masq have been setup properly, any MASQed client machines that initiate a web, telnet or ftp session will make the Linux box dynamically bring up its Internet link. There is a timeout that will occur with the first connection. This is inevitable if you are using analog modems. The time taken to establish the modem link and the PPP connections may cause your client program (WWW browser, etc.). This isn't common though. If this does happen, just retry that Internet traffic request (say a WWW page) again and it should come up fine. You can also try setting echo "1" > /proc/sys/net/ipv4/ip_dynaddr kernel option to help with this initial setup. 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: "Port Forwarding is only called within masquerading functions so it fits inside the same IPFWADM/IPCHAINS rules. Masquerading is an extension to IP forwarding. Therefore, ipportfw only sees a packet if it fits both the input and masquerading ipfwadm rule sets." 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. 2.2.x kernel users will already have the IPPORTFW kernel option available via IPMASQADM 2.0.x users will need to apply a simple kernel option patch 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: cd /usr/src tar xzvf ipmasqadm-x.tgz cd ipmasqadm-x make make install 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. /etc/rc.d/rc.firewall -- #echo "Enabling IPPORTFW Redirection on the external LAN.." # /usr/sbin/ipmasqadm portfw -f /usr/sbin/ipmasqadm portfw -a -P tcp -L $extip 80 -R 192.168.0.10 80 -- 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 cp /usr/src/subs-patch-1.37.gz /usr/src/linux Next, apply the kernel patch to create the IPPORTFW kernel option: cd /usr/src/linux zcat subs-patch-1.3x.gz | patch -p1 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 cd /usr/src gcc ipportfw.c -o ipportfw mv ipportfw /usr/local/sbin 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. /etc/rc.d/rc.firewall -- #echo "Enabling IPPORTFW Redirection on the external LAN.." # /usr/local/sbin/ipportfw -C /usr/local/sbin/ipportfw -A -t$extip/80 -R 192.168.0.10/80 #Please note that PORTFWing port 20 is NOT required for ACTIVE # connections as the internal FTP server will initiate this # port 20 connection and it will be properly handled by the # classic MASQ mechanisms. -- 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: Apply the IPPORTFW kernel patch as shown earlier in this section FIRST. Download the "msqsrv-patch-36" from Fred Viles's FTP server in the 2.0.x-Requirements section and put it into /usr/src/linux. Patch the kernel with this new code by running "cat msqsrv-patch-36 | patch -p1" Next, replace the original "ip_masq_ftp.c" kernel module with the new one mv /usr/src/linux/net/ipv4/ip_masq_ftp.c /usr/src/linux/net/ipv4/ip_masq_ftp.c.orig mv /usr/src/linux/ip_masq_ftp.c /usr/src/linux/net/ipv4/ip_masq_ftp.c Lastly build and install the kernel with this new code in place. 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. /etc/rc.d/rc.firewall -- #echo "Enabling IPPORTFW Redirection on the external LAN.." # /usr/local/sbin/ipportfw -C /usr/local/sbin/ipportfw -A -t$extip/21 -R 192.168.0.10/21 #NOTE: If you are using multiple local port numbers to PORTFW # to multuple internal FTP servers (say, 21, 2121, 2112, # etc, you need to configure the ip_masq_ftp nodule to # listen to these ports. To do this, edit the # /etc/rc.d/rc.firewall script as shown in this HOWTO # to look like: # # /sbin/modprobe ip_masq_ftp ports=21,2121,2112 # # Re-run the /etc/rc.d/rc.firewall script for these changes to # take effect. #Please note that PORTFWing port 20 is probably NOT required # for ACTIVE connections as the internal FTP server will # initiate this port 20 connection and it will be properly # handled by the classic MASQ mechanisms. -- 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 ICQ There 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(a)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: First, you need to be running a Linux kernel with IPPPORTFW enabled. Please see the Forwarders section for more details. Next, you need to add the following lines to your /etc/rc.d/rc.firewall file. This example assumes that 10.1.2.3 is your external Internet IP address and your internal MASQed ICQ machine is 192.168.0.10: The following example is for a 2.0.x kernel with IPFWADM: I have included two examples here for the user: Either once works fine: Example #1 -- /usr/local/sbin/ipportfw -A -t10.1.2.3/2000 -R 192.168.0.10/2000 /usr/local/sbin/ipportfw -A -t10.1.2.3/2001 -R 192.168.0.10/2001 /usr/local/sbin/ipportfw -A -t10.1.2.3/2002 -R 192.168.0.10/2002 /usr/local/sbin/ipportfw -A -t10.1.2.3/2003 -R 192.168.0.10/2003 /usr/local/sbin/ipportfw -A -t10.1.2.3/2004 -R 192.168.0.10/2004 /usr/local/sbin/ipportfw -A -t10.1.2.3/2005 -R 192.168.0.10/2005 /usr/local/sbin/ipportfw -A -t10.1.2.3/2006 -R 192.168.0.10/2006 /usr/local/sbin/ipportfw -A -t10.1.2.3/2007 -R 192.168.0.10/2007 /usr/local/sbin/ipportfw -A -t10.1.2.3/2008 -R 192.168.0.10/2008 /usr/local/sbin/ipportfw -A -t10.1.2.3/2009 -R 192.168.0.10/2009 /usr/local/sbin/ipportfw -A -t10.1.2.3/2010 -R 192.168.0.10/2010 /usr/local/sbin/ipportfw -A -t10.1.2.3/2011 -R 192.168.0.10/2011 /usr/local/sbin/ipportfw -A -t10.1.2.3/2012 -R 192.168.0.10/2012 /usr/local/sbin/ipportfw -A -t10.1.2.3/2013 -R 192.168.0.10/2013 /usr/local/sbin/ipportfw -A -t10.1.2.3/2014 -R 192.168.0.10/2014 /usr/local/sbin/ipportfw -A -t10.1.2.3/2015 -R 192.168.0.10/2015 /usr/local/sbin/ipportfw -A -t10.1.2.3/2016 -R 192.168.0.10/2016 /usr/local/sbin/ipportfw -A -t10.1.2.3/2017 -R 192.168.0.10/2017 /usr/local/sbin/ipportfw -A -t10.1.2.3/2018 -R 192.168.0.10/2018 /usr/local/sbin/ipportfw -A -t10.1.2.3/2019 -R 192.168.0.10/2019 /usr/local/sbin/ipportfw -A -t10.1.2.3/2020 -R 192.168.0.10/2020 -- Example #2 -- port=2000 while [ $port -le 2020 ] do /usr/local/sbin/ipportfw -A t10.1.2.3/$port -R 192.168.0.10/$port port=$((port+1)) done -- The following example is for a 2.2.x kernel with IPCHAINS: I have included two examples here for the user: Either once works fine: Example #1 -- /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2000 -R 192.168.0.10 2000 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2001 -R 192.168.0.10 2001 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2002 -R 192.168.0.10 2002 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2003 -R 192.168.0.10 2003 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2004 -R 192.168.0.10 2004 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2005 -R 192.168.0.10 2005 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2006 -R 192.168.0.10 2006 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2007 -R 192.168.0.10 2007 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2008 -R 192.168.0.10 2008 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2009 -R 192.168.0.10 2009 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2010 -R 192.168.0.10 2010 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2011 -R 192.168.0.10 2011 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2012 -R 192.168.0.10 2012 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2013 -R 192.168.0.10 2013 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2014 -R 192.168.0.10 2014 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2015 -R 192.168.0.10 2015 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2016 -R 192.168.0.10 2016 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2017 -R 192.168.0.10 2017 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2018 -R 192.168.0.10 2018 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2019 -R 192.168.0.10 2019 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2020 -R 192.168.0.10 2020 -- Example #2 -- port=2000 while [ $port -le 2020 ] do /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 $port -R 192.168.0.10 $port port=$((port+1)) done -- Once your new rc.firewall is ready, reload the ruleset to make sure things are ok by simple typing in "/etc/rc.d/rc.firewall". If you get any errors, you either don't have IPPORTFW support in the kernel or you made a typo in the rc.firewall file. Now, in ICQ's Preferences-->Connection, configure it to be "Behind a LAN" and "Behind a firewall or Proxy". Now, click on "Firewall Settings" and configure it to be "I don't use a SOCK5 proxy". Also note that it was repviously recommended to change ICQ's "Firewall session timeouts" to "30" seconds BUT many users have found that ICQ becomes unreliable. It has been found that ICQ is more reliable with its stock timeout setting (don't enable that ICQ option) and simply change MASQ's timeout to 160 seconds. You can see how to change this timeout in the rc.firewall-2.0.x and rc.firewall-2.2.x rulesets. Finally, click on Next and configure ICQ to "Use the following TCP listen ports.." from "2000" to "2020". Now click done. Now ICQ will tell you that you have to restart ICQ for the changes to take effect. To be honest, I had to REBOOT the Windows9x machine to get things to work right but other people say otherwise. So.. try it both ways. It should also be noted that one user told me that simply portforwarding port 4000 to his ICQ machine worked best. He reported that everything worked fine (chat, file transfers, etc) WITHOUT re-configuring ICQ from its default settings. Your mileage might vary on this topic but I though you might like to hear about this alternative configuration. 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: Have the newest 2.0.x kernel sources uncompressed in the /usr/src/linux directory ABSOLUTELY REQUIRED for v2.0.x: Download and install the IPPORTFW patch from the 2.0.x-Requirements section and as described in the Forwarders Section of the HOWTO. Download the LooseUDP patch from the 2.0.x-Requirements section Now, put the LooseUDP patch in the /usr/src/linux directory. Once this is done, type in: For a compressed patch file: zcat loose-udp-2.0.36.patch.gz | patch -p1 For a NON-compressed patch file: cat loose-udp-2.0.36.patch | patch -p1 Now, depending on your version of "patch", You will then see the following text: patching file `CREDITS' patching file `Documentation/Configure.help' patching file `include/net/ip_masq.h' patching file `net/ipv4/Config.in' patching file `net/ipv4/ip_masq.c' If you see the text "Hunk FAILED" only ONCE and ONLY ONCE at the very beginning of the patching, don't be alarmed. You probably have an old patch file (this as been fixed) but it still works. If it fails completely, make sure you have applied the IPPORTFW kernel patch FIRST. Once the patch is installed, re-configure the kernel as shown in the Kernel-Compile section and be sure to say "Y" to the "IP: loose UDP port managing (EXPERIMENTAL) (CONFIG_IP_MASQ_LOOSE_UDP) [Y/n/?]" option. To get LooseUDP running on a 2.2.x kernel, follow the following steps: In the /etc/rc.d/rc.firewall script, goto the BOTTOM of the file and find the LooseUDP section. Change the "0" in the line: echo "0" > /proc/sys/net/ipv4/ip_masq_udp_dloose to a "1" and re-run the rc.firewall ruleset. An example of this is given in both the rc.firewall-2.2.x example and the stronger-rc.firewall-2.2.x example. 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 mail script Te respondo personalmente, y con copia a la lista, ya que me parece que varias veces lei que algunos preguntaban como hacer esto. Espero que les sirva de algo, igualmente lean el howto del ipchains, y vayan pensando en aprender de nuevo cuando el kernel 2.4 se generalice, porque cambian un poco las cosas. Configuracion en los clientes windows: - Supongamos que la IP itnerna del linux es 192.168.1.250, entonces lo unico que tendrias que configurar en los clientes windows es el efault gateway, que tendria que apuntar a esa IP. Configuracion del linux Lo que queres hacer se hace con el ipchains (si no lo tenes buscalo en el cd el suse que tiene que estar para instalar), una utilidad para configurar el packet filtering, esto lo hace directamente el kernel, asi que lo tenes que tener compilado con soporte para firewalling (no me acuerdo bien la opcion, pero esta en la parte de networking) Para hacer simplemente un masquerading de todo lo que pase por el 'firewall', con ejecutar el siguiente comando seria suficiente: 'ipchains -P forward MASQ' si no tenes ninguna otra regla o cadenas definidas, tendria que funcionar. Lo que hace es habilitar el masquerading para todo lo que pase por la cadena forward (si no entendes bien como funciona esto, leete el howto http://www.linux.org/docs/ldp/howto/IPCHAINS-HOWTO.html que realmente te va a servir, aunque en mi caso recien lo entendi del todo la cuarta o quinta vez que lo lei ;-). Bueno, con esto ya tendrias definido el masquerading, ahora tenes que ejecutar 'echo 1 > /proc/sys/net/ipv4/ip_forward' con esto habilitas el forwarding en el kernel. Si quere hacer ftp, vas a tener que cargar un modulo especial, ya que parece que hacer msquerading del ftp es medio complicado, esto lo habilitas con: 'insmod ip_masq_ftp' asi como tenes este modulo, hay algunos otros especiales para real audio, etc. No los conozco porque en la empresa nadie los usa, y en casa no me puse a jugar con esto, habra que investigar... Todas estas configuraciones permanecen en memoria, asi que cuando reinicies la maquina var a perder todo esto. Por eso te conviene hacer algun script que se ejecute cuando inicies la maquina. Por ejemplo, algo asi: #!/bin/bash /sbin/ipchains -P forward MASQ echo 1 > /proc/sys/net/ipv4/ip_forward insmod ip_masq_ftp GOOD LUCK It s working 100%.I am 1 server and 6 term all with masquerading. SHOTGUN SEE LATER!!!! _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

1 0

RE: [suse-security] sorry, very OT: No such file or directory
by Freudenberger Joerg 09 May '01

09 May '01

> > another thing is with dos-files: if the script is in DOS format, the > > interpreter can't be found, too > > That must have been it - I copied and pasted all the 2243 > lines into a new > file - and now it's running. If you use vim (the SuSE vi is a vim) it is more easy. :help ff to convert a file brute force at end of edit session :set ff=unix :wq at Beginning of edit session :set ff=unix :w :e! Yours Jörg

1 0

sorry, very OT: No such file or directory
by Bjoern Engels 09 May '01

09 May '01

Sorry for being so OT, but maybe somebody can point me to the correct mailing list (if there is one) or somewhere else where I can get help... The problem I'm having sounds ridiculous: I'm trying to call a shell script and get a "No such file or directory" error. The file IS there and executable and I DID put a ./ in front of it ;) First I thought the script contains a command or library call that's not being found or something, so I straced it: svr1:/cdrom/accmgnt/Linux/setup # ./nds-install bash: ./nds-install: No such file or directory svr1:/cdrom/accmgnt/Linux/setup # svr1:/cdrom/accmgnt/Linux/setup # strace ./nds-install execve("./nds-install", ["./nds-install"], [/* 59 vars */]) = 0 strace: exec: No such file or directory svr1:/cdrom/accmgnt/Linux/setup # Any idea where to get help on this ? (It's Novell's EDirectory I'm trying to install, but the guys in Provo are still asleep now, I think ;) Bjoern Engels --------------------------------------------- E-Mail: Bjoern Engels <bengels(a)lanworks.de> Date: 09-May-01 Time: 10:39:12 www.lanworks.de ---------------------------------------------

3 3

Message Log Question
by Derik Whittaker 09 May '01

09 May '01

I have been monitering my /var/log/message file and came across an entry that reads localhost portmap[9415]: connect from 63.237.56.1 to dump(): request from unauthorized host. Does this mean that some one has gotten into my system? I am running red hat 6.1 using ipchains and portsentry as a firewall. Any insight would be great. Derik Whittaker derik(a)graudo.com

8 11

2.2.19 rtl8139 test
by Roman Drahtmueller 09 May '01

09 May '01

Hi together, the kernel security update is underway. At ftp://ftp.suse.com/pub/people/mantel/next/ there is a 2.2.19 tarball. Could anybody who has a rtl8139 NIC check and see if the driver from the 2.2.19 tarball works properly for this NIC? We've had a report that the driver hangs the machine, but it couldn't be verified. Please report directly to me. In case something unusual turns out, I'll summarize. Roman. -- - - | Roman Drahtmüller <draht(a)suse.de> // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -

1 0

RE: [suse-security] stateful and dynamic inspection
by Reckhard, Tobias 09 May '01

09 May '01

> does ipchains support stateful inspection and dynamic filtering in kernel > 2.2.18? > No, the 2.2.x kernel packet filtering code (configured by ipchains) is not stateful. Note that the term "stateful inspection" belongs to the company Check Point, makers of the Firewall-1 line of products, so nothing besides Check Point's software supports "stateful inspection", strictly speaking. > whats about kernel 2.4.x and iptables? > Yes, the 2.4.x kernel PF code (netfilter, which is configured with the iptables tool) is stateful. > I found nothing on the web which > describes > the different filter functions on different network layers. > Hmm, have you read the Netfilter documentation? And do you know what stateful filtering is? If you've got in-depth questions, there's the netfilter mailing list and the ultimate reference: the source code itself. > Could anyone > give me a > short description which functions are implemented in kernels 2.2.1x and > 2.4.x, > or give me a link about these topics? > Well, the reference site is http://netfilter.kernelnotes.org, but I can't establish a connection at the moment. Just input "netfilter linux 2.4 iptables" to your favourite search engine and you should get enough hits to keep yourself busy for a while. HTH Tobias

1 0

stateful and dynamic inspection
by Christian Osterbrink 08 May '01

08 May '01

Hello, does ipchains support stateful inspection and dynamic filtering in kernel 2.2.18? whats about kernel 2.4.x and iptables? I found nothing on the web which describes the different filter functions on different network layers. Could anyone give me a short description which functions are implemented in kernels 2.2.1x and 2.4.x, or give me a link about these topics? Thanks Christian

2 1

Re: [suse-security] Kernel security
by Martin Fahlgren 08 May '01

08 May '01

Serveral distributors have already published updates... What is the problem with SuSE? A crisis? This is probably the "worst" exploit up to now and a big problem for all networks with many login accounts (web sites, schools, universities etc). So the options I have are 1) Compile and install my own kernel 2) Disable logins until SuSE comes with a new kernel 3) Switch to a distribution which provides the necessary updates Not funny at all Best regards Martin

3 2

Kernel security
by Martin Fahlgren 07 May '01

07 May '01

Warning! There are serious problems with all Linux kernels prior to version 2.2.19. Among these are possibilities for local denial of service or root exploits by exercising race conditions between the ptrace, exec, and/or suid system calls. Programs which exploit these problems have existed since middle of april. See www.securityfocus.com/bugtraq/archive for more info. A SuSE Security Announcement and a new kernel rpm are needed! Best regards Martin

3 2

Apache log entry
by Phil Schrettenbrunner 07 May '01

07 May '01

Good morning, today I have found a pretty strange entry in my Apache access.log. I run a SuSE Linux 7.1/Apache 1.3.14 on a box with DSL that is up most of the time. This is in my log : --- cut --- 207.33.111.32 - - [01/May/2001:10:20:41 +0200] "HEAD%00 /%20HTTP/1.0%0D%0A%0D%0AAccept%3A%20hzwllekiww/../../index.html%3fyzhwpxdpqqt=/. ./lfspjgqdafroxyzmqeispzlifdknzswkphpwbxympterothgnnrefekenoedtvutrueqxavfamhqak gqlkhgvtxorcexhkamivmrutqcttwdtgjowguhfvucfnvcuosbycwsxoxlcuhbaothdvorozuylagkjg xcltvmijhqhobzeqiyeyhvdcmewgypgwoquonegtbpsyzctqcjmexujwrdhonducylgugrpojgjspzvq fnelrjzfvzluaazetwmjlntmnhalhnbyvhohnzuivzigwzntbzfjdztwanypiiuqjmqcqzhvsulzkjgw uucluiizzwwwiyhzbclqdqeehgrwxnprvdjnybeaaxauoscurjpsiwwrkdpzffqxscrueusjseiaexqe uyyvubgpkixksnztaxcncrkuqbohdjqfwsaldgjjphfbdcpvsxoghxsntmyeznfspgxtjhomdqeddbme zgusewcueuyydyapgudfztiiyicoqcjwxknmuorxcstavughbneygwtdyptizplytraycfedeliukxkj cuoytcnnkrucjkfjbufsabssfjtvyvxdduxmlmuxsucqfyoklposnayxzcgirqvsewnzqyhrvvbdvris rggwwupwvhwtrogkhirehsoyrarsztkxsiksmvtqtnjmmbkytxxvqqjaguszamymgskwlihmsdincvqu aqrcnwaekqchrnqswrerjlqbzxypymunwslpdmfxtezkormnkvhndatghpdhfzkvnehfcuxhiwudtoic rqqjkazjpornbqeggtjzrbeuthuhndkqougdmvrmpdiggchgjhoikthefooyfrwuaxczpgijwwgnnmbq zfpqjicskqpfajntqegvbdyrrdrfrsrikqiisqvuonowcyjxfqotsoarsznlgsejqthnlhytzgnrbnlw ungkegdomoecaoftupfzblrybjxcfnkpzionfpuovfaslpuclrbqrewqtljfjgtdsdkawpoamughityq lksslzynqlfgakkvhrxluarjdhgtvqqvosreqevbtrzigdpruvseggjqvvyqbmlnccdksobcqnlkjvwr ngosejplxykhamphsuyyfdmkqumeondxnuktknmavayeljskmlfslqyophmgghqolwbnmougnowmiibi pkyeoxsodogpqynmczourpqytbblrhgajfbmusvagnmrisiyhrbwusaahammcbnsgmbwkwdtvqjjviwg phrszbxiisubpfcgpblfkvrnpjidtfvjjonlvdskelfxxilgyttxqhafxggjlqniyxgxhupthqlsvjom njbkdcdraizjltfyxifklmzgqvlqpnzyawdpzwzuykcqkmfsuejkfcjcnoalebpptymjegylsfyegvmh qnqfbvfezbuyehszciv/.././%4d%59%4c%4f%47%2e%50%48%54%4d%4c HTTP/1.0" 501 1911 --- cut --- and it shows up every second for a 15 Minutes period. The entries differ from each other. Does anyone know what this? Thank you very much! regards | phil -- Das einzige Backup, das Sie je brauchen werden, ist das, für das Sie keine Zeit hatten.

1 0

help :(
by Jesse yep 06 May '01

06 May '01

Hi, I'm new to this kernel 2.4.x and my ipchains don't seem to work i get an error like protocol unavailable or something, any idea how i can fix it. Or is there a better tool then ipchains? I don't have any kind of security at this point, I own SuSE 7.1 with kernel 2.4.0. Any idea how i can get some security on this box? __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/

3 2

OpenSSH versus SSH
by Marko Kaening 06 May '01

06 May '01

Hi, looks like I didn't notice that SSH seems to be really commercial now. Is this right? Do I need to pay for it if I am still using it? Is OpenSSH a full-featured substitute for SSH? Are there major problems in configuration to expect if I try to deinstall SSH and go for OpenSSH? Marko

10 15

SuSE Linux 7.1 / Kernel 2.4 and freeswan
by Thomas Stinner 06 May '01

06 May '01

Hello, i tried using Kernel 2.4 together with FreeSWAN under SuSE 7.1. Is it correct that there is no module for Kernel 2.4.x yet? -- Mit freundlichem Gruß Thomas Stinner - billiton internet services GmbH Geschäftsleitung -------------------------------------------------------------- direct phone: 0271/30386-11 direct mail: t.stinner(a)billiton.de Weitere Informationen finden Sie unter http://www.billiton.de/

2 1

port-scan-blocker
by Daniel Quappe 04 May '01

04 May '01

hey list, does anybody know an opportunity to block port-scans with ipchains etc. like some commerical firewalls do?! any solution is appreciated...;-) bye, daniel -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net

4 4

missing mc update file
by Bob Vickers 04 May '01

04 May '01

Hello, The file ftp://ftp.suse.com/pub/suse/i386/update/7.1/ap1/mc-4.5.51-1.i386.rpm referenced in http://www.suse.de/de/support/security/2001_011_mc.txt seems to have gone missing...is it being updated? Bob ============================================================== Bob Vickers R.Vickers(a)cs.rhul.ac.uk Dept of Computer Science, Royal Holloway, University of London WWW: http://www.cs.rhul.ac.uk/home/bobv Phone: +44 1784 443691

2 1

SuSE Security Announcement: sgmltool
by Sebastian Krahmer 04 May '01

04 May '01

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: sgmltool-1.0.9-266 Announcement-ID: SuSE-SA:2001:16 Date: Friday, May 4th, 14:55:35 CEST 2001 Affected SuSE versions: 6.3, 6.4, 7.0, 7.1 Vulnerability Type: local fileaccess problem Severity (1-10): 2 SuSE default package: yes Other affected systems: All UN*X systems using this package Content of this advisory: 1) security vulnerability resolved: sgmltool problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information The sgmltool programs ("sgml2html" and others) are used to convert SGML-files into various other formats. During operation, the underlying SGML perlmodule creates temporary files in an insecure way. This allows attackers to destroy arbitrary files owned by the user who invoked the sgmltool program. The problem has been fixed by creating temporary files with the exclusive (O_EXCL) option upon opening them. Download the update package from locations desribed below and install the package with the command `rpm -Uhv file.rpm'. The md5sum for each file is in the line below. You can verify the integrity of the rpm files using the command `rpm --checksig --nogpg file.rpm', independently from the md5 signatures below. i386 Intel Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/i386/update/7.1/sgm1/sgmltool-1.0.9-302.i386.rpm bdedaefb82dc2bb8ff0a522607b80ac3 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/sgmltool-1.0.9-302.src.rpm dc5612aa475c5d6dcaaeee86e6bf985f SuSE-7.0 ftp://ftp.suse.com/pub/suse/i386/update/7.0/sgm1/sgmltool-1.0.9-301.i386.rpm 916953307d466d3bd8d26fb0655ce55a source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.0/zq1/sgmltool-1.0.9-301.src.rpm 5e11b85a494e1033ee2a83839cb296fe SuSE-6.4 ftp://ftp.suse.com/pub/suse/i386/update/6.4/sgm1/sgmltool-1.0.9-300.i386.rpm a489acc5c3dce4c44915e47b3ee64790 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/6.4/zq1/sgmltool-1.0.9-300.src.rpm efdb6b08988b689127600a954ebe2e2f SuSE-6.3 ftp://ftp.suse.com/pub/suse/i386/update/6.3/sgm1/sgmltool-1.0.9-300.i386.rpm 9c1e5da161b67248935cbc7f485dfd40 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/6.3/zq1/sgmltool-1.0.9-300.src.rpm a2deae294821e73ed24429636b20ed2a Sparc Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/sparc/update/7.1/sgm1/sgmltool-1.0.9-283.sparc.… b3e0ec269392fb3d77c37cc698f77d16 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.1/zq1/sgmltool-1.0.9-283.src.rpm eb80b6efe08f40139ec181fed7ccc832 SuSE-7.0 ftp://ftp.suse.com/pub/suse/sparc/update/7.0/sgm1/sgmltool-1.0.9-284.sparc.… 8312ac046de5df7a47008dba32f1a7e8 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.0/zq1/sgmltool-1.0.9-284.src.rpm a7e48214ae01f4f720240c1204120927 AXP Alpha Platform: SuSE-7.0 ftp://ftp.suse.com/pub/suse/axp/update/7.0/sgm1/sgmltool-1.0.9-283.alpha.rpm 06348dc4b669098d80bc16a8cc836123 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.0/zq1/sgmltool-1.0.9-283.src.rpm c7c7ff5507f7a510d615235323f9f636 SuSE-6.4 ftp://ftp.suse.com/pub/suse/axp/update/6.4/sgm1/sgmltool-1.0.9-281.alpha.rpm ee6bb4dd45c90ba716f0d825fba7bbca source rpm: ftp://ftp.suse.com/pub/suse/axp/update/6.4/zq1/sgmltool-1.0.9-281.src.rpm 44366d7edcace3448a606aff0c73026f SuSE-6.3 ftp://ftp.suse.com/pub/suse/axp/update/6.3/sgm1/sgmltool-1.0.9-281.alpha.rpm 2c2450e3dfdde9066269add9cfb0757b source rpm: ftp://ftp.suse.com/pub/suse/axp/update/6.3/zq1/sgmltool-1.0.9-281.src.rpm 66a9d60866a5ebbb2e0682a2056f2528 PPC Power PC Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/ppc/update/7.1/sgm1/sgmltool-1.0.9-216.ppc.rpm 01bda0ee0edfa1e1036d27b2bb3de352 source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.1/zq1/sgmltool-1.0.9-216.src.rpm 1c6668d3ccc1b27bb3d5a4f84b308323 SuSE-7.0 ftp://ftp.suse.com/pub/suse/ppc/update/7.0/sgm1/sgmltool-1.0.9-216.ppc.rpm e9b7161fe3a10624790ce65d9909165d source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.0/zq1/sgmltool-1.0.9-216.src.rpm 15b8204b9378f8e833e6bac263bbacdd SuSE-6.4 ftp://ftp.suse.com/pub/suse/ppc/update/6.4/sgm1/sgmltool-1.0.9-216.ppc.rpm 6af30c53d022866df5dd69ae053eeeea source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/6.4/zq1/sgmltool-1.0.9-216.src.rpm 35aa3ab2a86498c5e6ad145c0c7e378a ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - Marcus Meissner (Caldera) found a bug in KDE 2.1.*'s kdesu program which allows attackers to gather private information. This is due to insecure local filehandling by the kdesu program. Please update to the newest packages. - minicom format string vulnerabilities have been found in the minicom package. If /usr/bin/minicom is installed suid, the vulnerability may be exploited to gain elevated privileges. Please note that this is not the case in SuSE distributions. If you decided to make /usr/bin/minicom suid uucp or even suid root, please make sure that you grant access to the execution of minicom to trusted users only. - cfingerd The package has been found vulnerable to a remotely exploitable weakness. SuSE Linux distributions do not ship this version of fingerd. - webmin Insecure handling of temporary files has been found in webmin, a comprehensive administration webinterface. SuSE distributions do not contain the webmin package and therefore are not vulnerable to the found vulnerabilities by default. We urge administrators who use webmin to upgrade to the latest version of webmin available. - gnupg/gpg, openssl Several weaknesses have been found in gnupg/gpg that can reduce the strength of encrypted data. We will provide updates for the gnupg/gpg package. The updates are currently being tested. ______________________________________________________________________________ 3) standard appendix: SuSE runs two security mailing lists to which any interested party may subscribe: suse-security(a)suse.com - general/linux/SuSE security discussion. All SuSE security announcements are sent to this list. To subscribe, send an email to <suse-security-subscribe(a)suse.com>. suse-security-announce(a)suse.com - SuSE's announce-only mailing list. Only SuSE's security annoucements are sent to this list. To subscribe, send an email to <suse-security-announce-subscribe(a)suse.com>. For general information or the frequently asked questions (faq) send mail to: <suse-security-info(a)suse.com> or <suse-security-faq(a)suse.com> respectively. =============================================== SuSE's security contact is <security(a)suse.com>. =============================================== Regards, Sebastian Krahmer ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. SuSE GmbH makes no warranties of any kind whatsoever with respect to the information contained in this security advisory. Type Bits/KeyID Date User ID pub 2048/3D25D3D9 1999/03/06 SuSE Security Team <security(a)suse.de> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh 1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+ cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7 tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63 Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+ x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0 Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2 saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o L0oixF12Cg== =pIeS - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOvKmBHey5gA9JdPZAQFNrQf/WNKH2qdtejRaCkmkqO0h2zMSKrhWDmqA v0vhSI/iG+Ax+SXq2Jt7hhGbi8qNBGEGQI4Pm1gA66prJgDsh6azwqCCDU33Q8AK nQ0smS65VaFJsc5inSM/KIa33mpA82uwkihmTFUxrt0zh96Pqgbdu4ayr2BqlGCD G7QRQD79RFzJwMDlmrAZjAHslKe3RlXwXcyXfUgWZnkNW+Ehv6Pd1Zqj/EyIDHhg T6f5t5+QxCoIKiw1aVbW8UZ4Kpk0wMzfoU0A/INS8omEgDZFPxdm7woNDXYvlrfp l7MS1/fqt9LqFZOW+XGFvVJOrKhSbDPxQ96W8Oft6mAx8XhH5se3Mw== =WRNV -----END PGP SIGNATURE-----

1 0

IPSec on linux 2.4.4
by RoMaN SoFt / LLFB!! 04 May '01

04 May '01

Hi. I want to make an encrypted VPN and I'd like you to advice some free (linux) solutions. My 1st try was FreeSwan but it doesn't build on 2.4.4 kernel (tested with both freeswan latest versions: stable and today's snapshot). I'm having a look to other alternatives (listed in "Other approaches to VPNs for Linux" from freeswan doc). Just right now I'm going to have a look to CIPE. As usual I'd like to hear some words from you (which solution do you recommend and/or have tested for my kernel, ...). Greetings to the ml :) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** roman(a)madrid.com http://pagina.de/romansoft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4 5

New gnpg version. Will SuSE do an upgraded rpm?
by Paul Elliott 04 May '01

04 May '01

I have noted that the gnpg people have made a new release that fix several potential security problems. Will SuSE provide an upgraded RPM or should I get the tar file from the gnpg people?? Viel Spaß -- Paul Elliott 1(512)837-9345 1(512)837-1096 pelliott(a)io.com PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117

2 1

security-control.sh
by wolfgang tinhofer 04 May '01

04 May '01

greetings! a reboot this morning caused 5 D prozesses after the cron.daily/aaa_base_rotate_logs 3300 ? D 0:00 cp /var/log/messages /var/log/messages.o 11506 ? D 0:02 pico messages 17222 ? D 0:00 /usr/local/bin/logtail /var/log/messages 22112 ? D 0:00 tailf messages 30305 ? D 0:00 tail messages as this script worked for a long time and works for others, maybe someone could give me a hint, where to search for reasons for this strange behavior (not the script behavior) thanks wolfgang tinhofer

2 1

harden suse log
by Togan Muftuoglu 04 May '01

04 May '01

Hi, Hope this is not a FAQ but I have questions I did run harden_suse yes since this is a firewall/router box. Output from harden_suse v3.2 run on Fri May 4 09:07:42 EEST 2001 1) If this is a firewall router pc why disabling IP Forwarding I thought it was necessary Found /etc/rc.config, working on it ... Disabled IP Forwarding. 2) If ADSL is disabled how am I suppose to connect the Internet ? Disabled service ADSL. 3) Why disable IDS or issue a warning for a similiar? Warning: I'm leaving SCANLOGD enabled! Disabled service SNORT. 4) the only difference I see is use of cracklib whats the importance or benefit having it enabled ATTENTION: You have modified /etc/pam.d/sshd. Leaving it untouched... You can find my version in /etc/pam.d/sshd.SuSEconfig... -- Togan Muftuoglu

1 0

Re: [suse-security] kernel 2.4.2 and (new) IP MasQ configuration
by Harold ! 04 May '01

04 May '01

Ashley and other helpful list posters: Yes, please do. I appreciate your help in this matter. I am new to linux (less then 6 months serious exp) and want to keep my local lan secure. For you others: I apoligise if I intruded on your security discussions. I did NOT see a listserv for "idiots". I had no intentions of disturbing your "world" I only seek to learn what is (IMHO) a much better netowrking OS. In the short time I've used it, I'm inpressed. No, my real name does not appear in my emails sent. If ya really must know it's Bramton (NorDak Internet) >From: Ashley <ashleyg(a)dnai.com> >To: suse-security(a)suse.com >Subject: Re: [suse-security] kernel 2.4.2 and (new) IP MasQ configuration >Date: Thu, 3 May 2001 11:00:47 -0700 >MIME-Version: 1.0 >Received: from [202.58.118.3] by hotmail.com (3.2) with ESMTP id >MHotMailBCBAF530002040043251CA3A76030B230; Thu May 03 11:57:53 2001 >Received: (qmail 14470 invoked by alias); 3 May 2001 18:57:20 -0000 >Received: (qmail 14449 invoked from network); 3 May 2001 18:57:19 -0000 >From suse-security-return-7039-ambrosius1972 Thu May 03 11:58:44 2001 >Mailing-List: contact suse-security-help(a)suse.com; run by ezmlm >Precedence: bulk >X-No-Archive: yes >list-help: <mailto:suse-security-help@lists.suse.com> >list-unsubscribe: <mailto:suse-security-unsubscribe@lists.suse.com> >list-post: <mailto:suse-security@suse.com> >X-Mailinglist: suse-security >Delivered-To: mailing list suse-security(a)lists.suse.com >Message-ID: <20010503110047.E32593(a)rose.ashnet> >Mail-Followup-To: suse-security(a)suse.com >References: <F219hQdOgl4rhYQYx3G00012142(a)hotmail.com> >User-Agent: Mutt/1.3.12i >In-Reply-To: <F219hQdOgl4rhYQYx3G00012142(a)hotmail.com>; from >ambrosius1972(a)hotmail.com on Thu, May 03, 2001 at 02:36:19AM -0500 > >SuSEfirewall does not support iptables as shipped with 7.1, But it does >recognized if you are using the 2.2.18 or 2.4 kernel and does the >appropriate thing to setup ipchains. > >I was just playing with netfilter yesterday (and the day before that, >and the day before that... ). I'm masquerading a subnet behind a >dynamic ppp link. I hacked together a SuSEesque >init script and iptables rules script to setup up a iptables >firewall for a stock 7.1 system. I will send it to you if you are >interested. > >Some good sites for netfilter: >http://va.samba.org/netfilter/ >http://www.BoingWorld.com/workshops/linux/iptables-tutorial/ >http://ods.dyndns.org/ipt_flow.html >http://www.cs.princeton.edu/~jns/security/iptables/ >http://www.kalamazoolinux.org/presentations/20010417 > > >On Thu, May 03, 2001 at 02:36:19AM -0500, Harold ! wrote: > > Has anyone setup Connection sharing with kernel 2.4.2-4suse ?? > > I use a dialup connection and share it currently with IP Masq. Looking > > forward to migrating to netfilter's con sharing... > > > > I am currently running ManDrake 7.2 on my "server" box, and and to >replace > > it with SuSE (running the updated kernel. I know that IP Masq has been > > replaced with netfilter. My questions are as follows: > > > > 1. Is the neccessary utils bundled with SuSE 7.1 Pro (updated)? > > 2. Does the SuSEFirewall utility set this up? > > 3. If not Where can I find Idiot instructions? > > > > Thank you for your time. > > Ambrosius1972(a)hotmail.com > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com > > For additional commands, e-mail: suse-security-help(a)suse.com > > > >-- >-ashley > > One of these days I'm going to completely organize my life. > >--------------------------------------------------------------------- >To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com >For additional commands, e-mail: suse-security-help(a)suse.com > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

2 1

ashley's netfilter firewall scripts for SuSE7.1
by Ashley 04 May '01

04 May '01

Several people asked me for these scripts, so I'm posting them. Perhaps frittering my week on this was not a waste after all. But really I should be out looking for a job. Take a look. I'm very open to comments. My sh skills are rough. To make the init script part of the SuSE init system, I added a var in /etc/rc.config: START_IPTABLES_FW, I made links in /etc/init.d/rc#.d and a link for rciptables in /use/sbin: root@rose:~ >ls -l /usr/sbin/rciptables lrwxrwxrwx 1 root root 20 May 2 11:06 /usr/sbin/rciptables -> /etc/init.d/iptables root@rose:~ >ls -lR /etc/init.d/rc*.d/*iptables lrwxrwxrwx 1 root root 11 May 2 10:27 /etc/init.d/rc2.d/K17iptables -> ../iptables lrwxrwxrwx 1 root root 11 May 2 10:28 /etc/init.d/rc2.d/S04iptables -> ../iptables lrwxrwxrwx 1 root root 11 May 2 11:02 /etc/init.d/rc3.d/K17iptables -> ../iptables lrwxrwxrwx 1 root root 11 May 2 11:01 /etc/init.d/rc3.d/S04iptables -> ../iptables root@rose:~ >grep FW /etc/rc.config START_FW="no" START_IPTABLES_FW="yes" And definately have a look at James Stephen's iptables tutorial: http://www.cs.princeton.edu/~jns/security/iptables/ #!/bin/sh #set -x # # ================================================================== # # Iptables startup script # /etc/init.d/iptables # # For use on rose.ashnet SuSE7.1 # by ashley 4/30/2001 IPTABLES=/usr/sbin/iptables IPTABLES_CONFIG=/sbin/iptables.rules . /etc/rc.config # Determine the base and follow a runlevel link name. base=${0##*/} link=${base#*[SK][0-9][0-9]} # Force execution if not called by a runlevel directory. # I added a var in /etc/rc.config test $link = $base && START_FW=yes test "$START_IPTABLES_FW" = yes && START_FW="yes" test "$START_FW" = yes || exit 0 # Let's test that everything is in place echo "Ashley's iptables firewall: " return=$rc_done # check we have the iptables executable if [ ! -x $IPTABLES ]; then echo " Can't find $IPTABLES:$rc_failed" return=$rc_failed && exit 1 fi # check we have the right kernel version KERNELMAJ=`uname -r | sed -e 's,\..*,,'` KERNELMIN=`uname -r | sed -e 's,[^\.]*\.,,' -e 's,\..*,,'` if [ "$KERNELMAJ" -lt 2 ] || [ "$KERNELMAJ" -eq 2 -a "$KERNELMIN" -lt 3 ] ; then echo " No iptables support in kernel `uname -r`:$rc_failed" return=$rc_failed && exit 1 fi # Check if ipchains is already running if /sbin/lsmod 2>/dev/null |grep -q ipchains ; then echo " module ipchains already loaded:$rcfailed" return=$rc_failed && exit 1 fi # Check if iptables modules are already loaded iptables_loaded="no" if /sbin/lsmod 2>/dev/null |grep -q ip_tables ; then iptables_loaded="yes" fi # Looks good, let's get started case "$1" in start | restart) # We don't have the rules script? if [ ! -f $IPTABLES_CONFIG ]; then echo -n " Can't find firewall rules file $IPTABLES_CONFIG: " return=$rc_failed else echo -n " Loading rules: " $IPTABLES_CONFIG > /dev/null 2>&1 || return=$rcfailed fi echo -e "$return" ;; stop) if [ $iptables_loaded = yes ]; then echo " Flushing all chains, removing user defined chains and" echo " Resetting built-in chains to the default ACCEPT policy:" echo -n " The filter table: " $IPTABLES -P INPUT ACCEPT $IPTABLES -P OUTPUT ACCEPT $IPTABLES -P FORWARD ACCEPT $IPTABLES -F $IPTABLES -X $IPTABLES -Z echo -e "$rc_done" echo -n " The nat table: " $IPTABLES -t nat -P PREROUTING ACCEPT $IPTABLES -t nat -P OUTPUT ACCEPT $IPTABLES -t nat -P POSTROUTING ACCEPT $IPTABLES -t nat -F $IPTABLES -t nat -X $IPTABLES -t nat -Z echo -e "$rc_done" # Not in use #echo -n " The mangle table: " #$IPTABLES -t mangle -P PREROUTING ACCEPT #$IPTABLES -t mangle -P OUTPUT ACCEPT #$IPTABLES -t mangle -F #$IPTABLES -t mangle -X #$IPTABLES -t mangle -Z #echo -e "$rc_done" #echo -n " Stop forwarding and unload all the iptables modules: " #echo 0 > /proc/sys/net/ipv4/ip_forward #/sbin/rmmod `lsmod | awk '{print $1}' | grep '^ip'` #echo -e "$rc_done" else echo " No iptables modules loaded." fi ;; status) # I recommend piping this to `less` if [ $iptables_loaded = yes ]; then echo echo ' FILTER TABLE' echo $IPTABLES -t filter -L -v --line-numbers echo echo ' NAT TABLE' echo $IPTABLES -t nat -L -v --line-numbers echo #echo ' MANGLE TABLE' #echo #$IPTABLES -t mangle -L -v --line-numbers #echo else echo " No iptables modules loaded." fi ;; panic) if [ $iptables_loaded = yes ]; then echo " PANIC! Change all target policies to DROP: " echo -n " The filter table: " $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -F $IPTABLES -X $IPTABLES -Z echo -e "$rc_done" echo -n " The nat table: " $IPTABLES -t nat -P PREROUTING DROP $IPTABLES -t nat -P OUTPUT DROP $IPTABLES -t nat -P POSTROUTING DROP $IPTABLES -t nat -F $IPTABLES -t nat -X $IPTABLES -t nat -Z echo -e "$rc_done" # Not in use #echo -n " The mangle table: " #$IPTABLES -t mangle -P PREROUTING DROP #$IPTABLES -t mangle -P OUTPUT DROP #$IPTABLES -t mangle -F #$IPTABLES -t mangle -X #$IPTABLES -t mangle -Z #echo -e "$rc_done" echo -n " Stop forwarding and unload all the iptables modules: " echo 0 > /proc/sys/net/ipv4/ip_forward /sbin/rmmod `lsmod | awk '{print $1}' | grep '^ip'` echo -e "$rc_done" else echo " No iptables modules loaded." fi ;; *) echo "Usage: $0 {start|stop|restart|status|panic}" exit 1 esac # Inform the caller not only verbosely and set an exit status. test "$return" = "$rc_done" || exit 1 exit 0 #!/bin/bash ##============================================================ # Iptables firewall rules loading script # /sbin/iptables.rules # ##ag Adapted form the tutorial by James C. Stephens <jns(a)gfdl.noaa.gov> ##ag for use on rose.ashnet 4/30/2001 by ashley. ##ag My comments look like this ##ag # ##ag This is the K I S S version. ##ag I cut out James' wonderful comments for readablity. ##ag Look for full documentation at James' site: ##ag http://www.cs.princeton.edu/~jns/security/iptables/ IPTABLES=/usr/sbin/iptables MODPROBE=/sbin/modprobe ECHO=/bin/echo # Load appropriate modules. #$MODPROBE ip_tables #$MODPROBE ip_conntrack #$MODPROBE ip_conntrack_ftp ##ag The above calls aren't needed if the MASQ module is loaded; ##ag it brings them with it. $MODPROBE ipt_MASQUERADE # Flush rules $IPTABLES -F $IPTABLES -X $IPTABLES -Z $IPTABLES -t nat -F $IPTABLES -t nat -X $IPTABLES -t nat -Z # Default policy $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT DROP $IPTABLES -t nat -P PREROUTING ACCEPT $IPTABLES -t nat -P OUTPUT ACCEPT $IPTABLES -t nat -P POSTROUTING ACCEPT ## =========================================================== ## Some definitions: ##ag ashnet locals INT_NET="192.168.0.0/24" INT_IPADDR="198.168.0.1" INT_IFACE="eth0" EXT_IFACE="ppp0" INT_MAIL="192.168.0.2" ##ag my isp stuff NAMESERVER_1="207.172.3.10" NAMESERVER_2="207.172.3.11" POP3_HOST="208.59.199.22" SMTP_MAIL_RELAY= ##ag general P_PORTS="0:1023" UP_PORTS="1024:65535" TR_SRC_PORTS="32769:65535" TR_DEST_PORTS="33434:33523" ## ============================================================ ## Kernel flags #echo kernel flags $ECHO "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts $ECHO "0" > /proc/sys/net/ipv4/conf/all/accept_source_route $ECHO "0" > /proc/sys/net/ipv4/conf/all/accept_redirects $ECHO "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ##ag Don't I need to do this _after_ my ppp0 interface comes up? #for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do # $ECHO "1" > ${interface} #done ##ag Instead I'll just do the 'all' version $ECHO "1" > /proc/sys/net/ipv4/conf/all/rp_filter $ECHO "1" > /proc/sys/net/ipv4/conf/all/log_martians $ECHO "1" > /proc/sys/net/ipv4/ip_forward ## ============================================================ # RULES #=================================================================== ## The FORWARD chain #echo The FORWARD chain # I'm masquerading everything from my internal lan $IPTABLES -t nat -A POSTROUTING -o $EXT_IFACE -j MASQUERADE #$IPTABLES -A FORWARD -i $INT_IFACE -m state --state NEW,RELATED,ESTABLISHED -j LOG --log-prefix "ACCEPT FORWARD --state NEW,E,R:" $IPTABLES -A FORWARD -i $INT_IFACE -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT #$IPTABLES -A FORWARD -i $EXT_IFACE -m state --state RELATED,ESTABLISHED -j LOG --log-prefix "ACCEPT FORWARD --state E,R:" $IPTABLES -A FORWARD -i $EXT_IFACE -m state --state RELATED,ESTABLISHED -j ACCEPT # Log the losers $IPTABLES -A FORWARD -i $EXT_IFACE -m limit --limit 6/h --limit-burst 5 -j LOG --log-prefix "DROP FORWARD IN-PPP0: " $IPTABLES -A FORWARD -i $EXT_IFACE -j DROP #============================================================================== # Local Processes on Rose #echo Local Processes on Rose ## LOOPBACK #echo LOOPBACK $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A OUTPUT -o lo -j ACCEPT ## SYN-FLOODING PROTECTION #echo SYN-FLOODING PROTECTION ##ag Probably I don't need this, as I have no servers running. $IPTABLES -N syn-flood $IPTABLES -A INPUT -p tcp --syn -j syn-flood $IPTABLES -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN $IPTABLES -A syn-flood -j DROP ## Make sure NEW tcp connections are SYN packets $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP ## FRAGMENTS #echo FRAGMENTS # Log fragments just to see if we get any, and deny them too. $IPTABLES -A INPUT -f -j LOG --log-prefix "IPTABLES FRAGMENTS: " $IPTABLES -A INPUT -f -j DROP ## SPOOFING ##ag I cut out this section ##ag I'll rely on the kernel flags ## DNS #echo DNS # Allow UDP packets in for DNS client from nameservers. No tcp. $IPTABLES -A INPUT -i $EXT_IFACE -p udp -s $NAMESERVER_1 --sport 53 -m state --state ESTABLISHED -j ACCEPT $IPTABLES -A INPUT -i $EXT_IFACE -p udp -s $NAMESERVER_2 --sport 53 -m state --state ESTABLISHED -j ACCEPT # Allow UDP packets to DNS servers from client. $IPTABLES -A OUTPUT -o $EXT_IFACE -p udp -d $NAMESERVER_1 --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT $IPTABLES -A OUTPUT -o $EXT_IFACE -p udp -d $NAMESERVER_2 --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT ## SSH #echo SSH # Allow ssh outbound all interfaces. $IPTABLES -A INPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT $IPTABLES -A OUTPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT ##ag Allow connections from internal lan (and log while testing) #$IPTABLES -A INPUT -i $INT_IFACE -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j LOG --log-prefix "ACCEPT ssh from internal --state NEW,E,R: " $IPTABLES -A INPUT -i $INT_IFACE -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT #$IPTABLES -A OUTPUT -o $INT_IFACE -p tcp --sport 22 -m state --state ESTABLISHED -j LOG --log-prefix "ACCEPT ssh from internal --state E,R: " $IPTABLES -A OUTPUT -o $INT_IFACE -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT ## WWW ##ag I'll include this when I get my squid proxy up #echo WWW # Allow www outbound to 80. #$IPTABLES -A INPUT -i $EXT_IFACE -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT #$IPTABLES -A OUTPUT -o $EXT_IFACE -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT # Allow www outbound to 443. #$IPTABLES -A INPUT -i $EXT_IFACE -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT #$IPTABLES -A OUTPUT -o $EXT_IFACE -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT ## FTP ##ag For future ftp proxy #echo FTP # Allow ftp outbound. #$IPTABLES -A INPUT -i $EXT_IFACE -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT #$IPTABLES -A OUTPUT -o $EXT_IFACE -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT # 1) Active ftp. #$IPTABLES -A OUTPUT -o $EXT_IFACE -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT # 2) Passive ftp. #$IPTABLES -A INPUT -i $EXT_IFACE -p tcp --sport $UP_PORTS --dport $UP_PORTS -m state --state ESTABLISHED -j ACCEPT #$IPTABLES -A OUTPUT -o $EXT_IFACE -p tcp --sport $UP_PORTS --dport $UP_PORTS -m state --state ESTABLISHED,RELATED -j ACCEPT ## SMTP #echo SMTP ##ag Allow smtp outbound to internal lan only. $IPTABLES -A INPUT -i $INT_IFACE -p tcp --sport 25 -m state --state ESTABLISHED -j ACCEPT $IPTABLES -A OUTPUT -o $INT_IFACE -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT ## TRACEROUTE #echo TRACEROUTE # Outgoing traceroute to internet. $IPTABLES -A OUTPUT -o $EXT_IFACE -p udp --sport $TR_SRC_PORTS --dport $TR_DEST_PORTS -m state --state NEW -j ACCEPT ## ICMP #echo ICMP ##ag This is where netfilter really shines. It is sooo much easier! ##ag rose can ping either interface and accepts pings from internal $IPTABLES -A INPUT -i $EXT_IFACE -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -i $INT_IFACE -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -o $EXT_IFACE -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -o $INT_IFACE -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT ## LOGGING #echo LOGGING ##ag Rate limit the logging # Any udp not already allowed is logged and then dropped. $IPTABLES -A INPUT -i $EXT_IFACE -m limit --limit 6/h --limit-burst 5 -p udp -j LOG --log-prefix "DROP UDP-IN: " $IPTABLES -A INPUT -i $EXT_IFACE -p udp -j DROP $IPTABLES -A OUTPUT -o $EXT_IFACE -m limit --limit 6/h --limit-burst 5 -p udp -j LOG --log-prefix "DROP UDP-OUT: " $IPTABLES -A OUTPUT -o $EXT_IFACE -p udp -j DROP # Any icmp not already allowed is logged and then dropped. $IPTABLES -A INPUT -i $EXT_IFACE -m limit --limit 6/h --limit-burst 5 -p icmp -j LOG --log-prefix "DROP ICMP-IN: " $IPTABLES -A INPUT -i $EXT_IFACE -p icmp -j DROP $IPTABLES -A OUTPUT -o $EXT_IFACE -m limit --limit 6/h --limit-burst 5 -p icmp -j LOG --log-prefix "DROP ICMP-OUT: " $IPTABLES -A OUTPUT -o $EXT_IFACE -p icmp -j DROP # Any tcp not already allowed is logged and then dropped. $IPTABLES -A INPUT -i $EXT_IFACE -m limit --limit 6/h --limit-burst 5 -p tcp -j LOG --log-prefix "DROP TCP-IN: " $IPTABLES -A INPUT -i $EXT_IFACE -p tcp -j DROP $IPTABLES -A OUTPUT -o $EXT_IFACE -m limit --limit 6/h --limit-burst 5 -p tcp -j LOG --log-prefix "DROP TCP-OUT: " $IPTABLES -A OUTPUT -o $EXT_IFACE -p tcp -j DROP # Anything else not already allowed is logged and then dropped. $IPTABLES -A INPUT -i $EXT_IFACE -m limit --limit 6/h --limit-burst 5 -j LOG --log-prefix "DROP PROTOCOL-X-IN: " $IPTABLES -A INPUT -i $EXT_IFACE -j DROP $IPTABLES -A OUTPUT -o $EXT_IFACE -m limit --limit 6/h --limit-burst 5 -j LOG --log-prefix "DROP PROTOCOL-X-OUT: " $IPTABLES -A OUTPUT -o $EXT_IFACE -j DROP # THE END # ================================================================== -- -ashley One of these days I'm going to completely organize my life.

1 0

Re: [suse-security] How to prevent home-phoning ?
by christian.burri＠synecta.ch 03 May '01

03 May '01

I suggest that you use iptables and snort on the SuSE box and then, additionally go and install something like norton personal firewall or something alike on the internal computers (if they 're win32 as I suppose). The SuSE box divides your LAN from the internet, whereas the (host based) personal firewalls allow you to see which process uses what sockets and connects to where, plus you can allow/disallow individual applications. A drawback however is, that the win32 personal firewalls wont most likely not log to a centralized syslog, plus you will have to configure (and eventually maintain) them all manually. A different approach is presented by NFR (www.nfr.com) They do offer a complete solution for intrusion detection that works with agents, which, once deployed on each host within the LAN, log to the central NFR log repository (afaik). But this is like, costly ;-( hope that helps & cheers Chris Burri jun. Systems- & Network Engineer Synecta Informatik AG 9000 St. Gallen Switzerland .-. /v\ L I N U X // \\ >Phear the Penguin< /( )\ ^^-^^ |--------+-----------------------> | | Andreas | | | Fiesser | | | <fiesser(a)gmx.| | | net> | | | | | | 03.05.01 | | | 18:49 | | | | |--------+-----------------------> >---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Security SuSE <suse-security(a)suse.com> | | cc: | | Subject: [suse-security] How to prevent home-phoning ? | >---------------------------------------------------------------------------------------------------------------------------------------------| I've got a SuSE 7.0 box sitting between my home LAN and my DSL ISP. Among other services this host acts as a firewall for the LAN. The clients connect by masquerading or JunkBuster (running on the router) to the internet. Theoretically the FW should keep all the bad boys/girls out by stealthing my ports. How can I make sure that only those apps get out where I say it's OK ? I figure that this is no trivial task but maybe there are solutions to do this. Primarily I use Netscape to browse the Net and do my e-mails. Then I need a few programs to ftp outside. I guess it's a bit tricky to know if any other software tries to establish connections ? Sorry, if this sounds a bit naive but I'm wondering if my firewall thingy is actually any good in the days of spyware thrown at us users "to improve the knowledge about the needs of dear customers". --------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com For additional commands, e-mail: suse-security-help(a)suse.com

1 0

How to prevent home-phoning ?
by Andreas Fiesser 03 May '01

03 May '01

I've got a SuSE 7.0 box sitting between my home LAN and my DSL ISP. Among other services this host acts as a firewall for the LAN. The clients connect by masquerading or JunkBuster (running on the router) to the internet. Theoretically the FW should keep all the bad boys/girls out by stealthing my ports. How can I make sure that only those apps get out where I say it's OK ? I figure that this is no trivial task but maybe there are solutions to do this. Primarily I use Netscape to browse the Net and do my e-mails. Then I need a few programs to ftp outside. I guess it's a bit tricky to know if any other software tries to establish connections ? Sorry, if this sounds a bit naive but I'm wondering if my firewall thingy is actually any good in the days of spyware thrown at us users "to improve the knowledge about the needs of dear customers".

2 1

kernel 2.4.2 and (new) IP MasQ configuration
by Harold ! 03 May '01

03 May '01

Has anyone setup Connection sharing with kernel 2.4.2-4suse ?? I use a dialup connection and share it currently with IP Masq. Looking forward to migrating to netfilter's con sharing... I am currently running ManDrake 7.2 on my "server" box, and and to replace it with SuSE (running the updated kernel. I know that IP Masq has been replaced with netfilter. My questions are as follows: 1. Is the neccessary utils bundled with SuSE 7.1 Pro (updated)? 2. Does the SuSEFirewall utility set this up? 3. If not Where can I find Idiot instructions? Thank you for your time. Ambrosius1972(a)hotmail.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

3 2