Nipper and Cisco configuration results

I am using Nipper for verifying my Cisco configuration. Nipper is finding the "rlogin" service that is not in the configuration. I have searched the access lists and do not see it anywhere. The explanation by Nipper about this finding, "....Telnet protocol implemented by this service...." is confusing. Here is the Nipper's output:

Subba Rao wrote:

Can someone explain why Nipper is saying "Rlogin is enabled" when

> I do not see it in the configuration file? Is there something
> else that I need to be looking at?

It's been my experience that the routers are all listening on that port by default, and we notice it as a result of people nmap'ing us:

Dec 15 17:27:16 MST: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to RSHELL from a.b.c.d

Everything I've read indicates that additional specific configuration is required to actually enable this service. Still, it's always been one of my least favorite things about IOS. If I don't need it, it shouldn't be on. And why doesn't "show ip sockets" list it at all?

If I was a tinfoil hat person, I'd assume that is the NSA's back door.

Mike

What IOS version are you using? I don't see that behavior (rlogin/rsh) by
default, but I'm a few revisions behind on the latest. @ 12.2
I do see from the router:
RCMD-4-RSHPORTATTEMPT Attempted to connect to RSHELL from 192.168.1.52
from nmaps, but theres no response to the SYN packet of the attempting IP. I
think this has been
the case since w-a-y earlier versions of IOS for logging levels but not sure
at which level.
Looks to only be logging an attempt, no session is made, sort of like a
firewall
just letting you know there was an attempt. The router gets the request but
it falls on deaf
ears, no one home. Unless perhaps theres some other sort of flag/bit that
can be presented to
open that connection(extremely doubtful) I don't believe theres any way to
connect.

Perhaps turning down your logging will prevent your testing program from
reporting a false positive?
I'd snoop/sniff the traffic and see if your router is SYN/ACK-ing the
request of rlogin/rsh to be sure.

<sarcasm>And make sure their not to close to one another, incase their using
undocumented
internal wireless units as a means to complete the connection, those Cisco
guys you know..</sarcasm>

Regards
Joe Blanchard

Cisco considers this a fixed bug. See bug id CSCeb21552 for work-around
and fixed-in versions.

Steve

I am using Nipper for verifying my Cisco configuration. Nipper is finding
the "rlogin" service that is not in the configuration. I have searched the
access lists and do not see it anywhere. The explanation by Nipper about
this finding, "....Telnet protocol implemented by this service...." is
confusing. Here is the Nipper's output:

  <..snip ..>

Can someone explain why Nipper is saying "Rlogin is enabled" when I do not
see it in the configuration file? Is there something else that I need to be
looking at?

I played with it a bit - removing the "transport input telnet" on a
vty line got me the rlogin service is enabled. Add it back & nipper
says it's disabled...

Do you have a "transport input telnet" on each vty? If not, does
adding it fix the nipper report?

Regards,
Lee

I am using Nipper for verifying my Cisco configuration. Nipper is
finding the "rlogin" service that is not in the configuration. I have
searched the access lists and do not see it anywhere. The explanation
by Nipper about this finding, "....Telnet protocol implemented by this
service...." is confusing.

The problem, IMHO, is nipper. You might or might not have the rlogin
service enabled, but nipper has so many false positives I find is almost
useless. In my case, it caught some obvious things I had forgotten to
do, but everything else was useless. For instance from the nipper
source code:

struct vulnerability report_vuln_ios11 = {9, 0, 0, 12, 4, 0,
                          "CVE-2007-0479", "22208",
                          "IPv4 TCP listener denial of service",
                          true, false,
                          vuln_req_none, false, &report_vuln_ios12};

What the above means to nipper is any IOS version 12.0.x, 12.1.x,
12.2.x, 12.3.x is vulnerable, while every 12.4.x version is OK. This is
obviously false on *both* counts.

I spent a lot of time trying to explain this to $corporate audit guy
that had never even logged into a router, let alone had to choose a
stable IOS version for 6500/7600 class hardware.

  Here is the Nipper's output:

<snip>