I'm wondering if anyone that recently upgraded to IOS 12.3 on any access servers have run into this problem... We recently upgraded our AS5x00 access servers to the 12.3(x) main line. Upon doing so we started seeing some very strange RADIUS accounting records coming from IP addresses all over the Internet. Normally these boxes are ACL'd but upon scanning an IP address that the routers listen on nmap shows a slew of open TCP service ports which accept connections. Upon connecting to one of the ports we're prompted for username and password just as if we connected to the VTY management lines. If we try to log in, it queries the RADIUS server. The question is why suddenly are the routers answering on tons of ports, is there a way to turn these service ports off? Normally these routers only listen on port 22/23 and 514 at best. Upon nmapping the access servers now, we see something like the below. (TAC suggested an access-list; I know we can apply an access-list to block all this, but then that means we have to put ingress access-lists on every interface, including connected modem users, etc.) 2001/tcp open dc 2003/tcp open cfingerd 2005/tcp open deslogin 2007/tcp open dectalk 2008/tcp open conf 2009/tcp open news 2011/tcp open raid-cc 2012/tcp open ttyinfo 2013/tcp open raid-am 2014/tcp open troff 2015/tcp open cypress 2016/tcp open bootserver 2019/tcp open whosockami 2021/tcp open servexec 2022/tcp open down 2023/tcp open xinuexpansion3 2025/tcp open ellpack 2026/tcp open scrabble 2027/tcp open shadowserver 2028/tcp open submitserver 2030/tcp open device2 2034/tcp open scoremgr 2035/tcp open imsldoc 2041/tcp open interbase 2042/tcp open isis 2043/tcp open isis-bcast 2044/tcp open rimsl 2045/tcp open cdfunc 2046/tcp open sdfunc 2049/tcp open nfs 2064/tcp open dnet-keyproxy 2067/tcp open dlswpn 2105/tcp open eklogin 2106/tcp open ekshell 2108/tcp open rkinit 2112/tcp open kip 4008/tcp open netcheque 4045/tcp open lockd 4133/tcp open nuts_bootp 6001/tcp open X11:1 6003/tcp open X11:3 6005/tcp open X11:5 6007/tcp open X11:7 6008/tcp open X11:8 6009/tcp open X11:9 6101/tcp open VeritasBackupExec 6103/tcp open RETS-or-BackupExec 6105/tcp open isdninfo 6106/tcp open isdninfo 6110/tcp open softcm 6112/tcp open dtspc 6142/tcp open aspentec-lm 6143/tcp open watershed-lm 6145/tcp open statsci2-lm 6146/tcp open lonewolf-lm 6147/tcp open montage-lm 6148/tcp open ricardo-lm 9090/tcp open zeus-admin 9100/tcp open jetdirect 9152/tcp open ms-sql2000 -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net PGP: http://www.inoc.net/~dev/ Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0 Years of development: We finally got one to work.
Robert Blayzor wrote:
I'm wondering if anyone that recently upgraded to IOS 12.3 on any access servers have run into this problem...
Put "transport input none" to your tty lines. Pete
We recently upgraded our AS5x00 access servers to the 12.3(x) main line. Upon doing so we started seeing some very strange RADIUS accounting records coming from IP addresses all over the Internet. Normally these boxes are ACL'd but upon scanning an IP address that the routers listen on nmap shows a slew of open TCP service ports which accept connections. Upon connecting to one of the ports we're prompted for username and password just as if we connected to the VTY management lines. If we try to log in, it queries the RADIUS server.
The question is why suddenly are the routers answering on tons of ports, is there a way to turn these service ports off? Normally these routers only listen on port 22/23 and 514 at best.
Upon nmapping the access servers now, we see something like the below. (TAC suggested an access-list; I know we can apply an access-list to block all this, but then that means we have to put ingress access-lists on every interface, including connected modem users, etc.)
2001/tcp open dc 2003/tcp open cfingerd 2005/tcp open deslogin 2007/tcp open dectalk 2008/tcp open conf 2009/tcp open news 2011/tcp open raid-cc 2012/tcp open ttyinfo 2013/tcp open raid-am 2014/tcp open troff 2015/tcp open cypress 2016/tcp open bootserver 2019/tcp open whosockami 2021/tcp open servexec 2022/tcp open down 2023/tcp open xinuexpansion3 2025/tcp open ellpack 2026/tcp open scrabble 2027/tcp open shadowserver 2028/tcp open submitserver 2030/tcp open device2 2034/tcp open scoremgr 2035/tcp open imsldoc 2041/tcp open interbase 2042/tcp open isis 2043/tcp open isis-bcast 2044/tcp open rimsl 2045/tcp open cdfunc 2046/tcp open sdfunc 2049/tcp open nfs 2064/tcp open dnet-keyproxy 2067/tcp open dlswpn 2105/tcp open eklogin 2106/tcp open ekshell 2108/tcp open rkinit 2112/tcp open kip 4008/tcp open netcheque 4045/tcp open lockd 4133/tcp open nuts_bootp 6001/tcp open X11:1 6003/tcp open X11:3 6005/tcp open X11:5 6007/tcp open X11:7 6008/tcp open X11:8 6009/tcp open X11:9 6101/tcp open VeritasBackupExec 6103/tcp open RETS-or-BackupExec 6105/tcp open isdninfo 6106/tcp open isdninfo 6110/tcp open softcm 6112/tcp open dtspc 6142/tcp open aspentec-lm 6143/tcp open watershed-lm 6145/tcp open statsci2-lm 6146/tcp open lonewolf-lm 6147/tcp open montage-lm 6148/tcp open ricardo-lm 9090/tcp open zeus-admin 9100/tcp open jetdirect 9152/tcp open ms-sql2000
Petri Helenius wrote:
Put "transport input none" to your tty lines.
That was it. Seems like the default value changed between versions. Thanks. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net PGP: http://www.inoc.net/~dev/ Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0 Quality assurance: A way to ensure you never deliver shoddy goods accidentally.
In message <4076FBAB.6040709@inoc.net>, Robert Blayzor writes:
Petri Helenius wrote:
Put "transport input none" to your tty lines.
That was it. Seems like the default value changed between versions. Thanks.
Wonderful -- a change to default behavior that opens up lots of ports. This is exactly the wrong direction to go in. --Steve Bellovin, http://www.research.att.com/~smb
On Fri, 9 Apr 2004, Steven M. Bellovin wrote:
In message <4076FBAB.6040709@inoc.net>, Robert Blayzor writes:
Petri Helenius wrote:
Put "transport input none" to your tty lines.
That was it. Seems like the default value changed between versions. Thanks.
Wonderful -- a change to default behavior that opens up lots of ports. This is exactly the wrong direction to go in.
No kidding. Another pet peeve of roughly the same category: when you enable IPv6, telnet is automatically open to the world (using v6), even if you have disabled v4 telnet with an access-list. The vendor refused to believe this is a problem, so I'm waiting for v6 deployment to get really started before writing bugtraq. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On 9-apr-04, at 22:27, Pekka Savola wrote:
Another pet peeve of roughly the same category: when you enable IPv6, telnet is automatically open to the world (using v6), even if you have disabled v4 telnet with an access-list.
The vendor refused to believe this is a problem,
Whether or not this is a problem is in the eye of the beholder, but from what I've seen, this is standard practice with any kind of packet filter. As far as I know, only hosts.allow-style tcp wrapping is agnostic about the IP version. If you want to run a new protocol, you have to configure filters for it unless you want to go through life unfiltered. That's the way things work. It's even worse with FreeBSD: if you firewall it to the teeth in v4 and disable v6 in the rc.conf, it will still run v6 with link-local addresses and allow access to the services that are filtered in v4.
On Fri, 9 Apr 2004, Iljitsch van Beijnum wrote:
On 9-apr-04, at 22:27, Pekka Savola wrote:
Another pet peeve of roughly the same category: when you enable IPv6, telnet is automatically open to the world (using v6), even if you have disabled v4 telnet with an access-list.
The vendor refused to believe this is a problem,
Whether or not this is a problem is in the eye of the beholder, but from what I've seen, this is standard practice with any kind of packet filter. As far as I know, only hosts.allow-style tcp wrapping is agnostic about the IP version.
So, with a cisco style vty acl how does one do both v4 and v6 filterage? (not speaking as a v6 user)
* christopher.morrow@mci.com (Christopher L. Morrow) [Fri 09 Apr 2004, 23:53 CEST]:
So, with a cisco style vty acl how does one do both v4 and v6 filterage? (not speaking as a v6 user)
! line vty 0 4 access-class 1 in ipv6 access-class v6telnet in ! -- Niels. -- Today's subliminal thought is:
On Sat, 10 Apr 2004, Niels Bakker wrote:
* christopher.morrow@mci.com (Christopher L. Morrow) [Fri 09 Apr 2004, 23:53 CEST]:
So, with a cisco style vty acl how does one do both v4 and v6 filterage? (not speaking as a v6 user)
! line vty 0 4 access-class 1 in ipv6 access-class v6telnet in !
so what was the original complaint about ipv6 and telnet then?
* christopher.morrow@mci.com (Christopher L. Morrow) [Sat 10 Apr 2004, 00:15 CEST]:
On Sat, 10 Apr 2004, Niels Bakker wrote:
! line vty 0 4 access-class 1 in ipv6 access-class v6telnet in !
so what was the original complaint about ipv6 and telnet then?
I think it was that an ACL ending with "deny ip any any" configured as access-class in didn't deny IPv6 traffic as well. -- Niels.
On 10-apr-04, at 0:03, Niels Bakker wrote:
So, with a cisco style vty acl how does one do both v4 and v6 filterage? (not speaking as a v6 user)
! line vty 0 4 access-class 1 in ipv6 access-class v6telnet in !
Don't forget: ! ipv6 access-list v6telnet permit ipv6 3FFE:2500:310::/48 any permit ipv6 2001:888:1DDE::/48 any !
* iljitsch@muada.com (Iljitsch van Beijnum) [Sat 10 Apr 2004, 00:22 CEST]:
On 10-apr-04, at 0:03, Niels Bakker wrote:
! line vty 0 4 access-class 1 in ipv6 access-class v6telnet in !
Don't forget:
! ipv6 access-list v6telnet permit ipv6 3FFE:2500:310::/48 any permit ipv6 2001:888:1DDE::/48 any !
Yes, that was implied, just like ! access-list 1 permit 195.69.144.0 0.0.1.255 ! was. -- Niels.
On Fri, 09 Apr 2004, Iljitsch van Beijnum wrote:
On 9-apr-04, at 22:27, Pekka Savola wrote:
Another pet peeve of roughly the same category: when you enable IPv6, telnet is automatically open to the world (using v6), even if you have disabled v4 telnet with an access-list.
The vendor refused to believe this is a problem,
Whether or not this is a problem is in the eye of the beholder, but from what I've seen, this is standard practice with any kind of packet filter. As far as I know, only hosts.allow-style tcp wrapping is agnostic about the IP version.
If you want to run a new protocol, you have to configure filters for it unless you want to go through life unfiltered. That's the way things work.
It's even worse with FreeBSD: if you firewall it to the teeth in v4 and disable v6 in the rc.conf, it will still run v6 with link-local addresses and allow access to the services that are filtered in v4.
Bad FreeBSD, no cookie for FreeBSD :) But if you don't need IPv6, remove INET6 from your kernel config file, rc.conf is not the right place to do it either. - yann
participants (8)
-
Christopher L. Morrow -
Iljitsch van Beijnum -
Niels Bakker -
Pekka Savola -
Petri Helenius -
Robert Blayzor -
Steven M. Bellovin -
Yann Berthier