From: Brad McConnell (mo@xxxxxxxxxxxxx)
Date: Mon Jun 18 2001 - 01:50:09 GMT-3
No such thing -- It's checking against the 'ack' bit. Since a set
acknowledge bit would mean the packet can't be the beginning of the
conversation, it's assumed that the session has already been established.
Might want to see if passive ftp is being utilized, as that flips who begins
the ftp-data connection establishment.
-Brad McConnell.
----- Original Message -----
From: "Andrew R" <arousch@home.com>
To: <ccielab@groupstudy.com>
Sent: Sunday, June 17, 2001 5:55 PM
Subject: Re: What is the fuction of the established keyword in Access-list?
> The 'established' bit? Has RFC 793 been obsoleted by a new TCP rfc that
> has added an 'established' field to the header? Might want to check the
> RFC again.
>
>
> At 08:36 AM 6/15/01 -0500, Jim Graves wrote:
> >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/sec
ur_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
> **Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:25 GMT-3