ssh/telnet Question
I've just read an article about using ssh/telnet. The article suggested setting a Linux box in front of a mainframe, thus allowing users to telnet to the mainframe _after_ securely connecting to the Linux box via ssh. The Linux Security Admin Guide also suggests not installing (or deleting) services you know you won't be using to prevent attackers from using them to access your system. So, other than using a Linux box as a front door for a mainframe telnet session, is there any valid reason to even install telnet, rlogin, etc.? Based on the SAG, I could eliminate telnet, etc., as I cannot think of any reason to use those services in my LAN (which has no mainframe). SUSE installs these services by default (at least as of 8.0), so I'm thinking about removing them, unless someone can offer good reasons to retain them. My LAN consists of 6 SUSE 8.0 boxes and currently has no connection to the outside world (though that may come at a later date). I want to be sure I thoroughly understand security issues and that I am implementing the best practices for my LAN _before_ I think about connecting it to the outside world. Thanks in advance for your input. Don -- DC Parris http://matheteuo.org/ http://chaddb.sourceforge.net/ "Free software is like God's love - you can share it with anyone anytime anywhere."
On Oct 20, Don Parris <webdev@matheteuo.org> wrote:
I've just read an article about using ssh/telnet. The article suggested setting a Linux box in front of a mainframe, thus allowing users to telnet to the mainframe _after_ securely connecting to the Linux box via ssh. That's the way one should go (IMHO).
The Linux Security Admin Guide also suggests not installing (or deleting) services you know you won't be using to prevent attackers from using them to access your system. So, other than using a Linux box as a front door for a mainframe telnet session, is there any valid reason to even install telnet, rlogin, etc.? If you mean the telnet server: Clearly NO. The telnet client is still valueable, though. You can use it for many purposes (read your POP3 mail, HTTP requests, send mail via SMTP, ...), not only telnet (port 23).
Based on the SAG, I could eliminate telnet, etc., as I cannot think of any reason to use those services in my LAN (which has no mainframe). SUSE installs these services by default (at least as of 8.0), so I'm thinking about removing them, unless someone can offer good reasons to retain them. My LAN consists of 6 SUSE 8.0 boxes and currently has no connection to the outside world (though that may come at a later date). I want to be sure I thoroughly understand security issues and that I am implementing the best practices for my LAN _before_ I think about connecting it to the outside world. Thanks in advance for your input. SuSE 8.0 will become unsupported in a few weeks/months, so you should not use 8.0 in an insecure environment. I also don't think that a telnet server is enabled by default on 8.0, but I may be wrong. Otherwise, your thoughts are correct and you seem to make everything right.
Markus -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus(at)gaugusch.at X Against HTML Mail / \
Hi *, first read Answers from Markus, and you oftn don`t need to answer. ;-)))) But a little thing: 8.0 is discontinued ;-( http://www.suse.de/de/private/download/updates/index.html ftp://ftp.suse.com/pub/suse/discontinued/i386/ So you doesn`t work. Better don`t use this anymore. Btw. what about fou4s ;-)) Dirk Markus Gaugusch schrieb:
On Oct 20, Don Parris <webdev@matheteuo.org> wrote:
I've just read an article about using ssh/telnet. The article suggested setting a Linux box in front of a mainframe, thus allowing users to telnet to the mainframe _after_ securely connecting to the Linux box via ssh.
That's the way one should go (IMHO).
The Linux Security Admin Guide also suggests not installing (or deleting) services you know you won't be using to prevent attackers from using them to access your system. So, other than using a Linux box as a front door for a mainframe telnet session, is there any valid reason to even install telnet, rlogin, etc.?
If you mean the telnet server: Clearly NO. The telnet client is still valueable, though. You can use it for many purposes (read your POP3 mail, HTTP requests, send mail via SMTP, ...), not only telnet (port 23).
Based on the SAG, I could eliminate telnet, etc., as I cannot think of any reason to use those services in my LAN (which has no mainframe). SUSE installs these services by default (at least as of 8.0), so I'm thinking about removing them, unless someone can offer good reasons to retain them. My LAN consists of 6 SUSE 8.0 boxes and currently has no connection to the outside world (though that may come at a later date). I want to be sure I thoroughly understand security issues and that I am implementing the best practices for my LAN _before_ I think about connecting it to the outside world. Thanks in advance for your input.
SuSE 8.0 will become unsupported in a few weeks/months, so you should not use 8.0 in an insecure environment. I also don't think that a telnet server is enabled by default on 8.0, but I may be wrong. Otherwise, your thoughts are correct and you seem to make everything right.
Markus
TRIA IT-consulting GmbH Joseph-Wild-Stra?e 20 81829 Munchen Germany Tel: +49 (89) 92907-0 Fax: +49 (89) 92907-100 http://www.tria.de -------------------------------------------------------- working hard | for your success -------------------------------------------------------- Registergericht Munchen HRB 113466 USt.-IdNr. DE 180017238 Steuer-Nr. 802/40600 Geschaftsfuhrer: Richard Hofbauer Rosa Igl -------------------------------------------------------- Nachricht von: dirk.schreiner@tria.de Nachricht an: markus@gaugusch.at, suse-security@suse.com # Dateianhange: 0 Die Mitteilung dieser E-Mail ist vertraulich und nur fur den oben genannten Empfanger bestimmt. Wenn Sie nicht der vorgesehene Empfanger dieser E-Mail oder mit der Aushandigung an ihn betraut sind, weisen wir darauf hin, da? jede Form der Kenntnisnahme, Veroffentlichung, Vervielfaltigung sowie Weitergabe des Inhalts untersagt ist. Wir bitten Sie uns in diesem Fall umgehend zu unterrichten. Vielen Dank The information contained in this E-Mail is privileged and confidental intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient or competent to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this E-Mail is strictly prohibited. If you have received this E-Mail in error, please notify us immediately. Thank you
SUSE installs these services by default (at least as of 8.0), so I'm thinking about removing them, unless someone can offer good reasons to retain them. My LAN consists of 6 SUSE 8.0 boxes and currently has no
If the service isn't running why remove it? Are you worried that someone will hack your box then start the service? If they hacked your box then you're already screwed. If the software is not there they can/will install it. Also, you may want to use the telnet client. I use it all the time to test connections. And to make sure that services/ports are responding with the correct data. If it were something big that you thought would save a LOT of disk space then I might think about removing it, but those few items you mention are very small and aren't worth the effort to remove. IMO. BB
Don Parris wrote:
... So, other than using a Linux box as a front door for a mainframe telnet session, is there any valid reason to even install telnet, rlogin, etc.?
Based on the SAG, I could eliminate telnet, etc., as I cannot think of any reason to use those services in my LAN (which has no mainframe). SUSE installs these services by default (at least as of 8.0), so I'm thinking about removing them, unless someone can offer good reasons to retain them. My LAN consists of 6 SUSE 8.0 boxes and currently has no connection to the outside world (though that may come at a later date). I want to be sure I thoroughly understand security issues and that I am implementing the best practices for my LAN _before_ I think about connecting it to the outside world. Thanks in advance for your input.
You are wise to think/design this before you get there, if only more companies would we'd have fewer problem on the net...sigh... Yes, turn off every service you don't explicitly need. Go into /etc/xinetd.d and make sure every file's "disable" field is "yes" unless you know for sure you need it. Do an "nmap" against your machine (from another machine) to see what's there and needs to be turned off. I think you're on a good path not to allow rsh, rlogin, and ftp. We don't allow those here except for a couple of test machines that need ftp (one could put that in a chroot jail if needed). Our folks use ssh, scp, sftp for their work. The client telnet is actually useful in a few places as a testing tool; so I install it, but telnetd does not go on the box. HTH and Good Luck! Kevin
Don Parris wrote:
I've just read an article about using ssh/telnet. The article suggested setting a Linux box in front of a mainframe, thus allowing users to telnet to the mainframe _after_ securely connecting to the Linux box via ssh. The Linux Security Admin Guide also suggests not installing (or deleting) services you know you won't be using to prevent attackers from using them to access your system. So, other than using a Linux box as a front door for a mainframe telnet session, is there any valid reason to even install telnet, rlogin, etc.?
Based on the SAG, I could eliminate telnet, etc., as I cannot think of any reason to use those services in my LAN (which has no mainframe). SUSE installs these services by default (at least as of 8.0), so I'm thinking about removing them, unless someone can offer good reasons to retain them. My LAN consists of 6 SUSE 8.0 boxes and currently has no connection to the outside world (though that may come at a later date). I want to be sure I thoroughly understand security issues and that I am implementing the best practices for my LAN _before_ I think about connecting it to the outside world. Thanks in advance for your input.
There is an important distinction between "installed" and "running". SuSE installs telnet in case you want to use it, but at least as of SuSE 9.0 (and probably much earlier), it's not actually turned on by default. Modern unix systems have really moved away from the "don't install unless you absolutely need it" to a "install everything, but firewall off all the ports you don't need". This allows far more uniformity in your install base. Rather than having to back up entire systems, you can just keep copies of the /etc, /usr/local, and /home. You can also keep a spare machine on hand that with only unpacking a tarball can take the place of any other system. Another important practice is security patches. It sounds like your systems haven't had net access, and therefore haven't had any security update in years. This is a far more dangerous situation than any service like telnet sitting on your hard drive.
Hi,
front door for a mainframe telnet session, is there any valid reason to even install telnet, rlogin, etc.?
Yes, if you need to update ssh remotly. sshd got a lot of security problems the last years, if you have to update it remotly you will enable telnetd for a short period to restart sshd after an update - if the update fails you will be locked out of a remote system :-) Anyway you should consider to use pam features to secure the login (via sshd and telnet): disable remote root login, limit the su command then to few selected users with the pam listfile module. Nearly all script kiddies will fail to use a rootkit, even if they get it installed, as they are not able to add a user to the arbitrary listfile. That saved my servers once... You should upgrade to the latest SuSE Version anyway, obsolete products become really difficult after a short time (as you have to upgrade everything from sources manually). Good luck, Dieter
Dieter Kirchner wrote:
Hi,
front door for a mainframe telnet session, is there any valid reason to even install telnet, rlogin, etc.?
Yes, if you need to update ssh remotly. sshd got a lot of security problems the last years, if you have to update it remotly you will enable telnetd for a short period to restart sshd after an update - if the update fails you will be locked out of a remote system :-)
Anyway you should consider to use pam features to secure the login (via sshd and telnet): disable remote root login, limit the su command then to few selected users with the pam listfile module. Nearly all script kiddies will fail to use a rootkit, even if they get it installed, as they are not able to add a user to the arbitrary listfile. That saved my servers once...
You should upgrade to the latest SuSE Version anyway, obsolete products become really difficult after a short time (as you have to upgrade everything from sources manually).
Good luck,
Dieter
Even though the OS is fairly old, I've only recently setup the LAN. I've already ordered SUSE PRO 9.2, and will certainly be better off at that point. I am fairly new to the security admin side of things, and so want to learn prior to the upgrade. I've been reading the SAG (which is quite dated now) & the Linux Security HOWTO (an updated SAG, maybe? It's by the same author/contains similar info) to learn about this issue. When I update, I'll do a clean install on these boxes. Y'all have given me something to think about for now. Thanks. Don -- DC Parris http://matheteuo.org/ http://chaddb.sourceforge.net/ "Free software is like God's love - you can share it with anyone anytime anywhere."
On Oct 20, Dieter Kirchner <dkirchner@bupnet.de> wrote:
Hi,
front door for a mainframe telnet session, is there any valid reason to even install telnet, rlogin, etc.?
Yes, if you need to update ssh remotly. sshd got a lot of security problems the last years, if you have to update it remotly you will enable telnetd for a short period to restart sshd after an update - if the update fails you will be locked out of a remote system :-)
I clearly disagree. I haven't needed telnet for a long time, not even for sshd updates. In case of severe fear, I copy the sshd to another name, start it on another port and log in via that instance. Then I can easily update, kill or reconfigure the main sshd. Markus -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus(at)gaugusch.at X Against HTML Mail / \
On Wednesday, 20 October 2004 17.43, Markus Gaugusch wrote:
On Oct 20, Dieter Kirchner <dkirchner@bupnet.de> wrote:
Hi,
front door for a mainframe telnet session, is there any valid reason to even install telnet, rlogin, etc.?
Yes, if you need to update ssh remotly. sshd got a lot of security problems the last years, if you have to update it remotly you will enable telnetd for a short period to restart sshd after an update - if the update fails you will be locked out of a remote system :-)
I clearly disagree. I haven't needed telnet for a long time, not even for sshd updates. In case of severe fear, I copy the sshd to another name, start it on another port and log in via that instance. Then I can easily update, kill or reconfigure the main sshd.
Or indeed just log in and restart. When you restart sshd it will not kill the existing logins, so your shell will still be there. Log in, restart sshd, try to log in in a second window, if it works, done, if it doesn't, go back to the first window and fix the problem. No need for any special magic, and definitely no need for telnetd
Hi Dieter, Dieter Kirchner schrieb:
Hi,
front door for a mainframe telnet session, is there any valid reason to even install telnet, rlogin, etc.?
Yes, if you need to update ssh remotly. sshd got a lot of security problems the last years, if you have to update it remotly you will enable telnetd for a short period to restart sshd after an update - if the update fails you will be locked out of a remote system :-)
ouch, don`t tell such things in this list. Might be read by a newbee. Better search this list about how to update ssh _secure_ remotly. Or consider man sshd; man ps; man kill. Again, there is _no_ need to enable telnet just for an sshd update. Dirk TRIA IT-consulting GmbH Joseph-Wild-Stra?e 20 81829 Munchen Germany Tel: +49 (89) 92907-0 Fax: +49 (89) 92907-100 http://www.tria.de -------------------------------------------------------- working hard | for your success -------------------------------------------------------- Registergericht Munchen HRB 113466 USt.-IdNr. DE 180017238 Steuer-Nr. 802/40600 Geschaftsfuhrer: Richard Hofbauer Rosa Igl -------------------------------------------------------- Nachricht von: dirk.schreiner@tria.de Nachricht an: dkirchner@bupnet.de, suse-security@suse.com # Dateianhange: 0 Die Mitteilung dieser E-Mail ist vertraulich und nur fur den oben genannten Empfanger bestimmt. Wenn Sie nicht der vorgesehene Empfanger dieser E-Mail oder mit der Aushandigung an ihn betraut sind, weisen wir darauf hin, da? jede Form der Kenntnisnahme, Veroffentlichung, Vervielfaltigung sowie Weitergabe des Inhalts untersagt ist. Wir bitten Sie uns in diesem Fall umgehend zu unterrichten. Vielen Dank The information contained in this E-Mail is privileged and confidental intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient or competent to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this E-Mail is strictly prohibited. If you have received this E-Mail in error, please notify us immediately. Thank you
Hi,
Yes, if you need to update ssh remotly. sshd got a lot of security
ouch, don`t tell such things in this list. Might be read by a newbee.
Again, there is _no_ need to enable telnet just for an sshd update.
I needed this setup once while adjusting sshd pam config. I agree that for a normal update there is no need for telnetd, but messing around with login software on a remote root server can be tricky. It's nice to have a plan B, and IMHO the risk enabling telnetd for some minutes is acceptable. The passwords should be changed after using telnet, of course. Your newbees will prefer to call the provider if somethings going wrong (and pay for that service) :-) Ciao, Dieter
Hi Dieter, don`t know if i already answered, but this is still in my Inbox. Dieter Kirchner schrieb:
Hi,
Yes, if you need to update ssh remotly. sshd got a lot of security
ouch, don`t tell such things in this list. Might be read by a newbee.
Again, there is _no_ need to enable telnet just for an sshd update.
I needed this setup once while adjusting sshd pam config. I agree that for a normal update there is no need for telnetd, but messing around with login software on a remote root server can be tricky. It's nice to have a plan B, and IMHO the risk enabling telnetd for some minutes is acceptable. The passwords should be changed after using telnet, of course.
Your newbees will prefer to call the provider if somethings going wrong (and pay for that service) :-)
no, "my" newbees, especially those visiting my Network Courses, and often also those visiting my Administration Courses prefer to use their already running SSH-Shell to reconfigure the new SSH-Server and try again. (Remember i mentioned man sshd, man kill.) And yes, there is a little risk of Power failure when having a non working ssh-Configuration. You can get around this, by preparing telnetd for starting after a reboot. But what if the unplaned Shutdown corrupts the File System ;-(( (Don`t forget to sync after every Command and to disable telnet afer configuring Session. SCNR) But anyway, i don`t think "my" newbees will be paying for a misconfiguration due to a Power Failure (at/by ??) the Provider. Greetings Dirk
Ciao, Dieter
TRIA IT-consulting GmbH Joseph-Wild-Stra?e 20 81829 Munchen Germany Tel: +49 (89) 92907-0 Fax: +49 (89) 92907-100 http://www.tria.de -------------------------------------------------------- working hard | for your success -------------------------------------------------------- Registergericht Munchen HRB 113466 USt.-IdNr. DE 180017238 Steuer-Nr. 802/40600 Geschaftsfuhrer: Richard Hofbauer Rosa Igl -------------------------------------------------------- Nachricht von: dirk.schreiner@tria.de Nachricht an: suse-security@suse.com # Dateianhange: 0 Die Mitteilung dieser E-Mail ist vertraulich und nur fur den oben genannten Empfanger bestimmt. Wenn Sie nicht der vorgesehene Empfanger dieser E-Mail oder mit der Aushandigung an ihn betraut sind, weisen wir darauf hin, da? jede Form der Kenntnisnahme, Veroffentlichung, Vervielfaltigung sowie Weitergabe des Inhalts untersagt ist. Wir bitten Sie uns in diesem Fall umgehend zu unterrichten. Vielen Dank The information contained in this E-Mail is privileged and confidental intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient or competent to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this E-Mail is strictly prohibited. If you have received this E-Mail in error, please notify us immediately. Thank you
participants (8)
-
Anders Johansson -
Brad Bendily -
Dieter Kirchner -
Dirk Schreiner -
Don Parris -
Kevin Brannen -
Markus Gaugusch -
suse＠rio.vg