May 2001 - openSUSE Security - openSUSE Mailing Lists

Please help for FreesWan VPN script setup on SuSe 7.1
by Aboubacar Dramé 09 May '01

09 May '01

Hi ! I am trying to configure a script to securise a Linux FreesWan on SuSE 7.1 Professional edition , I use the sample script below (writed for the Red Hat distribution), I use the script to replace the /etc/rc.config.d/firewall.rc.config, but it does not work, what changes can I do on the script to adapt it for the SuSe 7.1 version to make the ipchains work ? Thanks for your help. Aboubacar Dramé Montreal, Quebec, Canada #!/bin/sh # # ---------------------------------------------------------------------------- # Last modified by Gerhard Mourani: 10-10-2000 # ---------------------------------------------------------------------------- # Copyright (C) 1997, 1998, 1999 Robert L. Ziegler # # Permission to use, copy, modify, and distribute this software and its # documentation for educational, research, private and non-profit purposes, # without fee, and without a written agreement is hereby granted. # This software is provided as an example and basis for individual firewall # development. This software is provided without warranty. # # Any material furnished by Robert L. Ziegler is furnished on an # "as is" basis. He makes no warranties of any kind, either expressed # or implied as to any matter including, but not limited to, warranty # of fitness for a particular purpose, exclusivity or results obtained # from use of the material. # ---------------------------------------------------------------------------- # # Invoked from /etc/rc.d/init.d/firewall. # chkconfig: - 60 95 # description: Starts and stops the IPCHAINS Firewall \ # used to provide Firewall network services. # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. if [ ${NETWORKING} = "no" ] then exit 0 fi if [ ! -x /sbin/ipchains ]; then exit 0 fi # See how we were called. case "$1" in start) echo -n "Starting Firewalling Services: " # Some definitions for easy maintenance. # ---------------------------------------------------------------------------- # EDIT THESE TO SUIT YOUR SYSTEM AND ISP. EXTERNAL_INTERFACE="eth0" # Internet connected interface # LOCAL_INTERFACE_1="eth1" # Internal LAN interface # LOOPBACK_INTERFACE="lo" # Your local naming convention IPADDR="my.ip.address" # Your IP address # LOCALNET_1="192.168.1.0/24" # Whatever private range you use IPSECSG="my.ipsecsg.address" # Space separated list of remote VPN gateways FREESWANVI="ipsec0" # Space separated list of virtual interfaces ANYWHERE="any/0" # Match any IP address # NAMESERVER_1="my.name.server.1" # Everyone must have at least one # NAMESERVER_2="my.name.server.2" # Your secondary name server # ------------------------------------------------------------------ # OUTGOING TRACEROUTE # ------------------- #ipchains -A output -i $EXTERNAL_INTERFACE -p udp \ # -s $IPADDR $TRACEROUTE_SRC_PORTS \ #-d $ANYWHERE $TRACEROUTE_DEST_PORTS -j ACCEPT # ---------------------------------------------------------------------------- # Unlimited traffic within the local network. # All internal machines have access to the firewall machine. # ipchains -A input -i $LOCAL_INTERFACE_1 -s $LOCALNET_1 -j ACCEPT # ipchains -A output -i $LOCAL_INTERFACE_1 -d $LOCALNET_1 -j ACCEPT # ---------------------------------------------------------------------------- # FreeS/WAN IPSec VPN # ------------------- # If you are using the FreeSWAN IPSec VPN, you will need to fill in the # addresses of the gateways in the IPSECSG and the virtual interfaces for # FreeS/Wan IPSEC in the FREESWANVI parameters. Look at the beginning of # this firewall script rules file to set the parameters. # IPSECSG is a Space separated list of remote gateways. FREESWANVI is a # Space separated list of virtual interfaces for FreeS/Wan IPSEC # implementation. Only include those that are actually used. # Allow IPSEC protocol from remote gateways on external interface # IPSEC uses three main types of packet: # IKE uses the UDP protocol and port 500, # ESP use the protocol number 50, and # AH use the protocol number 51 ipchains -A input -i $EXTERNAL_INTERFACE -p udp \ -s $IPSECSG -j ACCEPT ipchains -A output -i $EXTERNAL_INTERFACE -p udp \ -d $IPSECSG -j ACCEPT ipchains -A input -i $EXTERNAL_INTERFACE -p 50 \ -s $IPSECSG -j ACCEPT ipchains -A output -i $EXTERNAL_INTERFACE -p 50 \ -d $IPSECSG -j ACCEPT ipchains -A input -i $EXTERNAL_INTERFACE -p 51 \ -s $IPSECSG -j ACCEPT ipchains -A output -i $EXTERNAL_INTERFACE -p 51 \ -d $IPSECSG -j ACCEPT # Allow all traffic to FreeS/WAN Virtual Interface ipchains -A input -i $FREESWANVI \ -s $ANYWHERE \ -d $ANYWHERE -j ACCEPT ipchains -A output -i $FREESWANVI \ -s $ANYWHERE \ -d $ANYWHERE -j ACCEPT # Forward anything from the FreeS/WAN virtual interface IPSEC tunnel ipchains -A forward -i $FREESWANVI \ -s $ANYWHERE \ -d $ANYWHERE -j ACCEPT # Disable IP spoofing protection to allow IPSEC to work properly echo 0 > /proc/sys/net/ipv4/conf/ipsec0/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter # ---------------------------------------------------------------------------- ;; stop) echo -n "Shutting Firewalling Services: " # Remove all existing rules belonging to this filter ipchains -F # Delete all user-defined chain to this filter ipchains -X # Reset the default policy of the filter to accept. ipchains -P input ACCEPT ipchains -P output ACCEPT ipchains -P forward ACCEPT ;; status) status firewall ;; restart|reload) $0 stop $0 start ;; *) echo "Usage: firewall {start|stop|status|restart|reload}" exit 1 esac exit 0

1 0

Re: [suse-security] Kernel security
by christian.burri＠synecta.ch 09 May '01

09 May '01

mmmhkay let me add my babbling =) IMHO, one of the best solutions to have *good* security on a box is someone watching its logfiles and maybe have running a network traffic analyzer. I do have a box on the internet, and I do have a few users on it (basically, I give away shells, sometimes, for those poor ppl that are stuck with a dialup connection), and there were few attempts to root my box. Neverthless, every single try to root the box was defended either by myself watching the culprit, or by my co-admin. If you have a trustworthy coadmin that can keep an eye on your box while you cannot (work, school, whatever..), that might be worth more then spending 100'000 bucks on the latest stateful firewall (and another 30k to train your network engineers on it). Also, I found it very crucial to be careful about *who is granted shell access. If you dont run many services on your box, surely no portmapper or suchlike, then your chance of getting rooted has already reduced by an order of magnitude. Infact, almost all the root attempts I had came from local users. The very first time one of my boxen got rooted was because I like gave out an account. It took them dudes like 45 seconds to gain root (rootcron.sh on a SuSE 6.2....h0h0h0!). But like, because I was using the elite "w" command, I was instantly able to spot that there were two logins from different IPs to the account I gave out, so a lill "shutdown", followed by a reinstall from trusted media solved my problem ;-) So, as for a conclusion: 1) get a trustworthy co-admin 2) be careful about who gets shell accounts on your box NB: I like to thank Marc from SuSE (I think it was him, correct me if Im wrong =) for auditing the SuSE version of wu-ftpd! Cheers Chris Burri jun. Systems- & Network Engineer Synecta Informatik AG Zwinglistrasse 3 9000 St. Gallen Switzerland .-. /v\ L I N U X // \\ >Phear the Penguin< /( )\ ^^-^^

1 0

Re: [suse-security] Message Log Question
by Andreas Bätz 09 May '01

09 May '01

On Wednesday 09 May 2001 12:20, Markus Gaugusch wrote: > > IMHO a packet filter like ipchains can only decide what to do with a > > packet by looking at this very packet. So if you get a packet without > > SYN Flag set from somewhere to , say, port 61500, how can ipchains > > know if it's a response to a masqueraded request or a response to a > > request from al local app using this port ? > > It is not decided by ipchains, but the kernel. The kernel knows the > masqueraded connections, and can differ between local and masqueraded > connections therefore. Yes, but given the following scenario: 1) A client behind a firewall is masqeraded, and it uses a program that connects to a server outside (masqueraded by the firewall). The reply from the server goes to the port which is used by the firewall kernel for masquerading (say 61500). In my input chain on the firewall I have to ACCEPT packets to this port. 2) On the firewall there is a program which tries to connect to the internet, but should not be allowed to (for whatever reason, may be a backdoor or trojan or what or even just for added security). Now, say this program uses the local port 61500 for outbound connection (assuming it is not used by the masquerading this time). If I want to block responses to this program, on the input chain I have to DENY packets to this port. So, in my firewall script I have no possibility to decide if an incoming packet to a port in this range is to be allowed or not. If I have seperate port ranges for local and masqueraded connection, this decision can be based on the port range. OTOH, I don't know if a program cannot be told to use a port outside the local portrange. I suppose it can, in which case this discussion would be somewhat useless. Andreas Baetz ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been scanned for the presence of computer viruses. **********************************************************************

2 1

RE: [suse-security] SuSEfirewall2 & port forwarding
by Greisberger Christophe 09 May '01

09 May '01

Hum, thanks. It would have been easier to tell me to read the IP-Masquerade-HOWTO :-) But that's not what I wanted. This documentation is for ipportfw & ipchains, not netfilter... and I wanted to know if it's possible to use the SuSEfirewall2 to achieve this... Again, thank you anyway. Christophe

1 0

Kernel 2.4.0 to 2.4.4 update Doku?
by Mueller, Thomas 09 May '01

09 May '01

Hi list, hope anyone can help a newbie like me updating my Kernel 2.4.0 under SuSE Linux 7.1 to 2.4.4 and compiling it? Or is there any documentation out there on the net where I can help myself? Any help, tipps and hints are appreciatet Thanx in Advance Tom

1 0

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