From: Jim Graves (jtg@xxxxxxxxxx)
Date: Fri Jun 15 2001 - 12:46:31 GMT-3
I should just stop pretending to be intelligent today. I made yet another
sloppy error in my reply. I didn't notice that Gordon said "SYN or ACK"
and I said "ACK/RST."
The "established" bit checks the ACK or RST bits (not SYN). That, in
theory, matches anything after the very first packet in the TCP
handshake. The SYN bit is irrelevant to the "established" keyword. As you
said, the second step in the TCP handshake would match
"established." Matching SYN or ACK would match pretty much anything up to
the connection teardown.
Unless, of course, I'm overlooking something simple again. :)
At 08:23 AM 6/15/2001 -0700, Jon Carmichael wrote:
>The sloppy mental shorthand is understandable, --but your answer made me
>think about whether I really knew all the bits, --I think there are
>four, --but there might be five. The four I remember are SYN, ACK, FIN and
>RST. I believe the three way handshake is..
>
>SYN --> (ring)
>SYN-ACK <-- (hello)
>ACK --> (hi, -this is Fred)
>
>I believe the "established" keyword means that SYN-ACK is allowed thru the
>access-list, where SYN by itself is not, (you can say hello when I ring your
>phone, --but you can't ring mine, --or perhaps don't call me I'll call you).
>
>Altho it would be easy to alter a packet to send SYN-ACKs thru an
>access-list (hellos), there would not be anybody on the other side to
>remember calling you, so nobody would respond.
>
>JONC
>
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>Jim Graves
>Sent: Friday, June 15, 2001 7:39 AM
>To: Gordon W Skinner; ccielab@groupstudy.com
>Subject: Re: What is the fuction of the established keyword in
>Access-list?
>
>
>Sorry. That's sloppy mental shorthand on my part. There is no
>"established" bit, just the ACK/RST you mentioned. It's still a trivial
>matter to set one or both of these bits to match the "established" keyword.
>
>At 03:25 PM 6/15/2001 +0100, Gordon W Skinner wrote:
>
> >I thought the established keyword matches only TCP packets with the SYN or
>ACK
> >bit set, not aware of an established bit.
> >
> >Regards
> >
> >Gordon
> >
> >
> >
> >
> >jtg@lucent.com on 06/15/2001 02:36:33 PM
> >
> >Please respond to jtg@lucent.com
> >
> >To: bravojun@hanmail.net, ccielab@groupstudy.com
> >cc: (bcc: Gordon W Skinner)
> >Subject: Re: What is the fuction of the established keyword in
>Access-list?
> >
> >
> >
> >
> >The "established" keyword simply matches the "established" bit in the TCP
> >header. That's a bit that's set if a packet claims to be a response in an
> >existing conversation. In theory, every packet after the initial TCP
> >handshake will have the "established" bit set.
> >
> >It's usually used as a shortcut when specific access lists are too painful
> >or bothersome. For example, you'll sometimes see this sline thrown into an
> >access-list for inbound traffic:
> >
> >access-list 110 permit tcp any any established
> >
> >What that's supposed to do is allow through any reply traffic for existing
> >connections.
> >
> >But I don't like using "established", and here's why. As I mentioned, all
> >it does is match a bit in the TCP header. TCP headers are trivial to
> >forge. If I'm Henry Hacker, I can just as easily set the "established" bit
> >on every packet I send. If your access list depends on "established" to
> >permit or deny access, it's going to let that forged packet right on
> >through. Not good.
> >
> >FWIW, reflexive access lists are a much better way to do what the
> >"established" bit is usually used for. For more on reflexive access lists,
> >see CCO at
> ><
> >http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secu
>r_c/scprt3/screflex.htm
> > >.
> >
> >As for your particular issue - it should work the same whether you have
> >"established" set or not. I presume that 100.1.1.1 is the ftp server, and
> >10.1.1.1 is the client (i.e., 10.1.1.1 ftps to 100.1.1.1)? Your issue is
> >probably a mask/IP problem in your access lists. The destination address
> >in each case is 10.1.1.1 with a wildcard mask of 0.0.0.255. You probably
> >mean 10.1.1.0 0.0.0.255. I don't think anything will match 10.1.1.1
> >0.0.0.255.
> >
> >At 12:11 PM 6/15/2001 +0900, bravo wrote:
> > >Hello guy!
> > >
> > >Could you explain why the ftp is not work well?
> > >
> > >int se 0
> > > ip addr 100.1.1.254 255.255.255.0
> > > ip access-group 100 in
> > >int e 0
> > > ip addr 10.1.1.254 255.255.255.0
> > >
> > >access-list 100 permit tcp host 100.1.1.1 eq ftp 10.1.1.1 0.0.0.255
> > >established
> > >access-list 100 permit tcp host 100.1.1.1 eq ftp-data 10.1.1.1 0.0.0.255
> > >established
> > >access-list 100 deny ip any any
> > >
> > >==================================================
> > >?l8. @NEM3], Daum
> > >Fr;} >24B 9+7a E-mail AV<R GQ8^@O3]
> > >Av18CL GQ1[ 0K;v<-:q=: Daum FIREBALL
> > >http://www.daum.net
> > >**Please read:http://www.groupstudy.com/list/posting.html
> >---------------------------
> >Jim Graves
> >CCIE #7524, CISSP, MCSE
> >Network Systems Consultant
> >Lucent Worldwide Services
> >Alpha Pager: 1-800-467-1467
> >**Please read:http://www.groupstudy.com/list/posting.html
> >This communication is for informational purposes only. It is not intended
>as
> >an offer or solicitation for the purchase or sale of any financial
>instrument
> >or as an official confirmation of any transaction. All market prices, data
> >and other information are not warranted as to completeness or accuracy and
> >are subject to change without notice. Any comments or statements made
>herein
> >do not necessarily reflect those of J.P. Morgan Chase & Co., its
> >subsidiaries and affiliates.
>
>---------------------------
>Jim Graves
>CCIE #7524, CISSP, MCSE
>Network Systems Consultant
>Lucent Worldwide Services
>Alpha Pager: 1-800-467-1467
>**Please read:http://www.groupstudy.com/list/posting.html
---------------------------
Jim Graves
CCIE #7524, CISSP, MCSE
Network Systems Consultant
Lucent Worldwide Services
Alpha Pager: 1-800-467-1467
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:24 GMT-3