Telnet access restrictions

A while ago I've got an interesting question from one of the readers:

I'd like to be able to configure a set of routers to only be manageable from each other. Something like an access-class matching minimum packet TTL would probably be good enough, better if some connected routes could be tagged and access granted based on that. The idea is to keep router-by-router logins in case of routing problems, without opening up access too widely.

I did a few tests with IOS release 12.4(15)T and neither access-class nor control-plane policing recognizes the TTL field in ACL (various bits and pieces of IOS use the same data structures in different procedures, thus resulting in inconsistent behavior). Alternatively, you could deploy inbound access lists on all interfaces, but this is probably way too cumbersome to manage.

The best you can do without going into weird solutions is to allocate router loopback interfaces and inter-router links from a tightly controlled address space and only allow telnet from that address space (while at the same time filtering IP packets pretending to come from that same address space on the perimeter of your network). As the IOS supports extended access lists in the access-class line configuration command, you could allow SSH from a wider set of IP addresses and limit Telnet to the address range allocated to inter-router links.

7 comments:

  1. Sorry for stupid question: why "minimum TTL"? I believe it should be "maximum TTL" = 255 (as specified in RFC5082, Generalized TTL Security Mechanism).
    But if I'm not mistaken, GTSM support is optional, so the router isn't *required* to set TTL=255 in originating packets (the only exception is IPv6 Neighbor Discovery). So I couldn't call this method 'reliable' enough.

    SY, Jen
  2. Hi Ivan, be 'testing' - do you mean you've tested
    the option of TTL in ACL, something like this ? :
    ip access-list ext VTY_ACCESS
    permit ip any any ttl eq 2

    .. and it didnt work ?
  3. @Jen: the idea was that you would match incoming TTL of the packets with the known TTL of the telnet packets generated by IOS. Of course, if the initial TTL used by IOS is not 255, you are still open to attacks, but I didn't get that far as I could not filter on TTL values.

    @Yuri: that's approximately what I was testing. Matching TTL in the interface access-list probably works, but when used in VTY access-class it did not work for me.
  4. I found this quite interesting so I lab'ed it up as well to examine the behaviors. However, I observed a different behavior and it appeared though that the ACL seemed to work under the vty line but something else didn't work (more on that at the end).

    I was using IOS 12.4(15)T5 and had the following config in my router initially:

    ip access-list extended ttl
    permit ip any any ttl eq 255 log
    permit ip any any ttl eq 254 log
    permit ip any any ttl eq 253 log
    permit ip any any ttl eq 252 log
    permit ip any any ttl eq 2 log
    permit ip any any ttl eq 1 log
    permit ip any any ttl eq 0 log
    permit ip any any ttl lt 255 log
    !
    line vty 0 4
    access-class ttl in
    !

    Next I telnet'ed to this router from another router on the same LAN and successfully opened a telnet session. Syslog showed the following matches on the first line (ttl was = 255 coming from my other router):

    Home-Rtr#sh access-lists ttl
    Extended IP access list ttl
    10 permit ip any any ttl eq 255 log (12 matches)
    20 permit ip any any ttl eq 254 log
    30 permit ip any any ttl eq 253 log
    40 permit ip any any ttl eq 252 log
    50 permit ip any any ttl eq 2 log
    60 permit ip any any ttl eq 1 log
    70 permit ip any any ttl eq 0 log
    80 permit ip any any ttl lt 255 log

    Oct 26 09:01:10: %SEC-6-IPACCESSLOGP: list ttl permitted tcp 10.1.1.5(1375) -> 0.0.0.0(23), 1 packet

    I then reworked my ACL entries by putting a deny:

    ip access-list extended ttl
    deny ip any any ttl eq 254 log
    deny ip any any ttl eq 255 log
    permit ip any any ttl eq 253 log
    permit ip any any ttl eq 252 log
    permit ip any any ttl eq 2 log
    permit ip any any ttl eq 1 log
    permit ip any any ttl eq 0 log
    permit ip any any ttl lt 255 log
    !

    When I tried to telnet again I got denied. Syslog showed the following:

    Extended IP access list ttl
    2 deny ip any any ttl eq 254 log
    3 deny ip any any ttl eq 255 log (3 matches)
    30 permit ip any any ttl eq 253 log

    Oct 26 09:06:23: %SEC-6-IPACCESSLOGP: list ttl denied tcp 10.1.1.5(1383) -> 0.0.0.0(23), 1 packet

    If my test setup was correct then the ACL under the VTY lines was appeared to be working. However, I do have a question:

    * How can one initiate a telnet session from a router with a TTL of, says, 2?

    I have looked at various options available in the latest IOS and could not find a way to initiate a telnet session with a custom TTL value. In other words...for that reader to be able to log into his/her router from another locally connected router, he/she must find a way to initiate a telnet with a customized TTL setting.

    William
  5. Using either your configuration or this one ...

    ip access-list extended TTL
    permit tcp any any eq telnet ttl eq 253 log
    permit tcp any any eq telnet ttl eq 254 log
    permit tcp any any eq telnet ttl eq 255 log
    permit tcp any any eq telnet log
    !
    line vty 0 4
    access-class TTL in

    ... on C3725-ADVIPSERVICESK9-M, Version 12.4(15)T5, I always get hits on the line with TTL EQ 255 regardless of the actual TTL. For example, if I open a telnet session from a router two hops away, TTL should drop to 253 and a different line in the ACL should match. So it's (in my opinion) still not working.
  6. A very interesting discovery, Ivan. I was testing from another router directly attached to the testing router so I was looking for TTL=255 all the way. With your discovery I then tried matching on dscp or tos value but saw no hit on the ACL under the vty lines. Sniffer showed the proper DSCP or TOS marking coming in but debug on the router didn't show anything obvious as to why telnet was rejected. Very strange behaviors.
  7. As for me it's a normal.
    Packets for telnet session may come from any interface, and even from different interfaces in the same telnet session (for example, you are telneting to loopback interface and routing tables are changing). It's hard to apply dynamic access rules on each interface after session setup and any change of config (for example during telnet you setup new subinterface and telnet packets began to be delivered to router trough it).
    That is why the lines after
    line vty 0 4
    are config lines for "Virtual Exec" proccess, this proccess acts on application level and it checks only the source address of telnet packet to accept or to drop it (probably, only first packet for each session). Any packet for TCP port 23 or 22 is delivered directly to "Virtual Exec".
    It should be to expensive (cpu usage, process logic comlexity) to make this process to analyze TTL,DSCP, etc.. fields for any incomming packet.

    This things are the same for SNMP requests processig. That is why it's hard to 100% protect router when you are using RW community.
Add comment
Sidebar