Wirt,
I can't agree with you this time.
Firewalls do exist for more reasons that only protecting the inside
network:
They isolate the inside network from the outside.
Can provide NAT.
Can make intelligent routing.
They filter out undesired traffic.
They can provide VPN services
Provide a "sandbox" where any possible attacker can be caught.
Provide logging of anything.
You can build your own with an old 486 PC under Linux, and will
happily handle a full 10 MBPS network. Guaranteed.
With some tweaking, they can be used to distribute load between
servers.
Consider only one or two of these reasons, and, voila', you get the need
for a firewall.
(my favourite is 4).
Any takers?
-- Andres j. Ogayar
-- I.T. Department
-- Raytheon Microelectronics Espaņa (Malaga, Spain)
-- +34.95.224.92.27
Wirt Atmar
<WirtAtmar@AOL Para: [log in to unmask]
.COM> cc:
Enviado por: Asunto: Re: webserver on the 3k
HP-3000
Systems
Discussion
<HP3000-L@RAVE
N.UTC.EDU>
05/07/2001
19:46
Por favor,
responda a
WirtAtmar
Let me apologize for being so long getting back to this, but the Fourth
of
July has given me the first chance for some free time to reply.
If you remember, I suggested that a firewall for the HP3000 is not
necessary.
I expected some strong reaction to that statement and Richard Gambrell, Ken
Hirsch and Bruce Toback did respond. Nonetheless, I remain wholly
unconvinced
that a firewall is necessary, or that if you have one, it is doing you any
good.
The reasons given for a firewall can be grouped into several categories.
Let
me address them one by one:
DISTRIBUTED DENIAL OF SERVICE ATTACKS:
In this regard, Richard Gambrell writes:
> A firewall of some type gives the inner network and it's systems some
> insulation from an attack. Would you rather have the 3000 spending
> it's CPU cycles processing irrelevant packets, and possibly uncovering
> some unknown vulnerability in MPE's network handling or have your
> router/firewall beaten on instead until it fails? At the very least,
take
> your router and configure blocks for all ports that you do not need on
> the Internet.
>
> Perhaps take a close read of http://grc.com/dos/grcdos.htm before
answering.
As it occurs, I just happened to be using Steve Gibson's site, testing my
shields and probing my ports on a PC that I had set up as an FTP server,
when
his dDOS attack began. I saw his site go away. Of course, from my end, I
couldn't tell that that was his specific problem. The internet is still not
a
completely reliable device and someone in Alabama could have cut a fiber
cable, or a fuse on his server could have blown, or he could have forgotten
to pay his light bill and I would not have been able to tell the
difference.
When I could no longer use his service, I just got up and did something
else.
Nonetheless, the most important attribute to note of a dDOS attack is that
nothing is harmed. All that is being done is that his link to the world is
being flooded with useless packets, but none of this is causing any disc
movement on his server, no data is being written or retrieved. Absolutely
no
harm is being done. It is obviously an irritant, but nothing more.
Further, it's not even that much of an irritant. If you have a T1 line into
your HP3000, a completely flooded T1 line represents only 15% of the
traffic
that you could possibly have on the 10Mbs LAN card connected into your
backplane (or 1.5% of a 100Mbs connection).
But more importantly, Richard asks, "Would you rather have the 3000
spending
it's CPU cycles processing irrelevant packets?" The question implicity
presumes that a dDOS attack is a normal condition. It's not of course. Most
of us will never experience a dDOS attack during our lifetimes. And even it
you are unlucky enough to have it happen to you, while it exists, all
you've
lost your path out to the world, but that's all you've lost.
The way that a dDOS attack is ameliorated is that it is staunched somewhere
significantly upstream from you so that legitimate traffic can make it
through your relatively narrow pipe and the nonsense is filtered out before
it ever gets onto your specific circuit.
For the moment, everyone is vulnerable to these distributed "evilbot"
attacks, but I suspect that they won't last much longer. If they become a
real nuisance -- and that's all they are -- adaptive robots will be built
into the trunk carrier's code to watch and analyze packet traffic to
automatically detect and reject these planned attacks. At that point, much
of
the amusement will disappear from this particular internet weakness.
The presence or absence of a local firewall makes almost no difference in
this particular situation. While you may be able to keep these probes out
of
your local network (using either a firewall or far more likely your local
gateway router), that's all you can do. Your connection to the world is
still
being swamped by the dDOS zombies until someone further upstream accurately
characterizes and filters out the packet flood.
ATTACK CYCLE TIMES
I wrote:
>But other than that, there is no real difference. Ultimately, good
>passwording is your only security. If security ...
>was good with a permanently connected modem,
>it won't be any worse with a network connection. I blame a lot of the
>calls for firewalls on simple fear and not much else.
and Bruce Toback responded:
> Unfortunately, this seriously understates the threat.
>
> First, don't minimize the "no cost" and "quick cycle" differences.
> They're huge. One penetration attempt every fifteen seconds is a vastly
> different threat than a hundred attempts per second. Second, "no cost"
> means that the number of possible attackers has grown immensely, since
> cost was a barrier before. Moreover, international phone calls can
easily
> be policed. International IP traffic is a lot harder to police,
> particularly with the connivance of the authorities at the attacker's
> point of entry into the network.
> It's not "senseless" to lock these down. MPE allows only eight-character
> case-insensitive alphanumeric passwords. Given a fast line and a fast
> box, I can try 100,000 common words and names in an hour while nobody is
> monitoring the console. If you have complete control over your
passwords,
> and always assign random ones, and always reinstall passwords after a
> system update, and, and, and... that's not a problem. Otherwise, why
take
> chances?
At first glance, Bruce's numbers seem that therein lies a horrendous
threat,
but they're worth a second thought, and once thunk, the threat is not
nearly
a great as it might seem.
Bruce's 100,000 attempts per hour translates to 30 attempts per second, or
30
ms. per attempt. This sort of rate basically implies an attacking machine
on
the same LAN as the server. You simply can't even get these kind of ping
times from any reasonably close distance over the internet. More reasonable
ping times from a machine somewhere on the same continent lie between 50 to
250 ms, with intercontinental times more likely averaging between 250 to
1000
ms.
However, if we were to allow Bruce's numbers, 100,000 attempts per hour,
working against a password composed of only 8 letters, a dictionary attack
would still require, on average, 110 years to break the first password. And
if the password were composed of 8 characters, made of both letters and
numbers, the time would grow to 1490 years.
Nonetheless, these numbers are just quibbles. The way to blunt any sort of
dictionary attack is to simply slow it down. One trick has already been
implemented in MPE's telnet: a single mistaken password immediately
disconnects you from the HP3000 and you have to re-establish your TCP/IP
connection, a process that takes at least one second, even if you're right
next to the machine. Given this simple trick, the average time to break a
8-letter password grows to 3300 years and an 8-letter/number password
becomes
44,700 years.
However, there's no real reason to tolerate even this level of
vulnerability.
This basic subject was discussed two and half years on this list and the
recommendation then was to implement an autoadaptive INETDSEC updater that
allows a remote IP address 10 tries at entering a password, and should it
fail that, it would automatically put that IP address put into the deny
section of INETDSEC for 24 hours (or for whatever period of time the user
wishes to configure).
The complete thread is available on Bruce's server at:
http://www.optc.com/Webbot/Thread9139.html
I believe that the thread is very much worth reading again. All of the
individual pieces to do this are in MPE now and it shouldn't be that much
work. But if it were done, dictionary attacks would simply become
impossible.
In this same regard, Ken Hirsch writes:
> - Security is not as good for FTP access as it is for logons. Where are
> unsuccessful FTP logons logged? Do you have VESOFT security on FTP?
Actually, security is much better on FTP than it is on telnet. Under
standard
telnet protocols, which are identical the security protocols that have
always
traditionally existed on the HP3000, even for a dumb terminal, you enter
one
password at a time, and when you get that correct, you go on to the next,
and
so on.
What this procedure means is that if it should take you, on average, 3000
years to break through the first password, it will only take an additional
3000 years to break the next one. This sort of procedure entails nothing
more
than a simple linear addition, where you clear one hurdle at a time.
But that's not the way FTP was implemented on the HP3000. You have to get
both passwords right at the same time or you're disconnected, simply
because
you enter them as one long string, separated by a comma. What that means is
that if you were using two 8-character (number and letter) passwords for
your
MPE groups and accounts, the average time to break through the FTP password
challenge, using Bruce's 30 attempts/sec numbers, would be 4.2 million
billion years (or 20,000 lifetimes of the universe, discounting of course
the
fact that at the occurrence of each "Big Crunch", all information from the
previous universe's existence is lost) [36^16 possibilities / (30 attempts
per second * 86400 sec/day * 365 days/yr) = 4.2 x 10^15 years].
While these numbers essentially (absolutely) eliminate any brute force
attempt, I would still vote for the "10 tries and you're out of business
for
the next 24 hours" rule for FTP too. And I would log the IP address of
every
failed attempt. Nonetheless, even now, in any existing real world
conditions,
you're not going to get onto an HP3000 by breaking passwords.
HOMOGENEITY
Ken Hirsch writes:
> - The more network services you run, the more vulnerabilities exist.
Samba
> and Sendmail have had flaws discovered in the past that do not require a
> password to exploit.
and Bruce adds:
> But more importantly, almost NONE of the Internet-based system
> penetrations available to all and sundry via FTP-able "rootkits" rely on
> password security. They rely on the fact that many different code paths
> are exposed via the network. An attacker going in through a modem can do
> just one thing: try to log on by guessing or knowing passwords. Someone
> who attacks through the network doesn't need a password; they just need
a
> bug in one of the many processes that provide services to network users.
Actually, the vulnerabilities don't occur because of the number of network
services that you run. The real threat occurs to the HP3000 because of the
highly homogeneous code that has essentially the same heritage everywhere,
on
every platform, is also now being run on the HP3000. People are porting
this
"universal" code over onto the HP3000 without even fully understanding how
it
operates.
In that, the situation seems amazingly analogous to the agricultural
catastrophe that hit the United States in 1970-71 with the mass planting of
only one variety of high-lysine corn everywhere in the U.S.: Texas male
sterile.
All parasitization occurs through the exploitation of disinformation, and
that statement includes hacking as well. Bipolaris maydis is a fungal corn
parasite that generally has no economic impact at all, but in the late
1960's, a particular variety of the fungus, called Race T, evolved that
somehow got around the recently derived Texas male sterile's immune system
response. At the same time, this particular variety of corn proved to be so
agronomically valuable that it was planted nearly nationwide in the 1970
and
1971 growing seasons, a virtual monoculture of one specific variety of
corn.
The result was the closest the US has ever come to having a near complete
agricultural collapse in the manner of the Irish potato famine. Over 1
billion dollars in economic losses were sustained in the 1971 season, the
futures market went into freefall, President Nixon became intimately
involved
with the problem and NASA overflew most of the US with daily U-2 flights to
accurately measure the growing extent of the problem. An image of the
fungus
that caused the problem can be seen at:
http://plantpathology.tamu.edu/Texlab/Grains/Corn/sclb.html
What was the cure for the problem? Nothing more than hybridizing the Texas
male sterile variety with other corn types that retained the resistance
mechanism that was lost during the development of the Texas male sterile.
That and swearing off of a never-again nationwide monoculture. Genetic
diversity inherently limits the development of catastrophic mass
parasitization, simply because no parasite can ever learn to exploit
anything
but a small fraction of the vulnerabilities that exist in the diverse
population.
What we're doing at the moment is re-building a world-wide monoculture, and
the results seem predictably the same.
The preventive mechanism on computers similar to genetic diverstiy would be
for each organization to completely independently write the various network
protocols and services from only the specifications, without seeing anyone
else's code. While each independently written service would undoubtedly
have
its own vulnerabilities, the chances that they would be discovered,
especially on the rarer platforms, drops dramatically. Even more
importantly,
if such vulnerabilities were discovered, they would likely only affect one
platform.
In this universe, the rarest hosts become the safest, and this general
thought is codified in the "rain of parasites" idea that suggests the
reason
for the great biodiversity of plants in tropical rain forests is simply
because of this phenomenon. No single host platform can become
overwhelmingly
common because of the impact that would occur when parasites "locked-onto"
(learned) this host's particular weaknesses. The effect would be to greatly
subdue its general vigor, and thus its capacity to dominate its world.
BAD ADVICE
Bruce writes concerning my comment that I now longer lecture our customers
about having a modem continuously connected to their HP3000s and not having
passwords on all of their accounts:
> >I used to give these people stern lectures about this faux pas, but I've
> >stopped. If I say anything at all anymore, it's just a gentle reminder.
> >The chances that anything untoward will happen to them are about the
same
> >as their being hit by a martian meteorite. They are protected by
mulitple
> >layers of "security through obscurity," simply because they're running
an
> >HP3000.
>
> I'm sorry to be so blunt, but this is singularly bad advice.
Bruce misunderstands what I was saying. I certainly wasn't saying to NOT
put
passwords on their accounts. All I've done is stop lecturing our customers
who don't.
I've stopped these lectures because the world has changed, and as a
consequence so have the threat potential. No self-respecting hacker anymore
dials around looking for phone-connected modems, in great part because the
phone company has killed his opportunity to do it for free, as he could 30
years ago with a blue box. Secondly, it's simply declasse nowadays, as
compared to internet hacking. And thirdly, it requires a lot more knowledge
and thought than a scripted attack requires.
If the choice lies between alienating a customer and leaving them alone,
I've
chosen nowadays to leave them alone, or at least only provide gentle
reminders. All in all, I do feel the threat from modem attacks has dropped
dramatically, more as a cultural phenomenon than anything else, and that
these people are not particularly at high risk, although I as much as
anyone
would like to see them password all of their accounts.
Wirt Atmar
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
