From Travis.R.Waldher at boeing.com Thu May 8 15:52:15 2008 From: Travis.R.Waldher at boeing.com (Waldher, Travis R) Date: Thu, 8 May 2008 08:52:15 -0700 Subject: Help an IPTABLES neophyte please Message-ID: I've got a machine acting as a portal between a public network and a private network. Right now, all you can do is ssh in to the box from the public side, and then do as you please on the private side. You cannot ssh or form any other connection that wasn't initiated by a client on the public side of the machine. Think of it as a roach motel. Well, I need to be able to pull information from an LDAP server that is on the public network. How do I setup my firewall so that it will first allow outbound traffic on port 389 (any others?) and second forward any requests it receives from other machines on the private network on. Thanks, Travis -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricks at nerd.com Thu May 8 17:08:01 2008 From: ricks at nerd.com (Rick Stevens) Date: Thu, 08 May 2008 10:08:01 -0700 Subject: Help an IPTABLES neophyte please In-Reply-To: References: Message-ID: <48233371.6020501@nerd.com> Waldher, Travis R wrote: > I?ve got a machine acting as a portal between a public network and a > private network. Right now, all you can do is ssh in to the box from > the public side, and then do as you please on the private side. You > cannot ssh or form any other connection that wasn?t initiated by a > client on the public side of the machine. Think of it as a roach motel. > > > > Well, I need to be able to pull information from an LDAP server that is > on the public network. > > > > How do I setup my firewall so that it will first allow outbound traffic > on port 389 (any others?) and second forward any requests it receives > from other machines on the private network on. Hey, Travis! Long time, no speak! If this were a normal machine (one not acting as a router), the way you worded the above sounds like the only incoming connections allowed are for ssh (TCP port 22), so you probably have a rule such as: -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT in your ruleset. Assuming that the OUTPUT chain has a default policy of "ACCEPT", you should also have rules such as: -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT before the final "-j REJECT" (or "-j DROP") in the input chain. That should allow ANY TCP traffic as long as it was INITIATED from the local machine. If the machine is a router, then we'd probably have to get into specifying the different NICs in the rules (by use of the "-i" parameter). Could you post your current ruleset so we can get a grip on what you have set up? It may be a really simple fix or a simpler ruleset may work. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer rps2 at nerd.com - - Hosting Consulting, Inc. - - - - NEWS FLASH! Intelligence of mankind decreasing! Details at... - - uh, when, uh, the little hand is, uh, on the... Aw, NUTS! - ---------------------------------------------------------------------- From Travis.R.Waldher at boeing.com Fri May 9 14:39:11 2008 From: Travis.R.Waldher at boeing.com (Waldher, Travis R) Date: Fri, 9 May 2008 07:39:11 -0700 Subject: Help an IPTABLES neophyte please In-Reply-To: <48233371.6020501@nerd.com> References: <48233371.6020501@nerd.com> Message-ID: > -----Original Message----- > From: Rick Stevens [mailto:ricks at nerd.com] > Sent: Thursday, May 08, 2008 10:08 AM > To: Getting started with Red Hat Linux > Subject: Re: Help an IPTABLES neophyte please > > Waldher, Travis R wrote: > > I've got a machine acting as a portal between a public network and a > > private network. Right now, all you can do is ssh in to the box from > > the public side, and then do as you please on the private side. You > > cannot ssh or form any other connection that wasn't initiated by a > > client on the public side of the machine. Think of it as a roach > motel. > > > > > > > > Well, I need to be able to pull information from an LDAP server that > is > > on the public network. > > > > > > > > How do I setup my firewall so that it will first allow outbound > traffic > > on port 389 (any others?) and second forward any requests it receives > > from other machines on the private network on. > > Hey, Travis! Long time, no speak! > > If this were a normal machine (one not acting as a router), the way you > worded the above sounds like the only incoming connections allowed are > for ssh (TCP port 22), so you probably have a rule such as: > > -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT > > in your ruleset. Assuming that the OUTPUT chain has a default policy > of "ACCEPT", you should also have rules such as: > > -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > > before the final "-j REJECT" (or "-j DROP") in the input chain. That > should allow ANY TCP traffic as long as it was INITIATED from the > local machine. > > If the machine is a router, then we'd probably have to get into > specifying the different NICs in the rules (by use of the "-i" > parameter). > > Could you post your current ruleset so we can get a grip on what you > have set up? It may be a really simple fix or a simpler ruleset may > work. > > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer rps2 at nerd.com - > - Hosting Consulting, Inc. - > - - > - NEWS FLASH! Intelligence of mankind decreasing! Details at... - > - uh, when, uh, the little hand is, uh, on the... Aw, NUTS! - > ---------------------------------------------------------------------- Dang, change jobs? Nerd.com now? LOL Here's the script I use to set the firewall. IP's have been modified to protect the innocent #Clean out the IP Tables iptables -F iptables -X #setup default filter policy iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP #Allow unlimited traffic on loopback iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #Allow incoming ssh only iptables -A INPUT -p tcp -s 0/0 -d 162.254.180.165 --sport 513:65535 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp -s 162.254.180.165 -d 0/0 --sport 22 --dport 513:65535 -m state --state ESTABLISHED -j ACCEPT # Allow pings iptables -A INPUT -p icmp --icmp-type 0 -s 0/0 -d 162.254.180.165 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p icmp --icmp-type 8 -s 0/0 -d 162.254.180.165 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p icmp --icmp-type 0 -s 162.254.180.165 -d 0/0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p icmp --icmp-type 8 -s 162.254.180.165 -d 0/0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT #Allow FTP #iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT #iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT #Drop all other traffic iptables -A INPUT -i eth0 -j DROP iptables -A OUTPUT -o eth0 -j DROP #Allow the private network to be chatty iptables -A INPUT -i eth1 -s 192.168.1.0/255.255.255.0 -j ACCEPT iptables -A OUTPUT -o eth1 -s 192.168.1.0/255.255.255.0 -j ACCEPT iptables -A INPUT -i eth2 -s 192.168.2.0/255.255.255.128 -j ACCEPT iptables -A OUTPUT -o eth2 -s 192.168.2.0/255.255.255.128 -j ACCEPT #Allow certain pings #iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT #iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT #iptables -A INPUT -p icmp --icmp-type 11 -j ACCEPT #iptables -A INPUT -p icmp --icmp-type 8 -m limit --limit 1/second -j ACCEPT Basically I first tell it to drop all traffic, default deny. Then I start opening things back up. This machine is not acting like a router right now. I do need to forward LDAP traffic to the outside now. I want this machine to be wide open on the private network, but very closed off on the public side. Allowing inbound SSH only, no outbound. Allowing outbound LDAP requests, but no inbound. Thanks, Travis From ricks at nerd.com Fri May 9 16:54:21 2008 From: ricks at nerd.com (Rick Stevens) Date: Fri, 09 May 2008 09:54:21 -0700 Subject: Help an IPTABLES neophyte please In-Reply-To: References: <48233371.6020501@nerd.com> Message-ID: <482481BD.3010505@nerd.com> Waldher, Travis R wrote: >> -----Original Message----- >> From: Rick Stevens [mailto:ricks at nerd.com] >> Sent: Thursday, May 08, 2008 10:08 AM >> To: Getting started with Red Hat Linux >> Subject: Re: Help an IPTABLES neophyte please >> >> Waldher, Travis R wrote: >>> I've got a machine acting as a portal between a public network and a >>> private network. Right now, all you can do is ssh in to the box > from >>> the public side, and then do as you please on the private side. You >>> cannot ssh or form any other connection that wasn't initiated by a >>> client on the public side of the machine. Think of it as a roach >> motel. >>> >>> >>> Well, I need to be able to pull information from an LDAP server that >> is >>> on the public network. >>> >>> >>> >>> How do I setup my firewall so that it will first allow outbound >> traffic >>> on port 389 (any others?) and second forward any requests it > receives >>> from other machines on the private network on. >> Hey, Travis! Long time, no speak! >> >> If this were a normal machine (one not acting as a router), the way > you >> worded the above sounds like the only incoming connections allowed are >> for ssh (TCP port 22), so you probably have a rule such as: >> >> -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT >> >> in your ruleset. Assuming that the OUTPUT chain has a default policy >> of "ACCEPT", you should also have rules such as: >> >> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT >> >> before the final "-j REJECT" (or "-j DROP") in the input chain. That >> should allow ANY TCP traffic as long as it was INITIATED from the >> local machine. >> >> If the machine is a router, then we'd probably have to get into >> specifying the different NICs in the rules (by use of the "-i" >> parameter). >> >> Could you post your current ruleset so we can get a grip on what you >> have set up? It may be a really simple fix or a simpler ruleset may >> work. >> >> ---------------------------------------------------------------------- >> - Rick Stevens, Systems Engineer rps2 at nerd.com - >> - Hosting Consulting, Inc. - >> - - >> - NEWS FLASH! Intelligence of mankind decreasing! Details at... - >> - uh, when, uh, the little hand is, uh, on the... Aw, NUTS! - >> ---------------------------------------------------------------------- > > Dang, change jobs? Nerd.com now? LOL Yup. Nine years after co-founding the company, I simply couldn't take the political crap and gross mismanagement by the executives (except for one guy). I've watched the stock value drop over 75% because of their mismanagement and I couldn't bear to watch my child be murdered by those bastards any longer. One of the other former founders had started this up and needed my help. It wasn't an easy choice, but I'm a MUCH happier camper now! > Here's the script I use to set the firewall. IP's have been modified to > protect the innocent Yes, Sgt. Friday. :-) > #Clean out the IP Tables > iptables -F > iptables -X > > #setup default filter policy > iptables -P INPUT DROP > iptables -P OUTPUT DROP > iptables -P FORWARD DROP > > #Allow unlimited traffic on loopback > iptables -A INPUT -i lo -j ACCEPT > iptables -A OUTPUT -o lo -j ACCEPT > > #Allow incoming ssh only > iptables -A INPUT -p tcp -s 0/0 -d 162.254.180.165 --sport 513:65535 > --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT > iptables -A OUTPUT -p tcp -s 162.254.180.165 -d 0/0 --sport 22 --dport > 513:65535 -m state --state ESTABLISHED -j ACCEPT > > # Allow pings > iptables -A INPUT -p icmp --icmp-type 0 -s 0/0 -d 162.254.180.165 -m > state --state NEW,ESTABLISHED,RELATED -j ACCEPT > iptables -A INPUT -p icmp --icmp-type 8 -s 0/0 -d 162.254.180.165 -m > state --state NEW,ESTABLISHED,RELATED -j ACCEPT > iptables -A OUTPUT -p icmp --icmp-type 0 -s 162.254.180.165 -d 0/0 -m > state --state NEW,ESTABLISHED,RELATED -j ACCEPT > iptables -A OUTPUT -p icmp --icmp-type 8 -s 162.254.180.165 -d 0/0 -m > state --state NEW,ESTABLISHED,RELATED -j ACCEPT > > #Allow FTP > #iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j > ACCEPT > #iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED > -j ACCEPT > > #Drop all other traffic > iptables -A INPUT -i eth0 -j DROP > iptables -A OUTPUT -o eth0 -j DROP > > #Allow the private network to be chatty > iptables -A INPUT -i eth1 -s 192.168.1.0/255.255.255.0 -j ACCEPT > iptables -A OUTPUT -o eth1 -s 192.168.1.0/255.255.255.0 -j ACCEPT > iptables -A INPUT -i eth2 -s 192.168.2.0/255.255.255.128 -j ACCEPT > iptables -A OUTPUT -o eth2 -s 192.168.2.0/255.255.255.128 -j ACCEPT > > #Allow certain pings > #iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT > #iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT > #iptables -A INPUT -p icmp --icmp-type 11 -j ACCEPT > #iptables -A INPUT -p icmp --icmp-type 8 -m limit --limit 1/second -j > ACCEPT > > Basically I first tell it to drop all traffic, default deny. Then I > start opening things back up. This machine is not acting like a router > right now. I do need to forward LDAP traffic to the outside now. > > I want this machine to be wide open on the private network, but very > closed off on the public side. Allowing inbound SSH only, no outbound. > Allowing outbound LDAP requests, but no inbound. You didn't say which NICs are on the external and which are on the internal (and I see 3 NICS in your ruleset). However, assuming eth0 is the external and eth1 and eth2 are the internal, then # Permit incoming and outgoing LDAP:// traffic on eth0... iptables -A INPUT -i eth0 -s 0/0 -p tcp --dport 389 -m state --state \ ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -o eth0 -s 0/0-p tcp --sport 389 -m state --state \ NEW -j ACCEPT # Permit incoming and outgoing LDAPS:// traffic on eth0... iptables -A INPUT -i eth1 -s 0/0 -p tcp -sport 636 -m state --state \ ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -o eth0 -s 0/0-p tcp --sport 636 -m state --state \ NEW -j ACCEPT Should be a good basis to start with. Since you have SSH open to the outside world (btw, the first non-privileged port is 1024, not 513), you might want to add some rules to the SSH stuff to prevent brute-force password guessing attacks. Here's a set that blocks a given IP if they try to ssh more than once every 3 minutes. Its enough to block the script kiddies out there: # This rejects ssh attempts more than twice in 180 seconds... # First, mark attempts as part of the "sshattack" group... -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set # Optional: Include this line if you want to log these attacks... #-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck \ --seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: " # Finally, reject the connection if more than one attempt is made in 180 # seconds... -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck \ --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset Obviously, change the "--hitcount 2" and "--seconds 180" to whatever you want. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer rps2 at nerd.com - - Hosting Consulting, Inc. - - - - Blech! ACKth! Ooop! -- Bill the Cat (Outland) - ---------------------------------------------------------------------- From joliver at john-oliver.net Fri May 9 19:39:34 2008 From: joliver at john-oliver.net (John Oliver) Date: Fri, 9 May 2008 12:39:34 -0700 Subject: Kickstart install can't see DVD Message-ID: <20080509193934.GA7328@ns.sdsitehosting.net> I'm trying to create a bootable DVD with RHEL4u5 and my kickstart script to perform an unattended install. My image boots and sees the ks.cfg file just fine. However, it quickly says: The Red Hat Enterprise Linux CD was not found in any of your CDROM drives. Please insert the Red Hat Enterprise Linux CD and press OK to retry. Googling gives me a bunch of responses that say "You didn't copy the .discinfo file". But I did! And it's contents are identical to a working image: 1177148299.639333 Red Hat Enterprise Linux 4 i386 1,2,3,4,5 RedHat/base RedHat/RPMS RedHat/pixmaps Switching to vt3 shows: * starting to STEP_URL * trying to mount CD device hdc * trying to mount CD device hdc vt4 shows: <7>libata version 2.00 loaded. <3>FAT: bogus number of reserved sectors <6>VFS: Can't find a valid FAT filesystem on dev hdc. <4>VFS: Can't find ext2 filesystem on dev hdc. -- *********************************************************************** * John Oliver http://www.john-oliver.net/ * * * *********************************************************************** From Travis.R.Waldher at boeing.com Fri May 9 21:00:45 2008 From: Travis.R.Waldher at boeing.com (Waldher, Travis R) Date: Fri, 9 May 2008 14:00:45 -0700 Subject: Help an IPTABLES neophyte please In-Reply-To: <482481BD.3010505@nerd.com> References: <48233371.6020501@nerd.com> <482481BD.3010505@nerd.com> Message-ID: > -----Original Message----- > From: Rick Stevens [mailto:ricks at nerd.com] > Sent: Friday, May 09, 2008 9:54 AM > To: Getting started with Red Hat Linux > Subject: Re: Help an IPTABLES neophyte please > > You didn't say which NICs are on the external and which are on the > internal (and I see 3 NICS in your ruleset). However, assuming eth0 is > the external and eth1 and eth2 are the internal, then > > # Permit incoming and outgoing LDAP:// traffic on eth0... > iptables -A INPUT -i eth0 -s 0/0 -p tcp --dport 389 -m state --state \ > ESTABLISHED,RELATED -j ACCEPT > iptables -A OUTPUT -o eth0 -s 0/0-p tcp --sport 389 -m state --state \ > NEW -j ACCEPT > # Permit incoming and outgoing LDAPS:// traffic on eth0... > iptables -A INPUT -i eth1 -s 0/0 -p tcp -sport 636 -m state --state \ > ESTABLISHED,RELATED -j ACCEPT > iptables -A OUTPUT -o eth0 -s 0/0-p tcp --sport 636 -m state --state \ > NEW -j ACCEPT > > Should be a good basis to start with. > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer rps2 at nerd.com - > - Hosting Consulting, Inc. - > - - > - Blech! ACKth! Ooop! -- Bill the Cat (Outland) - > ---------------------------------------------------------------------- Okay, I finally got that working. #Allow outbound LDAP ## Permit incoming and outgoing LDAP:// traffic on eth0... iptables -A INPUT -i eth0 -s 0/0 -p tcp --sport 389 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -o eth0 -s 0/0 -p tcp --sport 1024:65535 --dport 389 -m state --state NEW,ESTABLISHED -j ACCEPT There was no talking on 636, so I was going to leave that closed off unless there is a good reason to open it. Next step, forwarding LDAP requests over eth1 or eth2 going out eth0. From pwc at u.washington.edu Fri May 9 21:48:34 2008 From: pwc at u.washington.edu (Paul Campbell) Date: Fri, 09 May 2008 14:48:34 -0700 Subject: Help an IPTABLES neophyte please In-Reply-To: <20080509160044.BF52E61927E@hormel.redhat.com> References: <20080509160044.BF52E61927E@hormel.redhat.com> Message-ID: <4824C6B2.2000008@u.washington.edu> Question for clarification on REDHAT iptables vs iptables It seems that there is something that translates an "abbreviated" iptables command-line and processes it. WHY ? The cmd line differences seem trivial. eg. > iptables -A INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -i lo -j ACCEPT Where is this process for "abbreviation/translation/processing" documented? I can read the iptables docs but I can not find docs or rationale on this. Using the normal iptables, allows you to imbed sh commands in the stream but I can't do that because of the "translation". I have looked at the iptables package and the securitylevel but I can't find it. I don't want to disable SELINUX but I would like to look at disabling this translation. Here is the beginning of the REDHAT iptables RedHat installs at start-up: # Firewall configuration written by system-config-securitylevel # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT //////////////////////////////////////////// Here is a sample of your code: > Dang, change jobs? Nerd.com now? LOL > > Here's the script I use to set the firewall. IP's have been modified to > protect the innocent > > #Clean out the IP Tables > iptables -F > iptables -X > > #setup default filter policy > iptables -P INPUT DROP > iptables -P OUTPUT DROP > iptables -P FORWARD DROP > > #Allow unlimited traffic on loopback > iptables -A INPUT -i lo -j ACCEPT > iptables -A OUTPUT -o lo -j ACCEPT From ricks at nerd.com Fri May 9 23:01:01 2008 From: ricks at nerd.com (Rick Stevens) Date: Fri, 09 May 2008 16:01:01 -0700 Subject: Help an IPTABLES neophyte please In-Reply-To: <4824C6B2.2000008@u.washington.edu> References: <20080509160044.BF52E61927E@hormel.redhat.com> <4824C6B2.2000008@u.washington.edu> Message-ID: <4824D7AD.9020800@nerd.com> Paul Campbell wrote: > Question for clarification on > REDHAT iptables vs iptables > > It seems that there is something that translates an > "abbreviated" iptables command-line and processes it. > > WHY ? The cmd line differences seem trivial. > eg. > > iptables -A INPUT -i lo -j ACCEPT > -A RH-Firewall-1-INPUT -i lo -j ACCEPT Ok, you're getting confused. The first one you have is the actual command used to ADD a rule to the iptables ruleset. It consists of the command "iptables" followed by the appropriate parameters: "-A INPUT" means "append to end of the INPUT chain". Note that "-I" would try to insert the rule between two existing rules in the chain. E.g. "-I INPUT 12" would mean to insert THIS rule BEFORE rule 12 in the INPUT chain. "-i lo" means "this refers to packets coming IN on the lo (loopback) interface "-j ACCEPT" means to jump to the ACCEPT result, accepting the packet The second line is an example of what's kept in /etc/sysconfig/iptables. It consists of the same command parameters, but not the "iptables" command itself. When the system boots, it runs a command: /sbin/iptables-restore /path/to/some/file which would save the EXISTING iptables rules to the file "/path/to/some/file" in exactly the same format as found in /etc/sysconfig/iptables. Most people find it easier to edit the /etc/sysconfig/iptables file to insert rules between existing rules, then running service iptables restart to make them effective instead of running "iptables -L -n --line-numbers" to get appropriate rule numbers and then using "iptables -I" commands to insert the rules between existing rules. Also note that the system used to do /sbin/iptables-save >/etc/sysconfig/iptables when it shut down to save any rules inserted via the "iptables" command directly so they'd reinserted at the next boot. I'm not sure that happens anymore, but it used to. Now, as to the "-A RH-Firewall-1-INPUT" versus the "-A INPUT" bit, you can create separate rulesets and name them however you want. system-config-securitylevel (which is run by the system installer) creates a separate INPUT ruleset, called "RH-Firewall-1-INPUT" and sticks its rules in it. Any rules set up by system-config-securitylevel (at any time, not just at system installation) get stuffed into that ruleset. The first rule that gets inserted into /etc/sysconfig/iptables by the system installer is -A INPUT -j RH-Firewall-1-INPUT which causes the INPUT chain to unconditionally jump to the "RH-Firewall-1-INPUT" ruleset. In my opinion, it's kinda silly. I suppose you could insert rules for the INPUT chain BEFORE the rule above that effect what you want to do, and leave the Red Hat ruleset alone. I generally find Red Hat's rules too simplistic for my uses, so I generally chuck their entire ruleset and just use my own in the normal "INPUT" chain. If I find I need to do something extra-special, then I may create a separate ruleset, but I virtually NEVER jump to it unconditionally...I usually have some criteria in the rule that has to be met to jump to my special set. Hope that explains it. :-) ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer rps2 at nerd.com - - Hosting Consulting, Inc. - - - - Memory is the second thing to go, but I can't remember the first! - ---------------------------------------------------------------------- From karlp at ourldsfamily.com Mon May 12 16:33:21 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Mon, 12 May 2008 10:33:21 -0600 (MDT) Subject: Help an IPTABLES neophyte please In-Reply-To: <4824D7AD.9020800@nerd.com> References: <20080509160044.BF52E61927E@hormel.redhat.com> <4824C6B2.2000008@u.washington.edu> <4824D7AD.9020800@nerd.com> Message-ID: <60971.207.173.117.242.1210610001.squirrel@webmail.ourldsfamily.com> On Fri, May 9, 2008 5:01 pm, Rick Stevens wrote: > Paul Campbell wrote: >> Question for clarification on >> REDHAT iptables vs iptables >> >> It seems that there is something that translates an >> "abbreviated" iptables command-line and processes it. >> >> WHY ? The cmd line differences seem trivial. >> eg. >> > iptables -A INPUT -i lo -j ACCEPT >> -A RH-Firewall-1-INPUT -i lo -j ACCEPT > > Ok, you're getting confused. The first one you have is the actual > command used to ADD a rule to the iptables ruleset. It consists of the > command "iptables" followed by the appropriate parameters: > > "-A INPUT" means "append to end of the INPUT chain". Note that > "-I" would try to insert the rule between two existing rules > in the chain. E.g. "-I INPUT 12" would mean to insert THIS > rule BEFORE rule 12 in the INPUT chain. > > "-i lo" means "this refers to packets coming IN on the lo > (loopback) interface > > "-j ACCEPT" means to jump to the ACCEPT result, accepting the > packet > > The second line is an example of what's kept in /etc/sysconfig/iptables. > It consists of the same command parameters, but not the "iptables" > command itself. When the system boots, it runs a command: > > /sbin/iptables-restore > which reads the contents of /etc/sysconfig/iptables and essentially > feeds each line, one at a time, to the iptables command. Conversely, > you can run > > /sbin/iptables-save >/path/to/some/file > > which would save the EXISTING iptables rules to the file > "/path/to/some/file" in exactly the same format as found in > /etc/sysconfig/iptables. > > Most people find it easier to edit the /etc/sysconfig/iptables file to > insert rules between existing rules, then running > > service iptables restart > > to make them effective instead of running "iptables -L -n > --line-numbers" to get appropriate rule numbers and then using "iptables > -I" commands to insert the rules between existing rules. > > Also note that the system used to do > > /sbin/iptables-save >/etc/sysconfig/iptables > > when it shut down to save any rules inserted via the "iptables" command > directly so they'd reinserted at the next boot. I'm not sure that > happens anymore, but it used to. Check /etc/sysconfig/iptable-config and you'll find a parameter that allows saving on stop that defaults to no: IPTABLES_SAVE_ON_STOP="no" HTH Karl > > Now, as to the "-A RH-Firewall-1-INPUT" versus the "-A INPUT" bit, > you can create separate rulesets and name them however you want. > > system-config-securitylevel (which is run by the system installer) > creates a separate INPUT ruleset, called "RH-Firewall-1-INPUT" and > sticks its rules in it. Any rules set up by system-config-securitylevel > (at any time, not just at system installation) get stuffed into that > ruleset. > > The first rule that gets inserted into /etc/sysconfig/iptables by the > system installer is > > -A INPUT -j RH-Firewall-1-INPUT > > which causes the INPUT chain to unconditionally jump to the > "RH-Firewall-1-INPUT" ruleset. In my opinion, it's kinda silly. I > suppose you could insert rules for the INPUT chain BEFORE the rule above > that effect what you want to do, and leave the Red Hat ruleset alone. > > I generally find Red Hat's rules too simplistic for my uses, so I > generally chuck their entire ruleset and just use my own in the normal > "INPUT" chain. If I find I need to do something extra-special, then I > may create a separate ruleset, but I virtually NEVER jump to it > unconditionally...I usually have some criteria in the rule that has to > be met to jump to my special set. > > Hope that explains it. :-) > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer rps2 at nerd.com - > - Hosting Consulting, Inc. - > - - > - Memory is the second thing to go, but I can't remember the first! - > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > -- Karl L. Pearson karlp at ourldsfamily.com http://consulting.ourldsfamily.com --- My Thoughts on Terrorism In America right after 9/11/2001: http://www.ourldsfamily.com/wtc.shtml --- The world is a dangerous place to live... not because of the people who are evil, but because of the people who don't do anything about it. - Albert Einstein --- "To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it." --- From JDunn at sefas.com Wed May 14 12:26:32 2008 From: JDunn at sefas.com (John Dunn) Date: Wed, 14 May 2008 13:26:32 +0100 Subject: Unable to ping RHEL 5 server over VPN Message-ID: <2F802216565E44489600A03F763219A83E960E@mia.SEFASBRISTOL> I am unable to ping my RHEL 5 server over VPN I can ping it on the LAN and I can ping our other Unix servers over the VPN. Is there some configuration I have missed on the RHEL 5 boxes? John Dunn Product Consultant Sefas Innovation Limited Direct Dial + 44 (0) 117 373 6122 www.sefas.com Sefas Innovation Ltd, CityPoint, Temple Gate, Bristol BS1 6PL, UK. Tel: +44 (0) 117 373 6114 Fax: +44 (0) 117 373 6115 Sefas Innovation Limited. Registered No: 3769761 England. Registered Office: One New Street, Wells, Somerset, BA5 2LA, United Kingdom. VAT Registration No: GB 741 5377 32 Unless stated to be non-confidential, this email and any attachments are private and confidential and are for the addressee only. Sefas monitors e-mails to ensure its systems operate effectively and to minimize the risk of viruses. Whilst Sefas has taken reasonable steps to scan this email, it does not accept liability for any virus that may be contained in it. Internet communications are not 100% secure and as such Sefas is not responsible for their abuse by 3rd parties, nor for any alteration or corruption in transmission. -------------- next part -------------- An HTML attachment was scrubbed... URL: From obed.listas at gmail.com Wed May 14 16:05:52 2008 From: obed.listas at gmail.com (obed) Date: Wed, 14 May 2008 11:05:52 -0500 Subject: Unable to ping RHEL 5 server over VPN In-Reply-To: <2F802216565E44489600A03F763219A83E960E@mia.SEFASBRISTOL> References: <2F802216565E44489600A03F763219A83E960E@mia.SEFASBRISTOL> Message-ID: Could you explain us how is you network schema, the IP addresses, the tunnel IP's 2008/5/14 John Dunn : > I am unable to ping my RHEL 5 server over VPN > > I can ping it on the LAN and I can ping our other Unix servers over the VPN. > > Is there some configuration I have missed on the RHEL 5 boxes? > > > > John Dunn > > Product Consultant > > Sefas Innovation Limited > > Direct Dial + 44 (0) 117 373 6122 > > www.sefas.com > > Sefas Innovation Ltd, CityPoint, Temple Gate, Bristol BS1 6PL, UK. Tel: +44 > (0) 117 373 6114 Fax: +44 (0) 117 373 6115 > > Sefas Innovation Limited. Registered No: 3769761 England. Registered > Office: One New Street, Wells, Somerset, BA5 2LA, United Kingdom. VAT > Registration No: GB 741 5377 32 > > Unless stated to be non-confidential, this email and any attachments are > private and confidential and are for the addressee only. Sefas monitors > e-mails to ensure its systems operate effectively and to minimize the risk > of viruses. Whilst Sefas has taken reasonable steps to scan this email, it > does not accept liability for any virus that may be contained in it. > > Internet communications are not 100% secure and as such Sefas is not > responsible for their abuse by 3rd parties, nor for any alteration or > corruption in transmission. > > > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > -- obed.org.mx From mccarty at yournetguard.com Thu May 15 12:37:32 2008 From: mccarty at yournetguard.com (McCarty Ronald) Date: Thu, 15 May 2008 07:37:32 -0500 Subject: Redhat Installation for Cold Disaster Recovery Systems Message-ID: <031F3E49-6C0D-452D-B7AC-037D52D650D7@yournetguard.com> Howdy, Just wondering if anyone has worked their way through the licensing aspects of having disaster recovery systems turned off, but ready to fire up in case of a system or site failure? On the technical side: How do you activate the system to get the latest updates, then disable it until it is either needed or annual testing? Where is the current eula aspects on licenses that are not being used? The idea here is the customer does not want to buy twice as many licenses for hardware that is on shelves off site until needed. --ron Ronald McCarty mccarty at YourNetGuard.com Your Net Guard LLC 3526 Lakeview Pkwy Ste B#164 Rowlett, TX 75088 http://www.YourNetGuard.com/ 214-257-8629 -------------- next part -------------- An HTML attachment was scrubbed... URL: