full-disclosure - Re: Re: open telnet port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: Robert.Moss at psinet.telstra.co.uk (Robert Moss)
Subject: Re: Re: open telnet port

Hi Peoples,
   I've been following this thread, and there are some really good
examples of how to set up secure backup access..  Here is a way that I
have used in the past:

Usually I would use a Cisco console server (2511 with 16 async serial
ports, 2600 with AS32 async serial ports), which provides reverse telnet
(this has already been covered).

Alternatively, you could set up a simple unix server with a multiport
serial board and connect that up to each servers' serial/console port.

Lastly, in the case of a small server network of say 6 or less servers,
you can attatch null modem cables between each pair of servers, and fire
up mgetty/getty on the serial port for the server(s) that you are
working on.  This provides a reasonably secure backup method of
connecting.  Keeping in mind that serial ports can be sniffed just as
easily as a telnet session, but with the provision that someone needs
physical access to the server(s) or a shell with priveledges for
connecting to the serial port device.

There are some things that I consider reasonably obvious that I will
omit here, ask for more details

Cheers
Robert Moss.

-----Original Message-----
From: full-disclosure-admin@...ts.netsys.com
[mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Andrew
Haninger
Sent: 09 September 2004 21:46
To: Gary E. Miller
Cc: full-disclosure@...ts.netsys.com
Subject: Re: [Full-Disclosure] Re: Re: open telnet port

> Yo Andrew!
... Right.

> Then you update OpenSSL and it crashes all the ssh processes at the 
> same time.  Been, there, done that.
Thanks a lot.

After your suggestion that it couldn't be done, I tried it. While it
took thinking, I could have done it had I not killall'ed my sshd's
without changing the paths in my "restart-sshd" cron job to reflect the
new location of sshd. :-/

Well, on the bright side, this will encourage me to make my script such
that it restarts sshd from either location. (/usr/sbin, where Slackware
puts it, or /usr/local/sbin, where the OpenSSH "make install" script
puts it).

Anyway, this would also be a solution. I have a shell script that checks
for ssh to be running on a couple ports*. If it isn't running, the
script starts it. I then placed this script into /etc/cron.hourly.
So, if I had it scripted correctly, I could install a new version of
libssl, install a new version of sshd, kill all running sshd's and then
wait about an hour for my system to start them back up.

*Actually, it runs nmap on, say, port 22. If there's no response, it
considers sshd not to be running. Someone could fool it by running some
other program on that port, but this is sufficient for me on a NAT'ed
machine at home on a cable connection.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html