[Dshield] Who's doing what

Bruce Lilly blilly at erols.com
Sun Aug 12 18:53:56 GMT 2001


> Date: Sat, 11 Aug 2001 09:43:37 -0400 (EDT)
> From: "Johannes B. Ullrich" <jullrich at euclidian.com>
[...]
> - Home systems are notoriously unpatched and it is in my opinion
> unreasonable to expect my grandma to stay up to date on the latest
> patches. I think in this case, it should be the vendors (MSFT) and the
> ISPs duty to protect her system. FIREWALL MY GRANDMA ! FIREWALL HER GOOD!

A full firewall is not necessary and would likely not be cost-effective.
As many ISPs' terms of service prohibit individuals from operating
servers, simple port filtering in the dial-up routers could -- and
should -- be used.  However, this requires some level of expertise
on the part of the ISP's staff (as well as equipment that supports
packet filtering and implements it correctly).  Moreover, it may
appear to be against the financial interests of ISPs that charge
by the packet.

[...]
> I think the internet should be moving into a phase now where we stop
> running it from various garages and more treat it like what it has already
> become, a critical part of our infrastructure. After all, people would get
> very upset if nobody would care, or even know about, traffic rules.

TANIP -- There ain't no Internet Police.  Be careful what you wish for; you
may get it, along with the costs, abuses, and corruption that go with it.

The problem is that the OS, despite claims of compliance with high levels
of security, isn't really secure at all.  That raises more issues:
1. the criteria for being able to claim compliance with high levels of
   security are too lax (they do not reflect common installation
   conditions (indeed, DEFAULT installation conditions) and/or lack of
   professional administration).
2. again, there's no enforcement.  Microsoft can, and does, claim POSIX.1
   compliance; where's the fork() system call? where's unistd.h? where's
   SIGCLD?  Who independently evaluates claims of compliance? Who is
   prosecuting false claims of compliance?  Nobody.
3. What would you have? "Sorry, Grandma, your Windows 2000 OS isn't
   secure. You can't connect to the Internet via Secure ISP Inc."
   a. Fly-by-night ISP, LLC will gladly accept Grandma's money to
      connect her to the Internet, no questions asked.  Reality is
      that ISP's make it easy to connect Windows boxes to the
      Internet, and make it difficult if one runs other OSs.
   b. What's Grandma to do? Does she have any idea of what security
      means in the context of computing and/or the Internet? [can she
      afford to attend a SANS course (N.B. no smiley)? Even if she
      could and would, would she understand it?] Can she install and
      configure Linux? [do you think Linux is secure?] Can she install
      and configure Solaris? [do you think Solaris is secure?] Can she
      set up an Ethernet, connect a firewall box and Ethernet modem/
      bridge/router, configure and administer it?  Is she even willing
      to pay for the extra hardware? Can she even find it at her
      friendly neighborhood computer store?  Does the salesman at
      Friendly Neighborhood Computer Stores, LLC have any better idea
      of security than Grandma does? Or is he more interested in
      selling the hardware and OSs that deliver the biggest sales
      commissions and spiffs?
   c. Reality check. Do you think that Grandma, ignorant of security
      considerations, is going to pay $0.01/month more for the services
      of Secure ISP, Inc. than for Fly-by-night ISP, LLC?
   d. Who holds Fly-by-night ISP, LLC responsible when Grandma's PC
      starts attacking? What powers of enforcement do they have? What
      prevents Fly-by-night ISP, LLC from billing Grandma $500.00 for
      "administrative costs" and canceling Grandma's account (assuming
      their TOS prohibits port scanning)? Should they? If not, why not?

> Date: Sat, 11 Aug 2001 11:53:37 -0700
> From: John Groseclose <iain at caradoc.org>
[...]
> I'm beginning to think that the solution is to simply disconnect any 
> server that continues to show signs of infection. When the person 
> calls their ISP to find out what's going on, they can be "educated."

That would be nice, but even before this problem, many ISPs abuse staffs
were inadequate to the task; some take literally months to respond to
abuse reports.  Have you talk to any of the support staff at a mass-
market ISP lately? Do you have any reason to believe that they are any
better informed about the problem than their customers?
 
> I'm simply astounded that so many of these machines respond to port 
> 25 requests, but have *no* "postmaster" accounts, in plain violation 
> of RFCs. The only blame for *that* can be laid directly on Microsoft 
> for ignoring consensus.

Are you really astounded? Did you expect that Microsoft, convicted of
the most heinous of anti-trust violations, would pay attention to mere
RFCs?

There's no question that Microsoft is a villain.  In addition to the
issues you mention w.r.t. port 25, note that those systems also fail
to recognize their own domain literals, in violation of RFC 1123 (the
Host Requirements RFC!) section 5.2.17, and generate cruft such as:

Received: from cpecsqlx08 ([10.49.140.227]) by cpecimsz01 with Microsoft SMTPSVC(5.0.2172.1);
         Thu, 25 May 2000 11:58:08 -0700

That contains a large number of violations of a great many RFCs:
1. the 'from' clause is supposed to contain a fully-qualified domain.
   Violates RFC 1034 [3.1], RFC 1123 [5.2.18], RFC 2821 [3.6]
2. same for the 'by' clause
3. the 'with' clause must use only registered terms, and the only
   legal registered terms are "smtp" and "esmtp". Violates RFC 821
   [4.1.2], RFC 1700 (the Assigned Numbers RFC!) [MAIL TRANSMISSION TYPES],
   RFC 2821 [4.4].  Microsoft was slapped down years ago for the same
   sort of nonsense with some of their earlier products, and this one
   was reported to Microsoft well over a year ago. As of W2k SP2, it
   still hasn't been fixed.  Of course, RFC 821 was only issued a mere
   19 YEARS ago...
4. there must be a space character before the semicolon. Violates RFC 821
   [4.1.2]. Strictly speaking, the comments and line folding also
   violate RFC 821.
5. day-of-week is not permitted in the time stamp. Violates RFC 821 [4.1.2].
6. even under the very lax syntax rules of RFC 2822, that header cannot
   be parsed; the "SMTPSVC" appears as an item-name with no associated
   item-value: RFC 2822 [3.6.7].

The end result is that that header is absolutely useless for its primary
purpose, viz. "tracing mail routes" (RFC 1123 [5.2.8]). Even if one peeks
inside the comment in the 'from' clause, no insight is gained, since the
IP address there is a private use one.

Microsoft should be flayed in the technical press for these violations
as well as for the gaping security holes in IIS and Microsoft's lack of
timely and/or effective action in dealing with the issues.  Unfortunately,
much of the technical press is supported by advertising and in the conflict
of interest between advertising revenue and journalistic integrity, the
former almost always wins.

Unfortunately, the end result of Microsoft's ineptitude is likely to be
the lowering of standards.  Did you know that RFC 2822 no longer requires
a time stamp in the Received header (introduced in RFC 821 as the "time
stamp line"!), because "it was found that some implementations didn't generate 
date".  As in other areas, this sort of implicitly or explicitly condoned
violations of the rules of conduct is a very bad lesson in ethics; keen
observers are likely to conclude that the morals are "don't pay any attention
to the rules; nobody does" and "if you do as you please long enough, the
rules will be changed to accommodate your behavior".

Incidentally, for those wondering who the culprit responsible for the
atrocious Received header is, or for those who simultaneously want a
good laugh and a cry, here are the complete headers and the first 3
body lines of that message (note that the Date and Message-ID headers
also violate RFCs):

-------------------------------
Return-Path: <1support at microsoft.com>
Received: from mx02.mrf.mail.rcn.net ([207.172.4.51])
          by mta02.mrf.mail.rcn.net
          (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP
          id <20000525185736.NDHS9585.mta02.mrf.mail.rcn.net at mx02.mrf.mail.rcn.net>
          for <blilly at mta.mrf.mail.rcn.net>;
          Thu, 25 May 2000 14:57:36 -0400
Received: from mail2.one.microsoft.com ([207.46.140.172] helo=cpecimsz01)
        by mx02.mrf.mail.rcn.net with esmtp (Exim 2.12 #3)
        id 12v2p6-0000QC-00
        for blilly at erols.com; Thu, 25 May 2000 14:57:36 -0400
Received: from cpecsqlx08 ([10.49.140.227]) by cpecimsz01 with Microsoft SMTPSVC(5.0.2172.1);
         Thu, 25 May 2000 11:58:08 -0700
Date: Thu, 25 May 2000 18:55:10
From: 1support at microsoft.com
To: blilly at erols.com
Subject: Information You Requested From Microsoft.com
X-Priority: 3
Organization: Microsoft Highlander
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT
Content-description: Mail message body
X-Mailer: Highlander's MailExpress version 1.0
Status: RO
Message-ID: <CPECIMSZ01ZLNsaeaIh0000907b at cpecimsz01>
X-OriginalArrivalTime: 25 May 2000 18:58:08.0391 (UTC) FILETIME=[2A608970:01BFC67B]
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: <CPECIMSZ01ZLNsaeaIh0000907b at cpecimsz01>

NOTE: PLEASE DO NOT RESPOND DIRECTLY TO THIS E-MAIL. THIS E-MAIL IS NOT MONITORED.

Welcome to Microsoft Online ID secure Internet environment!
--------------------------------

"secure Internet environment" my ___.

And no, I am not a cynic; I am an optimist tempered by experience.




More information about the list mailing list