linux security - Jun 1998 - Services not required?

I''m in the process of locking down as much of my systems here
as possible as to available ports.  I am down to only a handful
but am not sure how much of a security risk they pose and was
wondering if anyone here might be able to comment, or suggest
secure versions to run:

21/FTP        (WU-ftpd v2.4.2 BETA 14)
22/SSH        (1.22)
23/TELNET     (Netkit 0.09)
25/SMTP       (Sendmail v8.8.7)
49/TACACS     (TACACS_Plus v4.0.2 BETA/Cisco)
53/DNS        (BIND v8.1.2)
80/HTTP       (Apache v1.2.6 - upgrading to v1.3.0)
110/POP3      (Katie Steven''s v1.016)
111/RPC       (Netkit 0.09)
113/IDENTD    (????)
669/MOUNTD    (RPC/Linux Userspace NFS server v2.2beta29)
2049/NFS      (RPC/Linux Userspace NFS server v2.2beta29)
6669/APCUPSD  (UPS Monitoring, read-only from UPS server, already sent
                 letter to author for security info).

On servers that have no need for the above ports (ie, telnet, tacacs, pop3,
et al) they are disabled.  My main concerns are based on the assumption
that someone might gain access to the local subnet, which protocols
would be sniffable/hackable/et al?

Stephen Costaras,
stevecs@chaven.com

# 110/POP3      (Katie Steven''s v1.016)

Has this problem been patched:

	http://www.samiam.org/pop3/exploit.html

Oh, and I can''t post to linux-security without a question, and a patch
of
my own:

Question: Since the version of Pam for RH4.2 is Pam 0.57, why does the
          the XFree86-3.3.2 security require Pam 0.59?  Yes, I tried
          compiling Pam 0.59 from the RH5.0 SRPM, but it didn''t work.
          Can I safely install this by using the --nodeps flag?  I notice
          it is the spec file that specifically asks for version 0.59 (or
          higher) of Pam.

Patch: Patch for Apache 1.2.5 that requires that all cgi-bin scripts are
       Perl scripts that run in taint mode.  It hard-wires Apache to
       reject any cgi-bin that doesn''t start off as
"#!/usr/bin/perl -T"

RPMS built around this patch are here:

	http://linux.samiam.org/blackdragon/

- Sam

*** apache_1.2.5/src/mod_cgi.c.orig	Mon Jun  8 15:58:15 1998
--- apache_1.2.5/src/mod_cgi.c	Mon Jun  8 16:18:46 1998
***************
*** 343,350 ****
  {
      int retval, nph, dbpos = 0;
      char *argv0, *dbuf = NULL;
!     FILE *script_out, *script_in, *script_err;
!     char argsbuffer[HUGE_STRING_LEN];
      int is_included = !strcmp (r->protocol, "INCLUDED");
      void *sconf = r->server->module_config;
      cgi_server_conf *conf --- 343,350 ----
  {
      int retval, nph, dbpos = 0;
      char *argv0, *dbuf = NULL;
!     FILE *script_out, *script_in, *script_err, *perl_check;
!     char argsbuffer[HUGE_STRING_LEN], bangline[20];
      int is_included = !strcmp (r->protocol, "INCLUDED");
      void *sconf = r->server->module_config;
      cgi_server_conf *conf ***************
*** 365,370 ****
--- 365,382 ----
      else argv0 = r->filename;

      nph = !(strncmp(argv0,"nph-",4));
+
+     if(*(r->filename) != ''/'')
+     	return log_scripterror(r, conf, FORBIDDEN,
+ 	                       "You need absolute path to cgi-bin");
+
+     if((perl_check = fopen(r->filename,"rb")) == NULL)
+         return log_scripterror(r, conf, FORBIDDEN,
+ 			       "Can not read cgi-bin program");
+
+     if(strncmp(fgets(bangline,19,perl_check),"#!/usr/bin/perl
-T",19))
+         return log_scripterror(r,conf, FORBIDDEN,
+ 	                       "We only allow Perl cgis w/ taint check");

      if (!(allow_options (r) & OPT_EXECCGI) && !is_scriptaliased
(r))
  	return log_scripterror(r, conf, FORBIDDEN,

On Mon, 8 Jun 1998, Stephen Costaras wrote:
>
> I''m in the process of locking down as much of my systems here
> as possible as to available ports.  I am down to only a handful
> but am not sure how much of a security risk they pose and was
> wondering if anyone here might be able to comment, or suggest
> secure versions to run:
>
> 21/FTP        (WU-ftpd v2.4.2 BETA 14)
> 22/SSH        (1.22)
> 23/TELNET     (Netkit 0.09)
> 25/SMTP       (Sendmail v8.8.7)
> 49/TACACS     (TACACS_Plus v4.0.2 BETA/Cisco)
> 53/DNS        (BIND v8.1.2)
> 80/HTTP       (Apache v1.2.6 - upgrading to v1.3.0)
> 110/POP3      (Katie Steven''s v1.016)
> 111/RPC       (Netkit 0.09)
> 113/IDENTD    (????)
> 669/MOUNTD    (RPC/Linux Userspace NFS server v2.2beta29)
> 2049/NFS      (RPC/Linux Userspace NFS server v2.2beta29)
> 6669/APCUPSD  (UPS Monitoring, read-only from UPS server, already sent
>                  letter to author for security info).
The most non-secure services are the r services, and those aren''t much
at
risk if you''re not running a version with security holes. But I
don''t see
why you would actualy need to run all of them. Ssh could replace telnet,
you don''t need identd unless you go on IRC, as for mail, you should
check
sendmail alternatives. Oh and firewalling ports is still the best
solution. Unless you need to NFS with someone across the country, you
should firewall it for outside users.






Patrick Lambert
----------------------------------------------------------------------
DarkElf Network SysAdmin                        http://www.darkelf.net
OKC.OK.US.UnderNet.Org Operator                http://www.undernet.org
    Check the main resource for developers at www.fastethernet.net
----------------------------------------------------------------------

Hello!
> > 21/FTP        (WU-ftpd v2.4.2 BETA 14)
Sounds secure, but sniffable.
> > 22/SSH        (1.22)
Could replace telnet. Perhaps also ftp, but only between UNIX machines (I
think there isn''t a ''scp'' port for non-unix
OS''s).

Latest version is 1.2.23 and fixes some bugs.
> > 23/TELNET     (Netkit 0.09)
Good version, but sniffable service.
> > 25/SMTP       (Sendmail v8.8.7)
Could upgrade to sendmail 8.9.0 (and if you can, use tcp-wrapper to only
allow your main ''trusted'' mailhost of your subnet to send mail
to you).
> > 80/HTTP       (Apache v1.2.6 - upgrading to v1.3.0)
Nice idea to upgrade it ;)
> > 110/POP3      (Katie Steven''s v1.016)
I don''t know if that version is secure, but it''s a sniffable
service.

[Another reply to this mail :]
> The most non-secure services are the r services, and those aren''t
much at
> risk if you''re not running a version with security holes. But I
don''t see
> why you would actualy need to run all of them. Ssh could replace telnet,
> you don''t need identd unless you go on IRC, as for mail, you
should check
> sendmail alternatives. Oh and firewalling ports is still the best
> solution. Unless you need to NFS with someone across the country, you
> should firewall it for outside users.
Nothing to say about your advices, but encourage people to use identd
whenever it''s possible. It''s always nice to know which remote
user is
trying to access your system. In case of problem you know how to point
your finger at ;) I think it''s possible to fool that service, but...

The best solution when you''re worried with sniffers is to use as much
encrypted services as possible (either SSH or SSL), the problem is that
Winblows/DOS/Mac haven''t got much ports of those utilities. For
example, I
think there''s an SSL version of the pop3 server, but you won''t
be able to
find a SSLPOP3 client for windows (AFAIK). I think that Unix systems to be
more and more secure, but to be "windows compatible" we must use
stupid-non secure protocols :(

Greetings,

							Sergio

PS:Please excuse my english :)

On Tue, 9 Jun 1998, A Dark Elf wrote:
> On Mon, 8 Jun 1998, Stephen Costaras wrote:
> > 21/FTP        (WU-ftpd v2.4.2 BETA 14)
> > 22/SSH        (1.22)
> > 23/TELNET     (Netkit 0.09)
> > 25/SMTP       (Sendmail v8.8.7)
> > 49/TACACS     (TACACS_Plus v4.0.2 BETA/Cisco)
> > 53/DNS        (BIND v8.1.2)
> > 80/HTTP       (Apache v1.2.6 - upgrading to v1.3.0)
> > 110/POP3      (Katie Steven''s v1.016)
> > 111/RPC       (Netkit 0.09)
> > 113/IDENTD    (????)
> > 669/MOUNTD    (RPC/Linux Userspace NFS server v2.2beta29)
> > 2049/NFS      (RPC/Linux Userspace NFS server v2.2beta29)
> > 6669/APCUPSD  (UPS Monitoring, read-only from UPS server, already sent
> >                  letter to author for security info).
>
> The most non-secure services are the r services, and those aren''t
much at
> risk if you''re not running a version with security holes. But I
don''t see
> why you would actualy need to run all of them. Ssh could replace telnet,
Agreed, unless you happen to field a lot of Wintel boxes and no-one wants
to spring for F-Secure.
> you don''t need identd unless you go on IRC
Ummm ... A lot of sites are set to interrogate your identd server when you
access them for (mail|ftp|telnet|etc). It makes a good first defense
against various ''badness''.
> Oh and firewalling ports is still the best
> solution. Unless you need to NFS with someone across the country, you
> should firewall it for outside users.
Generally sound advise.

--
"Frankly, Agent Mulder, alien abduction is the more believable
option."
			Agent Skinner, X-Files, 3/09/98 [paraphrase]
-- John E. Jasen  // DNRC Ambassador to Earth \\  jjasen1@umbc.edu --
-- My views are those of the DNRC only. Prepare to be domesticated --

> > > 22/SSH        (1.22)
>
> Could replace telnet. Perhaps also ftp, but only between UNIX machines (I
> think there isn''t a ''scp'' port for non-unix
OS''s).
>
> Latest version is 1.2.23 and fixes some bugs.
>
> > > 23/TELNET     (Netkit 0.09)
>
> Good version, but sniffable service.
>
JUST CLOSE TELNET SERVICE!
Force your users to use ssh - there are already 2 clients for windows,
aik: SecureCRT and SSH for Windows.


> > > 25/SMTP       (Sendmail v8.8.7)
>
> Could upgrade to sendmail 8.9.0 (and if you can, use tcp-wrapper to only
> allow your main ''trusted'' mailhost of your subnet to send
mail to you).
Replace Sendmail with QMAIL:
qmail is a modern replacement for sendmail, written by Dan Bernstein.
qmail is proven to be more secure than Sendmail, and much faster.

It is an excellent mail host, in many ways superior to Sendmail (and not
in some others). Its main reasons for use are:

Ease of maintenance
Ease of building spam-free mail spools
Support for Maildirs
Very advanced queue management
Reliability over NFS
Speed & memory footprint
Great support from the qmail community

http://www.qmail.org
> > > 110/POP3      (Katie Steven''s v1.016)
>
> I don''t know if that version is secure, but it''s a
sniffable service.
Also replace with qmail''s pop3d.

> Nothing to say about your advices, but encourage people to use identd
> whenever it''s possible. It''s always nice to know which
remote user is
> trying to access your system. In case of problem you know how to point
> your finger at ;) I think it''s possible to fool that service,
but...
It''s trivial to write a spoofing identd.  (The protocol is extremely
simple, and the IDENT server is taken at its word.)
> The best solution when you''re worried with sniffers is to use as
much
> encrypted services as possible (either SSH or SSL), the problem is that
> Winblows/DOS/Mac haven''t got much ports of those utilities. For
example, I
F-Secure wrote a (shareware?) ssh for Windows.  I think there may also
be a free port somewhere.

Another option along these lines is Kerberos v4; a fair amount of unix
software supports it (though you need to apply patches in some cases),
and there are ktelnet and kpop clients for MacOS and Windows.
(Unfortunately, the only working Kerberized telnet client for Windows
AFAIK is a commercial product called Host Explorer.)

--
Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)

John \"E.R.\" Jasen enscribed thusly:
> On Tue, 9 Jun 1998, A Dark Elf wrote:
> > On Mon, 8 Jun 1998, Stephen Costaras wrote:
> > > 21/FTP        (WU-ftpd v2.4.2 BETA 14)
> > > 22/SSH        (1.22)
> > > 23/TELNET     (Netkit 0.09)
> > > 25/SMTP       (Sendmail v8.8.7)
> > > 49/TACACS     (TACACS_Plus v4.0.2 BETA/Cisco)
> > > 53/DNS        (BIND v8.1.2)
> > > 80/HTTP       (Apache v1.2.6 - upgrading to v1.3.0)
> > > 110/POP3      (Katie Steven''s v1.016)
> > > 111/RPC       (Netkit 0.09)
> > > 113/IDENTD    (????)
> > > 669/MOUNTD    (RPC/Linux Userspace NFS server v2.2beta29)
> > > 2049/NFS      (RPC/Linux Userspace NFS server v2.2beta29)
> > > 6669/APCUPSD  (UPS Monitoring, read-only from UPS server, already
sent
> > >                  letter to author for security info).
> > The most non-secure services are the r services, and those
aren''t much at
> > risk if you''re not running a version with security holes. But
I don''t see
> > why you would actualy need to run all of them. Ssh could replace
telnet,
> Agreed, unless you happen to field a lot of Wintel boxes and no-one wants
> to spring for F-Secure.
	There are freeware ssh clients for Windows 95/NT and now freeware
ssh servers (including a shell) for Windows NT (I don''t think the
server
runs on 95 - fortunately...).
> > you don''t need identd unless you go on IRC
> Ummm ... A lot of sites are set to interrogate your identd server when you
> access them for (mail|ftp|telnet|etc). It makes a good first defense
> against various ''badness''.
	Identd aka auth is spoofable / forgeable on a box you have control.
For that reason, nobody generally "relies" on it, even though there
are
plenty of services which inquire upon it.  The biggest problem is making
sure you return SOMETHING for it.  If you don''t want to run it, make
sure
you return an ICMP port unreachable or some such.  Lot''s of times
firewalls
will just drop unwanted stuff on the floor to avoid revealing anything about
any of the systems behind them.  If you don''t want to support identd
and
don''t want to return network host information to "error
probes" then return
a uniform error on that port for any address in your address space.  Otherwise,
every time you send an E-Mail message, the smtp server at the other end
will try and contact your ident server and have to time out.  That introduces
rediculous delays in mail delivery.
> > Oh and firewalling ports is still the best
> > solution. Unless you need to NFS with someone across the country, you
> > should firewall it for outside users.
> Generally sound advise.
	Absolutely, with the ident proviso above...
> --
> "Frankly, Agent Mulder, alien abduction is the more believable
option."
> 			Agent Skinner, X-Files, 3/09/98 [paraphrase] 
> -- John E. Jasen  // DNRC Ambassador to Earth \\  jjasen1@umbc.edu --
> -- My views are those of the DNRC only. Prepare to be domesticated --
	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

According to Aaron M. Ucko:
> F-Secure wrote a (shareware?) ssh for Windows.  I think there may also
> be a free port somewhere. 
Announced yesterday evening:

  From: roc+@cs.cmu.edu (Robert O''Callahan)
  Subject: free SSH client for Windows, with source
  Date: Mon Jun 08 23:38:56 CEST 1998
  Organization: Carnegie Mellon University
  
  I''ve created an extension to the excellent free (with source) telnet
  client Teraterm Pro 2.3. This extension provides basic SSH functionality
  --- ciphers, password/RSA/rhosts/rhosts+RSA authentication, compression,
  ssh_known_hosts. It does port forwarding too, but that''s a bit flaky.
This
  extension is free, the source is available, and it was developed while
  I was in Australia, and istherefore exportable all over. I hope it meets
  some people''s needs, but it mainly meets mine :-).
  
  http://www.zip.com.au/~roca/ttssh.html
  
  PS: I''m back in the US now, so no bugs can be fixed until I get out
again
  (November?), unless an overseas maintainer appears. sorry!

Mike.
-- 
 Miquel van Smoorenburg | Our vision is to speed up time,
    miquels@cistron.nl  |   eventually eliminating it.

On Tue, 9 Jun 1998, Linux Mailing Lists wrote:
> The best solution when you''re worried with sniffers is to use as
much
> encrypted services as possible (either SSH or SSL), the problem is that
> Winblows/DOS/Mac haven''t got much ports of those utilities. For
example, I
> think there''s an SSL version of the pop3 server, but you
won''t be able to
> find a SSLPOP3 client for windows (AFAIK). I think that Unix systems to be
> more and more secure, but to be "windows compatible" we must use
> stupid-non secure protocols :(
Most of the popular windows email clients support SSL - Netscape Messenger
has IMAP/SSL, MS Outlook - POP3/SSL. You can setup a SSL servers for those
services with quite small effort using wrapper like stunnel 
(http://mike.daewoo.com.pl/computer/stunnel/). stunnel performs the initial
SSL handshake with the client, calls the original non-SSL daemon and works
as encrypting proxy between them. For linux I have prepared a SSL enabled
fetchmail version (ftp://ftp.ceti.com.pl/pub/linux/), but tunneling over
SSH would be probably more efficient.

--
Pawel Krawczyk, CETI internet, Krakow. http://www.ceti.com.pl/
info: oferta@ceti.com.pl.  Home: http://ceti.com.pl/~kravietz/

"SC" == Stephen Costaras <stevecs@chaven.com> writes:

SC> 669/MOUNTD    (RPC/Linux Userspace NFS server v2.2beta29)

It should be noted that this service (as with most RPC services) does
not have a single "established" port.  It just happens to be on 669
today, on your box.

--Up.

Andrew Frolov (dron@ilm.net) wrote:
> JUST CLOSE TELNET SERVICE!
> Force your users to use ssh - there are already 2 clients for windows, 
> aik: SecureCRT and SSH for Windows.
I wish there would be.

AFAIK SecureCRT is in semi-public beta (download for U.S. citizens
only), and the free ssh for windows client is a proof of concept
implementation at best. Slow and painfull.

There definitely is a strong need for a free and powerfull ssh-Client for
Windows (and probably MacOS), just as we need a nice looking GUI-client
doing something like ftp, only with encryption (for passwords at least).
Not for us Real Men[tm], but for the lusers that force us to keep
those sniffable services running. Or would you like to tell your
customers to install a real OS only to be able to update their webpages?

Might be a nice opportunity for a startup software company to get into
the heads of gazillions of Internet-Users, did I hear somebody say
''Telnetscape'' ? ;)

> > > > 110/POP3      (Katie Steven''s v1.016)
> > 
> > I don''t know if that version is secure, but it''s a
sniffable service.
Are there any ssl-based replacements for pop/imap in the works? Or any
other cryptographical correct approach?

regards,
Bernhard

Stephen Costaras writes:
> 
> I''m in the process of locking down as much of my systems here
> as possible as to available ports.  I am down to only a handful
> but am not sure how much of a security risk they pose and was
> wondering if anyone here might be able to comment, or suggest
> secure versions to run:
> 
> 21/FTP        (WU-ftpd v2.4.2 BETA 14)
> 23/TELNET     (Netkit 0.09)
Replace unencrypted telnet with telnet-98.02.16, which supports
strong encryption via either SRP or Kerberos.  Run telnetd with
the "-a valid" option in inetd, which will permit only secure
connections to succeed.  The same applies to secure, SRP-enabled
FTP.  Windows and Linux clients/servers are at
<http://srp.stanford.edu/srp/>.
-- 
Tom Wu                        * finger -l tjw@xenon.stanford.edu for PGP key *
 E-mail: tjw@cs.Stanford.EDU          "The box said ''Requires
Windows 95, NT,
  Phone: (650) 725-6969                   or better,'' so I installed
Linux."
   http://www-cs-students.stanford.edu/~tjw/   http://srp.stanford.edu/srp/

> I''m in the process of locking down as much of my systems here
> as possible as to available ports.  I am down to only a handful
> but am not sure how much of a security risk they pose and was
> wondering if anyone here might be able to comment, or suggest
> secure versions to run:
> 
> 21/FTP        (WU-ftpd v2.4.2 BETA 14)
> 22/SSH        (1.22)
> 23/TELNET     (Netkit 0.09)
> 25/SMTP       (Sendmail v8.8.7)
> 49/TACACS     (TACACS_Plus v4.0.2 BETA/Cisco)
> 53/DNS        (BIND v8.1.2)
> 80/HTTP       (Apache v1.2.6 - upgrading to v1.3.0)
> 110/POP3      (Katie Steven''s v1.016)
> 111/RPC       (Netkit 0.09)
> 113/IDENTD    (????)
> 669/MOUNTD    (RPC/Linux Userspace NFS server v2.2beta29)
> 2049/NFS      (RPC/Linux Userspace NFS server v2.2beta29)
> 6669/APCUPSD  (UPS Monitoring, read-only from UPS server, already sent
>                  letter to author for security info).
> 
> On servers that have no need for the above ports (ie, telnet, tacacs, pop3,
> et al) they are disabled.  My main concerns are based on the assumption
> that someone might gain access to the local subnet, which protocols
> would be sniffable/hackable/et al?
Whats perhaps more important is to make sure your running tcpd and
have firewalling in place, such as ipfwadm ... so only trusted machines
may connect to you. 

Then look at the services your running, although thats about a minimal
list, except more upto date daemons.

I generally turn off Ident.
-- 

 --------------------------------------------------------------------------
 <a
href="mailto:darren@kedemel.demon.co.uk">darren@kedemel.demon.co.uk</a>
 PGP DSS/DH 1024/1024 public Key ID 0xF0AE2B5F.

-----Original Message-----
From: Andrew Frolov <dron@ilm.net>
To: linux-security@redhat.com <linux-security@redhat.com>
Date: Tuesday, June 09, 1998 8:54 AM
Subject: [linux-security] Re: Services not required?

>> > > 22/SSH        (1.22)
>>
>> Could replace telnet. Perhaps also ftp, but only between UNIX machines
(I
>> think there isn''t a ''scp'' port for non-unix
OS''s).
>>
>> Latest version is 1.2.23 and fixes some bugs.
>>
>> > > 23/TELNET     (Netkit 0.09)
>>
>> Good version, but sniffable service.
>>
>
>JUST CLOSE TELNET SERVICE!
>Force your users to use ssh - there are already 2 clients for windows,
>aik: SecureCRT and SSH for Windows.

Unfortunately we have Cisco 2511''s used for terminal servers (dialup
modems).  Not all clients can use PPP so some have to be able to telnet
into the system from the Cisco''s.  I have not been able to find
anything
that would offer a secure channel from the Cisco''s to the Unix host
(like
a ssh for the Cisco''s).  If something like that was available I would
disable telnet in a second.

All ''r'' services have long been disabled and removed from the
systems.
so the only remote holes are the ones that I listed before (or whatever
can go across those ports).

Someone mentioned a SSL version of POP3, does a SSL POP3d exist for Linux?
Anyone know the url?

Also, NFS, does anyone know if secureNFS was ever ported to Linux?

Sendmail I''m in the process of upgrading to 8.9, I looked at Qmail and
others but am not yet comfortable that they are as robust as sendmail is.
True sendmail has been hacked a bit in the past, but the fact that it has
been hacked lets me know that those holes were patched.  Qmail has not
been hacked (that I know of) and that gets me a little edgy.  I don''t
know
of any system that is 100bug free.

Steve

Bernhard Weisshuhn wrote:
> Are there any ssl-based replacements for pop/imap in the works? Or any
> other cryptographical correct approach?
wrapssl and edssl can be used to wrap a standard IMAP or POP daemon
launched from inetd.

I tried both.  I had better luck with wrapssl than edssl.  wrapssl
seemed to work, but netscape''s SSL imap may be flakey - netscape died
on
me consistently when trying to use SSL imap - but the same (large
collection of) folders worked fine with imap but without the SSL.

This was with suns, BTW.

Bernhard Weisshuhn enscribed thusly:
> Andrew Frolov (dron@ilm.net) wrote:
> > JUST CLOSE TELNET SERVICE!
> > Force your users to use ssh - there are already 2 clients for windows,
> > aik: SecureCRT and SSH for Windows.
> I wish there would be.
> AFAIK SecureCRT is in semi-public beta (download for U.S. citizens
> only), and the free ssh for windows client is a proof of concept
> implementation at best. Slow and painfull.
	You must not be looking very hard.  I believe there are at least
three ssh clients for Windows, not just the original one that I believe
you are referring to.  At least one ssh package for Windows includes
an ssh server.  I believe that''s the package that''s come out
of the GNU
Win32 project.
> There definitely is a strong need for a free and powerfull ssh-Client for
> Windows (and probably MacOS), just as we need a nice looking GUI-client
> doing something like ftp, only with encryption (for passwords at least).
> Not for us Real Men[tm], but for the lusers that force us to keep
> those sniffable services running. Or would you like to tell your
> customers to install a real OS only to be able to update their webpages?
> Might be a nice opportunity for a startup software company to get into
> the heads of gazillions of Internet-Users, did I hear somebody say
> ''Telnetscape'' ? ;)
> > > > > 110/POP3      (Katie Steven''s v1.016)
> > > 
> > > I don''t know if that version is secure, but
it''s a sniffable service.
> Are there any ssl-based replacements for pop/imap in the works? Or any
> other cryptographical correct approach?
	There is a port designation for imaps (SSL IMAP), 993, and pop3s
(SSL POP3), 994.  I do know from first hand experience that both Netscape
and MS Outlook support SSL IMAP natively.  AFAIK neither support pop over
SSL.  I''ve set up a couple of SSL IMAP servers by using edssl to map
from
SSL IMAP on port 993 over to the IMAP server on port 143.  You can map
any tcp connection through SSL using eassl on the client side and edssl on
the server side.  The tricky part is getting a server certificate for edssl.
Verisign doesn''t have a clue if it doesn''t have anything to
due with https
and a web server.
> regards,
> Bernhard
	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

[mod: Sorry for the moderation backlog. I''m uptodate again now. There
have been a bunch of posts naming ways to get an encrypted login on a
unix server from windows clients. I''ve just grabbed the URLs that
people named and put them below:

http://www.doc.ic.ac.uk/~ci2/ssh/ 
http://cannibal.mi.org/~tawollen/computer.html
http://www.cs.hut.fi/ssh
http://www.pdc.kth.se/kth-krb/
http://www.vandyke.com/download/beta/SecureCRT/index.html
http://www.europe.datafellows.com/f-secure/fclintp.htm
ftp://ftp.pdc.kth.se/pub/krb/binaries/i386-unknown-winnt4.0/krb4-gui-980226.zip
ftp://ftp.pdc.kth.se/pub/krb/src/krb4-0.9.9.tar.gz
http://srp.stanford.edu/srp/
ftp://ftp.funet.fi/pub/unix/security/login/nrl-opie

Regards, Roger ]

On Tue, 9 Jun 1998, Michael H. Warfield wrote:
> > Agreed, unless you happen to field a lot of Wintel boxes and no-one
wants
> > to spring for F-Secure.
> 
> 	There are freeware ssh clients for Windows 95/NT and now freeware
> ssh servers (including a shell) for Windows NT (I don''t think the
server
> runs on 95 - fortunately...).
Unfortunately, this doesn''t address the patent licensing issues for
RSA, and
getting the license for running the code to connect, say to a box at 
work, generally costs more than the cost of the commercial clients.  

If however, any of the Freeware clients do only DH/IDEA/3DES, I''d like
to hear
from someone with a URL, because as long as RSA wants such idiotic fees for 
the algorithms, I''ll stay right the heck away from it, and I even
bought
RSAREF.
> will try and contact your ident server and have to time out.  That
introduces
> rediculous delays in mail delivery.
SMTP isn''t exactly a real-time protocol, and SMTP servers
aren''t required
to answer to IDENT queries, if you run IDENT requests, then you should be 
able to live with the extra socket lifetime on your server, just as I 
should if I don''t wish to respond with an RST and I send you mail.  Two
days could be considered a ridiculous delay in SMTP, a few seconds 
to a few minutes shouldn''t be.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts@clark.net      which may have no basis whatsoever in fact."
                                                                     PSB#9280

On 10 Jun 1998 tjw@CS.Stanford.EDU wrote:
> 
> Replace unencrypted telnet with telnet-98.02.16, which supports
> strong encryption via either SRP or Kerberos.  Run telnetd with
> the "-a valid" option in inetd, which will permit only secure
> connections to succeed.  The same applies to secure, SRP-enabled
> FTP.  Windows and Linux clients/servers are at
> <http://srp.stanford.edu/srp/>.
I don''t believe I''ve seen OPIE mentioned in the discussion. 
The
OPIE suite includes an ftp server (although not as full-featured
as wu-ftp), as well as a replacement login program.  An example
client is included that gives enough of an example to let me hack
it into a pop server (although it''s not by any means the easiest
thing to use from the user''s perspective).

And there is a pass-phrase ''calculator'' for windows clients.

It''s available at ftp://ftp.funet.fi/pub/unix/security/login/nrl-opie ,
and the official site is ftp://ftp.nrl.navy.mil/pub/security/opie ... but
I''ve never been able to get the latter site to work.

-ps

--
Paul Schmidt          <  ><               PSchmidt at Custom dot Net
Amateur Radio K9PS     ARRL Life Member     QCWA Life Member (26711)
Bloomfield, IN USA    Linux 2.0.34   web:viaduct.custom.net/pschmidt 
PGP 2.6 fingerprint: 24 9F D3 BD AE E3 50 72 23 AB A0 64 BB 9E 2B 8D

On Tue, 9 Jun 1998, Michael H. Warfield wrote:
> John \"E.R.\" Jasen enscribed thusly:
> > Ummm ... A lot of sites are set to interrogate your identd server when
you
> > access them for (mail|ftp|telnet|etc). It makes a good first defense
> > against various ''badness''.
> 
> 	Identd aka auth is spoofable / forgeable on a box you have control.
> For that reason, nobody generally "relies" on it, even though
there are
> plenty of services which inquire upon it.  The biggest problem is making
> sure you return SOMETHING for it.  If you don''t want to run it,
make sure
> you return an ICMP port unreachable or some such.
identd/auth is a great start to catching all the people who make stupid or
''newbie'' mistakes while committing badness. [People just
discovering how
to forge mail come to mind.]

--
"Frankly, Agent Mulder, alien abduction is the more believable
option."
			Agent Skinner, X-Files, 3/09/98 [paraphrase] 
-- John E. Jasen  // DNRC Ambassador to Earth \\  jjasen1@umbc.edu --
-- My views are those of the DNRC only. Prepare to be domesticated --

On Thu, 11 Jun 1998, Michael H. Warfield wrote:
> John \"E.R.\" Jasen enscribed thusly:
> 
> > On Tue, 9 Jun 1998, A Dark Elf wrote:
> 
> > Ummm ... A lot of sites are set to interrogate your identd server when
> > you access them for (mail|ftp|telnet|etc). It makes a good first
defense
> > against various ''badness''.
> 
> Identd aka auth is spoofable / forgeable on a box you have control.
> For that reason, nobody generally "relies" on it, even though
there are
> plenty of services which inquire upon it.  The biggest problem is making
> sure you return SOMETHING for it.  If you don''t want to run it,
make sure
> you return an ICMP port unreachable or some such.  Lot''s of times 
> firewalls will just drop unwanted stuff on the floor to avoid revealing
> anything about any of the systems behind them.  If you don''t want
to
> support identd and don''t want to return network host information
to "error
> probes" then return a uniform error on that port for any address in
your
> address space. Otherwise, every time you send an E-Mail message, the smtp
> server at the other end will try and contact your ident server and have to
> time out.  That introduces rediculous delays in mail delivery.
Another ''gotchya'' to be aware of:
I tried using ipfwadm as follows:

/sbin/ipfwadm -I -a reject -P tcp -S 0.0.0.0/0 -D a.b.c.d/32 113

When an outside server decided it wanted to check my ident daemon, it
attempts a connection, and the Linux packet filtering code  sent back a
''host administratively unreachable'' packet (ICMP type 3,
sub-type 10,
iirc).  This in itself seems okay, apart from two things:

1) You are blatantly advertising the firewalling.

2) Certain OS''s don''t recognise the packet - I am informed
that certain
versions of SunOS simply ignore the packet completely, and therefore
re-send the SYN packet until the TCP session times out - exactly what
we''re trying to avoid.

Number 2 comes from experience of trying to email a DNS change to
auto-net@nic.uk, and puzzling why it wouldn''t ever leave my machine. 
In
the end, with assistance from a technician at Nominet, we figured it out.
Now, I just have it dropped completely - my attempt at being
''polite'' to
other mail servers seemed to simply cause more problems.

Just thought I''d share, hope that''s of some use to the
discussion.


Ian.

--
Ian Marsh
mushypea@dominion.net.uk                                   ... Email
http://www.etchq.demon.co.uk/                              ... WWW
http://www.dominion.net.uk/ telnet://dominion.net.uk:2468/ ... Dominion
http://www.alpha4.com/      telnet://alpha4.com:3214/      ... MBa4

Dan Siemon writes:
> 
> I am interested in a comparison of Telnet98(SRP) with SSH. Advantages?
> Disadvantages? How secure is it? Why use it instead of SSH?
> 
> Tom Wu wrote:
> > 
> > Replace unencrypted telnet with telnet-98.02.16, which supports
> > strong encryption via either SRP or Kerberos.  Run telnetd with
> > the "-a valid" option in inetd, which will permit only
secure
> > connections to succeed.  The same applies to secure, SRP-enabled
> > FTP.  Windows and Linux clients/servers are at
> > <http://srp.stanford.edu/srp/>.
Advantages:

- SRP is not susceptible to the MITM attack against SSH even if the
  two hosts have never executed the SSH protocol before.
- SRP gives security equivalent to SSH''s stored RSA key authentication
  (e.g. zero knowledge, perfect forward secrecy) with standard passwords
  and without client-side stored keys.
- SRP, in effect, solves the bootstrapping problem by leveraging a
  low-entropy secret (the password) into a high-entropy session key
  without being susceptible to dictionary attacks the way Kerberos,
  S/Key, and challenge-response protocols are.
- SRP is a pure authentication protocol, which uses no encryption to
  establish initial authentication.  Thus it is not subject to export
  restrictions.  Strength of the authentication is independent of the
  strength of the session cipher.  With perfect forward secrecy, even
  giving up the session key does not allow a dictionary attack against
  the password.  With SSH and Unix passwords, OTOH, compromising the
  session key compromises the plaintext password.
- Since authentication and encryption are orthogonal, one can, for
  example, export full-strength SRP from the US with 40-bit session
  crypto.

Disadvantages:

- Protocol is newer than RSA; it has only been widely known since mid-
  1997 and was published earlier this year.
- Fewer clients and servers support it... so far.  For example, a
  Mac client still needs to be written.  Wider awareness is probably
  the best way to rectify that situation.

The telnet98 source code is publicly available for scrutiny, of course,
and I would be willing to help get the patches into the NetKit telnet
for RedHat and other Linux distributions.  SRP is a simple Telnet
auth protocol extension, a la RFC 1416, so it is autonegotiated
like any other Telnet option; it would be nice to have a single
"super-telnet" binary that supported all the auth options and
servers that autodetected what mechanisms were supported at run
time.

Linux PAM modules are also available to handle the new Exponential
Password File Format, see <http://srp.stanford.edu/srp/> to download
them.
-- 
Tom Wu                        * finger -l tjw@xenon.stanford.edu for PGP key *
 E-mail: tjw@cs.Stanford.EDU          "The box said ''Requires
Windows 95, NT,
  Phone: (650) 725-6969                   or better,'' so I installed
Linux."
   http://www-cs-students.stanford.edu/~tjw/   http://srp.stanford.edu/srp/

On Tue, 9 Jun 1998, Michael H. Warfield wrote:
> > Ummm ... A lot of sites are set to interrogate your identd server when
you
> > access them for (mail|ftp|telnet|etc). It makes a good first defense
> > against various ''badness''.
> 
> 	Identd aka auth is spoofable / forgeable on a box you have control.
> For that reason, nobody generally "relies" on it, even though
there are
> plenty of services which inquire upon it.  
The problem is really that people attemt to use identd for things it is
not meant to solve. It is there for logging purposes, not for
authentication purpoes. It can be used for authentication from trusetd
machines (i.e. ones where the users are believed not to become root or the 
equivalent). It is as trustworthy as the machine it is running on.

Identd is a very good way for us to find out which of our users who has
been misbehaving. 

Peter
--
Peter Svensson      ! Pgp key available by finger, fingerprint:
<petersv@df.lth.se> ! 8A E9 20 98 C1 FF 43 E3  07 FD B9 0A 80 72 70 AF
------------------------------------------------------------------------
Remember, Luke, your source will be with you... always...

In message <Pine.LNX.3.96.980611145912.13628A-100000@limbo.alpha4.com>, 
MushyPe
a writes:
+-----
| 1) You are blatantly advertising the firewalling.
| 
| 2) Certain OS''s don''t recognise the packet - I am informed
that certain
| versions of SunOS simply ignore the packet completely, and therefore
| re-send the SYN packet until the TCP session times out - exactly what
| we''re trying to avoid.
+--->8

3) Older Ultrix, and possibly some other OSes, will drop *all* connections 
to the host upon receiving such a packet.

In any case, I use "-a deny" instead.

[mod: One such "Other OS" is HPUX. -- REW]

-- 
brandon s. allbery	   [team os/2][linux][japh]	 allbery@kf8nh.apk.net
system administrator, ece facilities			   allbery@ece.cmu.edu
carnegie mellon university			   (bsa@kf8nh is still valid.)

On Thu, 11 Jun 1998 15:17:12 +0100 (BST), 
MushyPea <mushypea@dominion.net.uk> wrote:
>When an outside server decided it wanted to check my ident daemon, it
>attempts a connection, and the Linux packet filtering code  sent back a
>''host administratively unreachable'' packet (ICMP type 3,
sub-type 10,
>iirc)... Certain OS''s don''t recognise the packet
And worse, some old OS''s incorrectly handle host unreachable or
administratively denied.  Instead of giving up on just the ident
handshake, they give up on *all* connections to your machine.  So you
end up with

 You start to send mail, port SMTP.
 They ident you.
 You reject ident with ICMP.
 They incorrectly hang up all sessions, including SMTP.
 You retry sending mail.
 They ident you ... repeat ad nauseum.

I found it better to allow ident through the firewall and just not run
the ident service.  Immediate TCP RST instead of ICMP, seems to work
for everything.

On Tue, Jun 09, 1998 at 05:57:24PM -0500, Stephen Costaras
wrote:
> Unfortunately we have Cisco 2511''s used for terminal servers
(dialup
> modems).  Not all clients can use PPP so some have to be able to telnet
> into the system from the Cisco''s.  I have not been able to find
anything
> that would offer a secure channel from the Cisco''s to the Unix
host (like
> a ssh for the Cisco''s).  If something like that was available I
would
> disable telnet in a second.
Recent IOSes support some encrypted remote access support (but probably
proprietary). Another way is to connect your Cisco to a SSH enabled machine
by serial cable and use minicom ;)
> Someone mentioned a SSL version of POP3, does a SSL POP3d exist for Linux?
> Anyone know the url?
See http://mike.daewoo.com.pl/computer/stunnel/

-- 
Pawel Krawczyk, CETI internet, Krakow. http://www.ceti.com.pl/
info: oferta@ceti.com.pl.  Home: http://ceti.com.pl/~kravietz/

http://www.seifried.org/http/

Any votes on what to write next?

Chrooting:
Apache-SSL
cgi-bin stuff (perl, bash, etc)
DHCPD
IDENTD/giving canned replies.
User shell accounts
Sendmail/POP/IMAP (you''ll have to wait for this one =)

Programs:
Script(s) to chroot named (in the works)
Script(s) to chroot apache/setup user dirs, etc. (in the works)

Other suggestions/comments?

-seifried

Howdy there to all !!! :)
Greeting from Italy.

MushyPea wrote:
> On Thu, 11 Jun 1998, Michael H. Warfield wrote:
>
[snip...]
> > Identd aka auth is spoofable / forgeable on a box you have control.
> > For that reason, nobody generally "relies" on it, even
though there are
> > plenty of services which inquire upon it.  The biggest problem is
making
> > sure you return SOMETHING for it.  If you don''t want to run
it, make sure
> > you return an ICMP port unreachable or some such.  Lot''s of
times
> > firewalls will just drop unwanted stuff on the floor to avoid
revealing
> > anything about any of the systems behind them.  If you don''t
want to
> > support identd and don''t want to return network host
information to "error
> > probes" then return a uniform error on that port for any address
in your
[snip...]
> Another ''gotchya'' to be aware of:
> I tried using ipfwadm as follows:
>
> /sbin/ipfwadm -I -a reject -P tcp -S 0.0.0.0/0 -D a.b.c.d/32 113
>
> When an outside server decided it wanted to check my ident daemon, it
> attempts a connection, and the Linux packet filtering code  sent back a
> ''host administratively unreachable'' packet (ICMP type 3,
sub-type 10,
> iirc).  This in itself seems okay, apart from two things:
>
> 1) You are blatantly advertising the firewalling.
Sure, unless you decide to replace the ipfwadm line above with this one:

/sbin/ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D a.b.c.d/32 113

This will not generate an icmp message.
> 2) Certain OS''s don''t recognise the packet - I am
informed that certain
> versions of SunOS simply ignore the packet completely, and therefore
> re-send the SYN packet until the TCP session times out - exactly what
> we''re trying to avoid.
Since you deny that service (identd in our example) you can also run a little
daemonthat opens a raw socket and wait for tcp segment that will be delivered to
the identd service.
Once the segment is arrived on that raw socket, you can simple RST the
connection on the other side, so one will know neither if you have a
"simple" fw
running, nor if your identd service is down.

Well, This is only my humble opinion :), so feel free to give me some advices if
I''m in wrong
We learn always :)

Have a good time :)

Gigi Sullivan

P.S.
Uh, well .. I''d also like to apologize for my bad english.
---------------------------------------------------------------------------------------------

Linux is really CUTE: Cool User Text Environment :) enjoy yurself
>
>
> Number 2 comes from experience of trying to email a DNS change to
> auto-net@nic.uk, and puzzling why it wouldn''t ever leave my
machine.  In
> the end, with assistance from a technician at Nominet, we figured it out.
> Now, I just have it dropped completely - my attempt at being
''polite'' to
> other mail servers seemed to simply cause more problems.
>
> Just thought I''d share, hope that''s of some use to the
discussion.
>
> Ian.
>
> --
> Ian Marsh
> mushypea@dominion.net.uk                                   ... Email
> http://www.etchq.demon.co.uk/                              ... WWW
> http://www.dominion.net.uk/ telnet://dominion.net.uk:2468/ ... Dominion
> http://www.alpha4.com/      telnet://alpha4.com:3214/      ... MBa4
>
> --
> ----------------------------------------------------------------------
> Please refer to the information about this list as well as general
> information about Linux security at http://www.aoy.com/Linux/Security.
> ----------------------------------------------------------------------
>
> To unsubscribe:
>   mail -s unsubscribe linux-security-request@redhat.com < /dev/null