Hi,
Yes these are all valid answers to solve the problem. But... Just so that
you know. The IOS FFS with CBAC allows the inspection of outgoing sessions
(here telnet) and allows the incoming session in, even with a "deny all" on
the inbound ports. So that you don't have a static access-list to allow the
session in. CBAC opens dynamic session tunnels, that close with session
completion. Even with the one session started, an external user still can
not connect in.
http://www.cisco.com/warp/public/778/security/firewall/fire_ds.htm
Just in case you're wondering, no I am not a Cisco employee - but have
already had experience with CBAC and it is a great tool.
:) Heather
-----Original Message-----
From: Jeremy Tinkler [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 03, 1999 11:01 AM
To: '[EMAIL PROTECTED]'
Subject: RE: One-way telnet
Many thanks to all who replied to my query - Robert Bonomi, Paul
Beltrani, Robert Molnar, Laris Benkis, Chuck Jou, Paul D. Robertson,
Kenneth Durazzo, Paul Krumviede, Akatosh, Kelly Hair and especially
Colin Campbell whose excellent solution I attach below. Problem solved
- thanks all.
> -----Original Message-----
> From: Colin Campbell [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, February 02, 1999 11:26 PM
> To: Jeremy Tinkler
> Subject: Re: One-way telnet
>
> Hi,
>
> When you establish a telnet session you finish up with the following
> "connections" (the "arrow" shows the connectiondirection):
>
> A B
> some port > 1023 -------> port = 23
>
> Packets flowing from A to B always have souce IP=A, port > 1023,
> destination IP=B, port = 23. Packets flowing from B to A always have
> soyrce IP=B, port = 23, destination IP=A, port > 1023, ACK bit set.
>
> On a cisco router you'd have incoming ACLs like:
>
> # on interface closest to A
> access-list 100 permit tcp host A gt 1023 host B eq 23
>
> # on interface closest to B
> access-list 101 permit tcp host B eq 23 host A gt 1023 established
>
> This permits all packets required for a TCP session from A to B but no
> connections from B to A under any circumstances.
>
> With FTP things get more complex. With "normal" FTP you have two
> connections, a control channel and a data channel which is only opened
> for
> transferring information, shoing up as follows:
>
> A B
> control: port > 1023 ----> port = 21
> data: port > 1023 <---- port = 20
>
> Yes, the data connection is in reverse - from the server at B `TO' the
> client at A.
>
> Standard ACL's would be:
>
> # on interface closest to A
> # for the control channel
> access-list 100 permit tcp host A gt 1023 host B eq 21
> # for data channel
> access-list 100 permit tcp host A gt 1023 host B eq 20 established
>
> # on interface closest to B
> # for the control channel
> access-list 101 permit tcp host B eq 21 host A gt 1023 established
> # for the data channel
> access-list 101 permit tcp host B eq 20 host A gt 1023
>
> This last rule permits someone on B to "manufacture" packets on B with
> a
> source port of 20 and attempt to connect to any port on A > 1023.
>
> You need to examine A very carefully to see if this presents a
> problem. If
> so you'll need to go to passive FTP which works as follows:
>
> A B
> control: port > 1023 ----> port = 21
> data: port > 1023 ----> port > 1023
>
> The better part about this is the fact that both connections are from
> A to
> B. This would change the ACLs to:
>
> # on interface closest to A
> # for the control channel
> access-list 100 permit tcp host A gt 1023 host B eq 21
> # for data channel
> access-list 100 permit tcp host A gt 1023 host B gt 1023
>
> # on interface closest to B
> # for the control channel
> access-list 101 permit tcp host B eq 21 host A gt 1023 established
> # for the data channel
> access-list 101 permit tcp host B gt 1023 host A gt 1023 established
>
> Colin
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
