× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: A DoS Must Read from Steve Gibson...
  • From: "Sims, Ken" <KSIMS@xxxxxxxxxxxxxxxx>
  • Date: Mon, 25 Jun 2001 19:46:47 -0400

Hi Dan -

>You say that all operating systems have this capability, except for the
>previous versions of Windoze.  If your mother or your grandmother has a
>PC, is it running anything other than Windows?  It would seem that most
>Linux systems and other systems running non-Windoze OS's would be less
>vulnerable on the basis that they are being administered by
>technically-minded folk and would be more likely to be using a firewall.
>Therefore, your argument doesn't give me much comfort.

I didn't all say, I said most.

Based on things that I see in the firewalls newsgroup, there a lot of Linux
and even Unix users who don't have much of a clue about security.

>I think (but am not sure as to your exact intention) that you supported
>S.G.'s thoughts on this re: the above paragraph when you say "no real
>Internet application is going to use these capabilities".  What
>constitutes a "real Internet application"?  Anything that you and I
>would legitimately use?  If true, then *why* would the Raw Sockets be
>implemented? =20

By a "real Internet application", I meant things like browers, email
clients, FTP clients, telnet, Client Access, and the like.  I don't know
what you might legitimately use.  Since I run both a software firewall and
an external SonicWALL firewall applicance, I might have occasion to want to
run programs that the typical user wouldn't run, to make sure that
everything is working the way it should be.  Of course, these programs would
have to have their own raw socket processing to run on my WinNT4 system,
because its OS is crippled.

>So what if the current consumer iterations of Windoze already has a
>"crippled" implementation?  Does that make it O.K. to serve up an
>implementation far more powerful than a crippled one?  I think not.

As was already pointed out in someone else's message, if a trojan contains
the code for raw socket processing, it can spoof IP addresses and the like
even on pre-2000 Windows systems.  Why cripple the socket processing to give
people a false sense of security?  And as I already mentioned, DDoS attacks
(without IP spoofing) and scads of other kinds of attacks can be run on
pre-2000 Windows system without needing special raw socket processing.
Since various versions of Windows are on the majority of home systems,
should MicroSoft have left Winsock processing totally out of Windows?  After
all, if the user isn't smart enough to find and load some third-party
winsock (as I did with Trumpet winsock on my Windows 3.1 system) they
shouldn't be on the Internet anyway!

Since IP spoofing really has no valid use outside of a WAN (at least that I
can think of), ISPs should block packets to the public Internet where the
source IP address in the packet does not match the actual IP address.

Ken
Southern Wine and Spirits of Nevada, Inc.
Opinions expressed are my own and do not necessarily represent the views of
my employer or anyone in their right mind.

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.