ACL-back and forth?

Hi guyz,

Herez another doubt(im full of em)..

If i have an ACL say

access-list 101 deny tcp source add mask host dest add eq telnet
access-list 101 permit ip any any

Basically not allowing a network A to telnet to a host B.

Would this mean that host B would also be denied telnetting into any host in network A?

Thanks again in advance!

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

stuh84

Someone may correct me on this, but I'm pretty sure doing that alone will not do anything, you have to apply them to an interface/vty line to be able to use them.

Given you actually pass a direction onto the interface (as in whether they apply inbound or outbound), then this dictates your scenario.

Dubuku57

Okay sorry din put that info in, I would apply this ACL on the inside interface of the router, say smth like

int f0/1
ip access-group 101 in

Then only the telnetting traffic from inside the network would be denied right? Would the returning telnetting traffic be denied too?

captobvious

Dubuku57 wrote: »

Okay sorry din put that info in, I would apply this ACL on the inside interface of the router, say smth like

int f0/1
ip access-group 101 in

Then only the telnetting traffic from inside the network would be denied right? Would the returning telnetting traffic be denied too?

From the Odom book on Controlling Telent and SSH Access with ACLs

"However, to do the job by enabling ACLs on interfaces using ip access-group interface subcommand, the ACL would need to check for all the router's IP addresses, and both the Telnet and SSH port. As new interfaces are configured, the ACL would need to be updated.

IOS provides a much easier option for protecting access into and out of the virtual terminal line(vty) ports. Telnet and SSH users connect to vty lines on a router, so to protect that access, an IP ACL can be supplied to the vty lines."

In your case, if you wanted to stop a certain subnet from telnetting to your router it is better to use a standard ACL as follows:

access-list 1 deny 172.16.1.0 0.0.0.255

line vty 0 4
access-group 1 in

sandman748

This is the same question as in your other thread, which I see died without an answer.

This has got me wondering as well. With the access list as is; telnet traffic for network A destined for network B will be dropped at the interface with the ACL applied.

But what If network B tries to telnet to Network A. The packets would make it to from network B to network A, but would the return traffic be allowed or would it match the ACL on the way back?

Can we use the established key word at the end of an ACL for telnet traffic? If we can, and put that at the top of the ACL, it should allow the traffic to return. I know we can do it for http, just not sure about about telnet.

Just to clarify, I don't think he is trying to restrict telnet traffic to a router. He's just trying to set this up between hosts, assuming that they are all set up for telnet.

shednik

sandman748 wrote: »

This is the same question as in your other thread, which I see died without an answer.

This has got me wondering as well. With the access list as is; telnet traffic for network A destined for network B will be dropped at the interface with the ACL applied.

But what If network B tries to telnet to Network A. The packets would make it to from network B to network A, but would the return traffic be allowed or would it match the ACL on the way back?

Can we use the established key word at the end of an ACL for telnet traffic? If we can, and put that at the top of the ACL, it should allow the traffic to return. I know we can do it for http, just not sure about about telnet.

Just to clarify, I don't think he is trying to restrict telnet traffic to a router. He's just trying to set this up between hosts, assuming that they are all set up for telnet.

Yes it should allow the traffic because the return traffic should be using the original source port as the destination. So the initial packet would have a destination port of 23, with a source of say 2523. The return packet would be flipped destination of 2523, and source of 23. So the established statement in the ACL isn't needed.

networker050184

You really need to understand how TCP works as shednik pointed out the return traffic will not have destination port of 23 and will therefore be allowed through the ACL.

jason_lunde

Transmission line from a telnet session in wireshark...

Session initiation:
Transmission Control Protocol, Src Port: 5175 (5175), Dst Port: telnet (23), Seq: 0, Len: 0
Source port: 5175 (5175)
Destination port: telnet (23)
Flags: 0x02 (SYN)

And back to my computer from the switch...
Transmission Control Protocol, Src Port: telnet (23), Dst Port: 5175 (5175), Seq: 0, Ack: 1, Len: 0
Source port: telnet (23)
Destination port: 5175 (5175)
Flags: 0x12 (SYN, ACK)

with some output omitted of course. But the traffic according to this would pass the acl.

hope this helps...

Dubuku57

Yes Sandman, ur right the thread sorta died so started a new one

Thanks guys, i think i get it- the ACL looks at the port numbers for tcp traffics and uses that to determine what goes through and does not. This woul dbe the case for HTTP also? In this case the 'established' command would not be needed at all right?

So, if this was a NAT case, would the and im applying a std list to an inside source, would the returning traffic b denied also?

shednik

Dubuku57 wrote: »

Yes Sandman, ur right the thread sorta died so started a new one

Thanks guys, i think i get it- the ACL looks at the port numbers for tcp traffics and uses that to determine what goes through and does not. This woul dbe the case for HTTP also? In this case the 'established' command would not be needed at all right?

So, if this was a NAT case, would the and im applying a std list to an inside source, would the returning traffic b denied also?

Anything TCP or UDP will follow the same rules dest port/source port for sending and the return will be the same ports but flipped. If I load up wireshark and do an nslookup on www.google.com.... It works exactly the same src port of 1089 with a dst of 53. NAT shouldn't make a difference of this since it does not modify the ports only the source and/or destination address.

Dubuku57

Thanks for clarifying that! I just get confused smtms when different books/question paper answers mention stuff otherwise - start doubting myself :S