On Tue, 21 May 2002, Noonan, Wesley wrote:
> <snip>
> >
> > <chuckle> Damn! <we are awaiting to see how many broked content scanners
> > are going to go nuts here, sicne it's already demonstrated that 'bitch' is
> > so offnesive to so many> It's getting to easy, not even a challenge
> > these days, to get a rise outta ya <grin>.
>
> It's really simple Ron. I don't like it when people attribute statements to
> me that I never made. I didn't like it the first time that it was done, and
> I don't like it now. It is bad enough to happen, but it is worse when it
> occurs on a public list. I decided that, after trying to explain it to you
> the last time didn't work, I would try a different tactic this time. It
> would appear as though I got your attention this time around.
>
Who got who's attention? Like it or not, you non-stance on the issue in
fact is a stance. Your rejection of historical issues is a stance.
> > Yet, I tend to think that it remains a mistake to ignore historical
> > reference, see below;
>
> Certainly this is no worse than making the mistake of misunderstanding the
> implications of something and reacting based on that misunderstanding.
>
> <snip>
> >
> > Does this imply that all other VLAN implimentations are not vulnerable?
> > Perhaps, perhaps not, it may well remain to be seen.
>
> So how about you wait to proclaim that other VLAN implementations (spell
> checker in Outlook is a good thing) are vulnerable until you know that, or
> do you always jump to conclusions?
>
Outlook is not only bloated, but perhaps the most unsafe mail reading
software on the market, it's a shame so many are stuck with it, but, let's
not get misdirected into another topic. And yet, I wont knock your poor
speed reading abilities if you can refrain from letting my typos in quick
replies bunching up your undies. We'll both then not be mistaken by some
out here as having some kind of affair going on.
> > Yet, on a historical note, the fact that this is *normal* traaffic that is
> > passing, no exploit required nor intended for this to happen, makes one
>
> Uhh... Ron... this is what switches do when they don't know the port the
> destination MAC address is on. Passing the traffic isn't the problem. The
> switch losing the port to address mappings is. Come on, I know you are smart
> enough to figure this out.
>
The switch was *not* doing what it was supposed to do, it was working
proper, then not then working proper then not, it was fading in and out
intermittently, often mid tcp stream;
<quote>
Packet #01 is _not_ seen by the sniffer, and rightly so, assuming the
switch
knows the MAC entry for the DNS server.
Packet #02 is seen by the sniffer, but shouldn't have been. The switch
should have learned the workstation's MAC
entry from packet #01.
Packet #03 is _not_ seen by the sniffer, and rightly so, assuming the
switch
knows the MAC entry for the Server.
Packet #04 is seen by the sniffer, but shouldn't have been; no matter
what.
The switch now has had 2 different packets
from the workstation to learn it's MAC.
Packet #05 is _not_ seen by the sniffer, and rightly so...
Packet #06 through #09 are seen by the sniffer, but shouldn't have been!
Packet #10 is assumed to be an "ACK" from the workstation and suddenly the
switch registers the workstation's MAC. No
additional packets are seen for _this_ conversation.
</quote>
> > wonder how secure any VLAN setup is under harsher condistions.
>
> It doesn't make you wonder how secure VLAN setup is, it makes you wonder how
> secure switches are... then again, if someone is implementing a switch
> solely for security, they are a fool.
>
agreed! which includes VLAN segments in a security setting, which is
after all what a DMZ is...
> > Additionally, there is a strong hint there that this might well be tied to
> > older exploitable conditions; i.e. cam table flooding and MAC address
> > spoofing.
>
> Strong hint? No hint. There is nothing in the report that implies this, even
> remotely. Nothing in the cam table is being flooded and nothing is spoofing
> MAC addresses.
>
> > <quote>
> >
> > Workaround:
> > Setting the CAM agingtime to a larger time _helps_ but does not
> > completely eliminate the problem. "set cam agingtime xx 14400" where xx is
> > VLAN #.
> >
> > </quote>
>
> Read up on what "set cam agingtime" does Ron.
>
> > This report makes it clear no exploit is needed, not that one needs to be
> > written up:
> >
> > <quote>
> >
> > ...
> >
> > However, what is happening, is that TCP session packets are being flooded,
> > although the switch _should_ have learned
> > the MAC.
>
> Correct. This is the only problem. The switch *should* have learned the
> address. That is the *only* problem. Nothing to do with passing traffic
> between VLANs, nothing to do with buffer overflows, nothing to do with
> spoofing, simply the switch should have learned the address mappings and
> didn't.
>
had learned the MAC address it would seem, afterall it found a
destination, then the switch *forgot* what it had learned, and a number
of times the posting indicated, this was not a pre-learning issue, nor
was it a one time issue, it seemed to be indicated this was an issue that
popped in and out.
> > ...
> >
> > I have captured telnet sessions, ftp sessions, etc; with a portion of a
> > telnet session's password visible. There is no
> > special setup required to see this other than physical Ethernet connection
> > & sniffer software.
>
> Uh, Ron... this is how Ethernet (among pretty much every other shared media
> topology) works. Maybe you should go tell the IEEE that this is occurring
> and ask them to change the 802.x specifications. See, this is a symptom Ron.
> Good troubleshooting dictates that you don't waste time on symptoms
> (flooding unknown data), but rather you address the problems (why is the
> switch losing the mapping) directly. The worst thing about this issue
> though, is that the guy who reported the problem seems to understand
> perfectly well what is going on... it's just when amateur hacks get involved
> that things start getting confused and convoluted...
>
Ahh, yes, ethernet, but, this was *not* an issue at all related to 802.x
specifications. It was a failing of the switch to deal with ports
properly. the packets went where they were not supposed to go, the
switch failed, it's VLAN setup failed. Where was it mentioned that the
port sniffed was setup to read all traffic flowing across the switch, I
think it was pretty clear this was not the setup in question.
> <snip>
> >
> > I think what was presented in the advisory is enough to ake all secrurity
> > related implimentations of VLAN/DMZ etups suspect,
>
> And why again would you think this, when the "problem" has nothing to do
> with traffic traversing a VLAN? Having uninformed opinions is not a good
> practice. Making recommendations to others, based on those uniformed
> opinions is even worse.
>
Yet, it was traversin ports it was not ment to. If the switch is failing
so, what makes one presume the switch has only those problems? The VLAN
in qustion failed to function as it was supposed to do, who knows what
other issues it has, I'm sure you might well agree.
> > until at least cisco
> > comes up with a fix. Of course, this does not speak to the
> > implimentations of other switch vendors, of which there are some.
> >
>
> You do get that this issue only occurs on a single VLAN, yes? IOW, as long
> as you have a switch with a single VLAN (not default VLAN1), this is a
> problem. If you use VLAN1, this isn't a problem. If you use multiple VLANs,
> the problem only occurs on the individual VLANs, no cross VLAN traffic gets
> passed.
>
It has in the past, so, seeing issues of port hopping makes one feel less
positive that the switch works as designed, yes? Past issues have been
documented of packets crossing VLANS, now we are seeing packets hoping to
ports they are not destined for. Perhaps not all the problems supposedly
fixed in past patches fixed all the issues, or then again, perhaps past
fixes introduced new issues. Of course, this is not too surprising this
we'd be seeing problems again. Afterall, switches are fairly new toys as
compared to some of the other devices we all play with, including hubs,
unix systems, that stable windows environment <cough>, and routers, etc.
> >
> > <chuckle> You get so 'cute' when yer fingers get all red pounding out
> > frustrations!
> >
>
> And you sound so old and bitter when you lose the technical ground on which
> your flawed opinions are based.
>
> Unless you have something new and productive to add, I am done with this
> subject, and you. I think that I have made it abundantly clear that you are
> talking out of your ass on this subject, and that was my goal. I also wanted
> to make it painfully clear that what you were attributing to me was a load
> of crap, and I think I did that as well. Case closed.
>
<chuckle> Wes, you need to inject a sense of humor into the personality
there, it helps keep from getting those fingers so stressed with blood
flow as you pound on the keys. Seriously, it helps one avoid burnout in a
tense industry.
Thanks,
Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***
OK, so you're a Ph.D. Just don't touch anything.
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
For Account Management (unsubscribe, get/change password, etc) Please go to:
http://lists.gnac.net/mailman/listinfo/firewalls
