On Oct 20, 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. 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 / \

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

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

On Wednesday, 20 October 2004 17.43, Markus Gaugusch wrote:

On Oct 20, 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 :-)

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 *, 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 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

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