🚀 go-pugleaf

"Chris" <never@work> wrote in news:vi0eseqe4p8sc3@corp.supernews.com:

> IP Protocol 53 -- SWIPE -- a network-layer encrypted encapsulation
> protocol for IP; pre-dates IPsec and seems not to have been widely
> implemented 

Now that is a good answer.  Thank you, Chris.  I see 
now that the premise of my previous article and questions 
were wrong.  That's a GOOD thing, because I'll bet 
that I am not the only fool on the planet that read 
an access list containing the number 53 and associated
it with DNS.  I should have caught my own error, because
I did indeed check and and notice the mismatch between 
the description of IANA TCP port number 103, and the 
reference that Cisco's alert doc made to the PIM IP 
multi-cast related protocol before I posted even the
first article yesterday.

So if I had had my thinking cap on, my first question 
should have been "please help me understand this, 
kind readers".
 
> Know the difference between an IP protocol and a TCP/UDP port!

Clearly, I don't and I didn't.  My bad.

Now, please understand that the rest of this article is
a followup to the thread, and is not meant to reflect on 
Chris, who has just done me the courtesy of providing an
answer that educated me, rather than merely squeaked that
I was an idiot and then hid behind the bushes again.

So please understand that none of the rest of this article 
is directed at "Chris <never@work>".

My ignorance on the meaning of the number in router ACLs 
could stem from the fact that I spent more time diddling 
my clients' PIX boxes, on which port blocking and port 
redirection (PAT) is a major concern.  To be sure, this
use of port numbers typically occurs in the "conduit" 
command lines, but those are ones that often get the 
most work and rework as a new firewall is set up.

Like many engineers, I keep a library of old configs, 
and it turns out that the most complex router acl that 
I have on file doesn't specifically cite any IP protocols 
by number; there were 8 acls that primarily served as 
ingress and egress filters to be applied to certain 
interfaces for certain internal address blocks.  

One tends to learn concepts according to technical 
necessity.  Unlike many who "lurk" on the net, I have
never minded asking a "dumb" question, or in this case, 
making a suggestion that could potentially expose 
ignorance on my part.  In such cases, the followups 
usually turn out to be educational, both for me, 
and I daresay for a few other folks out there who, 
like me, have never had occasion to need write a 
router ACL citing an explicit IP protocol.  

So thanks again of behalf of my fellow ignorami 
and lurkers.  

For the rest of y'all, please remember that the 
purpose of Usenet groups is the asking and answering 
of questions, efficient dissemination of information 
to "BoF", and the discussing of ideas.

If you'll recall, both the title and the main point 
of my original post was to suggest that we'd all 
benefit by knowing how this particular exploit 
was being launched - the "vehicle", if you will.

NO ONE took serious exception to this main idea, 
or at least, no one did so cogently.  Instead,
various members of the peanut gallery sniped 
that the question wasn't necessary because the
acls provided by Cisco mitigated the problem. 

Well, for those of you who are not capable of
extrapolation or abstraction, the core issue 
here concerns the very high level of secrecy 
that now surrounds security announcements from
the likes of CERT, SANS, and vendors.  Sometimes
it makes sense; often it does not.  This time 
it did not, REGARDLESS of whether Cisco's fix 
mitigated the problem, and REGARDLESS of whether
my missing the distinction between IP protocol
and TCP or UDP port number within Cisco acl
syntax meant that I had over-estimated the 
seriousness of the threat posed by this latest
IOS flaw.  

My topic dealt with the policy issue of information
control.  For those of you who were in the business 
pre-9/11/98, say (note the year, will ya?) by which
time we all agreed that information security was 
important and some were starting to declare that
immediate full disclosure wasn't ALWAYS, AUTOMATICALLY
the right thing to do, which is what we'd believed 
in the past ... we now frequently have to deal with 
the flip side of the coin.  Believe it or not, it 
is still legal in this country to want more info
than your vendor is willing to provide.  

So, in this case, one fellow was kind enough to 
provide a useful answer to my "vehicle" question. 
At least one other was interested enough in that 
gentleman's post to follow up on the same topic.  

> For someone who works for a Network Consulting Services company you
> really aren't paying much attention to the details are you? 

Please note the company name in the .sig, below.  As a one-man
shop, I don't get the chance to configure enterprise gear 
as often you might think, though I still dutifully provide 
information to my old clients because *I* built their networks
and *I* stand by my work even after the companies I worked for 
bite the dust.  Now I did get the play with the big toys at my 
last "real" job, working as a CCNA/DA-level engineer for Verizon 
(Cisco Gold) before they shrank their network integration business 
to just letting union guys install pre-configured edge routers  
whenever the telco guys sell a new circuit.  Prior to that, 
I did enterprise Cisco and MS design and billable consulting 
work for a very successful Cisco Silver that unfortunately 
got sold to Bell Atlantic pre-Verizon.  And while I was WAY 
far from being their top dog - even as a 200-seat company
they had plenty of CCNPs and two CCIEs - I WAS their 
"detail man".  I wrote the contracts, the SOWs, did 
the designs, and then handed the jobs off to younger
engineers for implementation.  

These days I'm more likely to be found on my hands 
and knees vacuuming out a sh*tty PC in a doctor's 
office that they insist on calling a "server", 
and trying to persuade them to invest in a UPS 
and a tape backup system.  Laugh all you want,
but YOU folks go out and try setting up your 
own accounting systems, soliciting your own 
customers, and collecting on your own past-due
invoices.  Try dealing with a clueless client
who threatens to sue YOU for something he doesn't
understand, even though YOU just fixed his problem 
yanked HIS nuts out of the fire.

Sure, I'd give my left nut to get back into full-time 
Cisco work, but there's been a bit of a shortage of that
in the DC area for guys without Active Secret tickets 
since the dot-bombs went bust.  Anyone interested in 
working with an honest engineer with Cisco and MS certs, 
plus six years in the systems integration biz?  I've 
sent resumes to companies offering positions as low
as PC support, and offered to take any job on the 
totem pole to get back in the door with former clients 
whose networks I designed, built, and implemented, even 
though I made six figures in my last two years at VZ. 
I've freely offered to work for less than half of that,
to sign a stay-on contract at a fixed salary for X years,
and even do the first month or so as an unpaid volunteer.
That's the state of the job market in DC, unless you're
eligible for cleared security work.

Lastly, as for those who are feel the need to complain 
about long posts to the Usenet, may I ask just who exactly 
is forcing you to read this?  Killfile me if you feel the 
need.  If you have access to really old usenet archives and 
grep for johnston@me.udel.edu in gnu.* groups circa '88-'91 
(pre-Linux) through '94 or so, you'll see that I've paid 
my dues many times over here in never-never land, answering 
far more questions than I've asked, and contributing my 
share in the freeware and patch department.

And for those of you who post hiding behind unreachable
or non-existent email addresses, sniping only at the 
edges of the some of the points I've made in my "long",
"whiny" posts, well, have a look at my .sig.  Never 
once in my life have I posted to the net without  
including my real name, address, phone number, and
email address.

And my current IP addy is 68.50.36.39.  ;-)

Have at it, kiddies. 

- Bill
-- 
Bill Johnston
Johnston Network Consulting Services
14758 Chisholm Landing Way
Gaithersburg, MD  20878
301-717-8894
wdj-netconsult@consultant.com