I love IP Tables....

Les hlhowell at pacbell.net
Wed May 30 08:17:50 UTC 2007


On Tue, 2007-05-29 at 21:09 -0600, David G. Miller wrote:

> Les <hlhowell at pacbell.net> wrote: wrote:
> 
> > But I want to use the darn thing, not babysit it.  That is why I left
> > Windows.  ...
> The only way anyone can safely ignore a computer attached to the 
> internet is to boot it from a live CD, only use the hard drive as swap 
> and shut it down when you're done.  Any system left on and connected is 
> a potential target.  Some are easier to hack than others but all are 
> potentially vulnerable.  On the other hand, I run a Linux box that's 
> connected to the internet and running 24 hours a day that acts as my 
> mail server, web server for my really lame web site, firewall for the 
> rest of my home network and provides file and print services.  To the 
> best of my knowledge, I've never been hacked but I still spend a minute 
> or two every day looking at logwatch and the output from chkrootkit.  We 
> use our computers to manage a lot of our finances so we have a lot to 
> lose if we were to get hacked.  I don't consider a couple of minutes a 
> day to be too much of a burden if I want to be (relatively) safe.
> >
> >     As to the car analogy, do you NEVER speed, never tailgate, always
> > signal lane changes or turns?....  
> Always? No.  Often enough to stay out of trouble?  Apparently.  I mainly 
> worry about the idiots yakking away on cell phones and not paying enough 
> attention to their driving.  I've almost gotten creamed a couple of 
> times and probably would have if I hadn't been watching out.  One item 
> you left out of your list of question is I try to remember to check both 
> ways before entering an intersection after the traffic light changes in 
> my favor.  The right of way isn't a right that's worth dying for.
> 
> So, I'd say the car analogy really fits computers.  Like with cars, you 
> don't have to do everything perfectly all the time but any lapse is 
> *potentially* an accident waiting to happen.  Do it often enough and 
> eventually the accident will happen.  Like with safe driving, the idea 
> is to develop a bunch of safe computing habits like checking what 
> logwatch reports, running chkrootkit from cron, if you can, port scan 
> your network from outside (e.g., visit the local library with a laptop) 
> from time to time, etc.
> 
> Finally, like with cars, if all you want to do is the computing 
> equivalent of hop in, turn the key and make a run to the grocery store, 
> about all you need to do is scan the gages and idiot lights and do the 
> scheduled maintenance.  On the other hand, if you want to drive like 
> you're James Bond escaping from Specter, you'd better do a little bit 
> more.  All I'd like to see normal users do is the equivalent of scan the 
> idiot lights and do the scheduled maintenance.  That's all.  Conversely, 
> if you want to go beyond just checking e-mail and surfing the 'net, it 
> is your responsibility to make sure that whatever services you open up 
> don't become an invitation to hackers.  It's in your best interest as 
> well as helping others not have to deal with your security lapses.
> 
> Cheers,
> Dave

OK, Services.  Remember that about six months ago I posted a question
about the number of services that should be running.  The answers ranged
from about 15 (I think someone was running text only and no network), to
over 150.  The number of course depends on the system use.  But users
don't know squat about services.  They load the software they need to do
their job and as long as that job gets done, they are happy.  

    Moreover, even though this is a very powerful tool, what reason is
there for them to know the services on the system.  Do you know how the
computer on your car computes the fuel air mixture, or the spark timing,
or if a BMW the valve timing?  How does it arrive at the decision to
make antilock brakes operate in antilock mode?  Or even to manage
traction control?  Do you know how traction control works on a front
wheel drive car?  Or that almost every car on the road in the last 20
years has overdrive?  Do you know how overdrive works and how it saves
gas?  How a gas gauge works?  or even how the turnsignal is timed?  Is
your radio part of your car's engine monitoring system?  Where the
computer is located, how the fuel injection works, or even what fuel
injection does work on a modern production gasoline engine?  Did you
know it is different from the fuel injection used on diesel engines?

    What I am saying is that technology surrounds you.  You are not
aware of much of it at all, but it is ubiquitous. IC chips are produced
on 8" wafers, with each die being about .25 inches or less on a side.
That means the wafer will contain many hundreds of chips.  Wafers are
processed in boats, containing 12 to 20 wafers.  A typical test program
runs between 400milliseconds and 4 seconds, and a boat of wafers takes
about 8 hours to test.  A typical test floor for production has 40 or
more testers doing this around the clock and there are hundreds of
thousands of test floors world wide.  Digital and mixed signal devices
pour out their doors in a continuous stream, and there is a continuous
backlog of three to six months on parts.  Our little PC's are just the
tip of the iceberg.  We have touched on routers, firewalls, services,
worms, viri, and other issues.  But most of all, software is just not
generally well engineered.  Much is entered on the fly, debugged down
the hall or overseas, and released to the public with patches and
debugging a perpetual process.  Why should customers be blamed?  Really,
why?  They are just users of yet one more technical machine, and they
only know poweron, type and mouse to do what they want, they don't want
to know more and won't learn it.  If we try to make them, we will lose
our customers.  End of the line.

    They pay the checks and when they don't, no checks are forthcoming.
We go without.

That is the full story.

Regards,
Les H 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20070530/637bf8b7/attachment-0001.htm>


More information about the fedora-list mailing list