Help an IPTABLES neophyte please
 

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







_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@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@redhat.com
Subject: unsubscribe

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@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! -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@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@redhat.com
Subject: unsubscribe

Help an IPTABLES neophyte please
 

> -----Original Message-----
> From: Rick Stevens [mailto:ricks@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@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

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@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@redhat.com
Subject: unsubscribe

Help an IPTABLES neophyte please
 

Waldher, Travis R wrote:

-----Original Message-----
From: Rick Stevens [mailto:ricks@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@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@nerd.com -
- Hosting Consulting, Inc. -
- -
- Blech! ACKth! Ooop! -- Bill the Cat (Outland) -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@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@redhat.com
Subject: unsubscribe

Help an IPTABLES neophyte please
 

> -----Original Message-----
> From: Rick Stevens [mailto:ricks@nerd.com]
> Sent: Friday, May 09, 2008 9:54 AM
> To: Getting started with Red Hat Linux
> Subject: Re: Help an IPTABLES neophyte please

<snip>

>
> 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@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.



_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@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@redhat.com
Subject: unsubscribe

Help an IPTABLES neophyte please
 

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

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@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@redhat.com
Subject: unsubscribe

Help an IPTABLES neophyte please
 

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 </etc/sysconfig/iptables

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.

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@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@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@redhat.com
Subject: unsubscribe

Help an IPTABLES neophyte please
 

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 </etc/sysconfig/iptables
>
> 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@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@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@redhat.com
> Subject: unsubscribe
>


--
Karl L. Pearson
karlp@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."
---

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@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@redhat.com
Subject: unsubscribe