could someone translate these rules inot plain english

could someone translate these rules inot plain english

[Technical]

-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

Re: could someone translate these rules inot plain english

[Ray Leach]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

On Thu, 2004-01-22 at 08:10, Technical wrote:
> -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> 
Add (-A) to chain RH-Firewall-1-INPUT match (-m) on state (--state)
ESTABLISHED or RELATED jump (-j) to ACCEPT (basically accept this
packet).

> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
Add (-A) to chain RH-Firewall-1-INPUT jump (-j) to REJECT and reject
with specific options (--reject-with icmp-host-prohibited)

The chains above are user defined chains.

-- 
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: could someone translate these rules inot plain english

[Alex Satrapa]

Technical wrote:
> -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

For this chain (presumably packets inbound to the network), accept any 
packets that are part of established TCP connections (ie: a SYN packet 
for the connection has gone out from the network), or related to UDP 
packets that have gone out through the firewall.

> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

Otherwise, reject the packet by sending back an ICMP message telling the 
remote host that communication with its intended target is 
administratively prohibited.


HTH
Alex Satrapa

Re: could someone translate these rules inot plain english

[Arnt Karlsen]

On Thu, 22 Jan 2004 17:34:28 +1100, 
Alex Satrapa <alex@lintelsys.com.au> wrote in message 
<400F6EF4.2060608@lintelsys.com.au>:

>  Technical wrote:
>  > -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j
>  > ACCEPT
> 
>  For this chain (presumably packets inbound to the network), accept
>  any packets that are part of established TCP connections (ie: a SYN
>  packet for the connection has gone out from the network), or related
>  to UDP packets that have gone out through the firewall.
> 
> > -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
> 
> Otherwise, reject the packet by sending back an ICMP message telling
> the remote host that communication with its intended target is 
> administratively prohibited.

.."Otherwise, " is not part of this last rule.  "Otherwise, " could
understood as a context where these 2 rules appear as shown. 

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: could someone translate these rules inot plain english

[Technical]

> Technical wrote:
>> -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> For this chain (presumably packets inbound to the network), accept any
> packets that are part of established TCP connections (ie: a SYN packet
> for the connection has gone out from the network), or related to UDP
> packets that have gone out through the firewall.
>
>> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
>
> Otherwise, reject the packet by sending back an ICMP message telling the
> remote host that communication with its intended target is
> administratively prohibited.
>
>
> HTH
> Alex Satrapa
>
>


If the default is that iptables to reject all packets that cannot not be
deall with any of the previous rules, why would somemone use the last
rule??  am I missing something??

RE: could someone translate these rules inot plain english

[bmcdowell]

I often do it just to be thorough...  I'm only human after all.


Bob

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Technical
Sent: Thursday, January 22, 2004 4:48 AM
To: netfilter@lists.netfilter.org
Subject: Re: could someone translate these rules inot plain english


> Technical wrote:
>> -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> For this chain (presumably packets inbound to the network), accept any
> packets that are part of established TCP connections (ie: a SYN packet
> for the connection has gone out from the network), or related to UDP
> packets that have gone out through the firewall.
>
>> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
>
> Otherwise, reject the packet by sending back an ICMP message telling the
> remote host that communication with its intended target is
> administratively prohibited.
>
>
> HTH
> Alex Satrapa
>
>


If the default is that iptables to reject all packets that cannot not be
deall with any of the previous rules, why would somemone use the last
rule??  am I missing something??

Re: could someone translate these rules inot plain english

[Unknown, Alistair Tonner]

On January 22, 2004 05:48 am, Technical wrote:
> > Technical wrote:
> >> -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> >
> > For this chain (presumably packets inbound to the network), accept any
> > packets that are part of established TCP connections (ie: a SYN packet
> > for the connection has gone out from the network), or related to UDP
> > packets that have gone out through the firewall.
> >
> >> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
> >
> > Otherwise, reject the packet by sending back an ICMP message telling the
> > remote host that communication with its intended target is
> > administratively prohibited.
> >
> >
> > HTH
> > Alex Satrapa
>
> If the default is that iptables to reject all packets that cannot not be
> deall with any of the previous rules, why would somemone use the last
> rule??  am I missing something??

	The reply with host-prohibited is used to send  a different ICMP response 
	than would normally be sent (policy DROP doesn't reply) ... I believe also that the core tables in a 
	RH firewall are *not* set DROP -- they do that in the user chains they 
	create. .... but thats hearsay so I don't count it 100% accurate.



	Alistair.

Re: could someone translate these rules inot plain english

[Arnt Karlsen]

On Thu, 22 Jan 2004 05:48:09 -0500 (EST), 
"Technical" <technical@sojourn.dyndns.org> wrote in message 
<34137.66.65.52.125.1074768489.squirrel@sojourn.dyndns.org>:

> > Technical wrote:
> >> -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j
> >ACCEPT
> >
> > For this chain (presumably packets inbound to the network), accept
> > any packets that are part of established TCP connections (ie: a SYN
> > packet for the connection has gone out from the network), or related
> > to UDP packets that have gone out through the firewall.
> >
> >> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
> >
> > Otherwise, reject the packet by sending back an ICMP message telling
> > the remote host that communication with its intended target is
> > administratively prohibited.
> 
> 
> If the default is that iptables to reject all packets that cannot not
> be deall with any of the previous rules, why would somemone use the
> last rule??  am I missing something??

..polite authentication scheme?  To hide my box, I have played with the
less polite  -j REJECT --reject-with icmp-host-unreachable and --state
ESTABLISHED,RELATED -j ACCEPT and have people try to
ping/scan/see me.  ;-)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: could someone translate these rules inot plain english

[Alex Satrapa]

Technical wrote:
> If the default is that iptables to reject all packets that cannot not be
> deall with any of the previous rules, why would somemone use the last
> rule??  am I missing something??

It explicitly tells the remote computer that they're not *allowed* to 
communicate with that host - as opposed to just dropping the packets 
(pretending you're a black hole), or rejecting the packets with "host 
unreachable" or "port unreachable".  These two options imply that the 
remote host is *allowed* to try connecting, but there's just nothing there.

The administrator at the other end would likely act different ways in 
these circumstances. Upon noticing that there are many "host 
unreachable" messages coming through, the administrator would take the, 
"leave it alone and try again" stance - since the assumption would be 
that something is broken. "host prohibited" messages explicitly state to 
the administrator that everything is working just as it should be, and 
that communication with that host is simply not allowed.