I asked him about it on IM, wondering if it is real:
"looks like that
but requires a sctp app to be running"
one good thing, practically no sctp deployment... and, hopefully for
networking equipment there's already local firewall/acl capability
deployed.
That said there are a few 'network devices' which are linux based (not
just Vyatta! )
o Cisco Guards
o Arbor Peakflow (at least the X version)
o some-route-optmization systems
o dns/mail/ntp/blah widgets
It's nice to get some notice of this, it's also nice it got fixed in
later kernels (who knows what kernel Peakflow-X has deployed or what
custom mods happen to it?)
Quickly searching <favorite search engine> shows quite a few
SCTP/Linux problems reported over at least the last 2.5 years. The one
mentioned here seems to be: CVE-2009-0065 reported Jan 5th 2009, only
redhat reports back a fix so far (according to mitre).
Putting on my Paul Quinn/Roland Dobbins/Darrel Lewis hat - another
good argument for infrastructure acls!!
-chris
Phrased differently: "The horse has already left the barn, and Gadi is warning
you that there's a horse possibly munching on your front lawn already".
Which would you rather have if you actually had a network to run - Gadi and
HD Moore telling you that the bad guys have a point-and-shoot for the boxes
you use to run your net, or them *not* telling you about the point-and-shoot?
Hint: Anybody who thinks HD Moore is a major part of the problem is probably
more a part of the problem than HD is.
> Cisco ASA's appear to be linux under the hood based on watching
> versions of ASA804-3/12/19/23/31 boot on the console
They are Linux, and run two copies of IOS simultaneously in a VM each.
Kind of like how VMWare ESX is Linux - technically it is, but you
don't really treat it as such.
Not to nit-pick, but VMware ESX uses RedHat Enterprise Linux for it's
service console on versions previous to ESXi. The purpose of the service
console is to provide support for booting the ESX Hypervisor which itself IS
NOT Linux. It does, however, implement a Linux Driver compatability layer so
that un-modified Linux drivers can be used w/ the Vmware ESX Hypervisor. The
stated goal of this layer is to allow existing third party drivers to be
rapidly added to the ESX Hypervisor w/out a lengthy porting process or a
requirement for a company to maintain a completely separate driver source
code tree for Vmware ESX.
Here is a link to some info on Wikipedia:
Specifically; "VMware states that the ESX Server product runs on "bare
metal".[3] In contrast to other VMware products, it does not run atop a
third-party operating system[4], but instead includes its own kernel. Up
through the current ESX version 3.5, a Linux kernel is started first[5] and
is used to load a variety of specialized virtualization components,
including VMware's 'vmkernel' component. This previously-booted Linux kernel
then becomes the first running virtual machine and is called the service
console. Thus, at normal run-time, the vmkernel is running on the bare
computer and the Linux-based service console runs as the first virtual
machine (and cannot be terminated or shutdown without shutting down the
entire system)."
It is a common misconception that the ESX Hypervisor is Linux based, but
that is an urban legend.
I have a customer running with a Cisco 5500 series firewall. What were
seeing (as a problem) is that there is a bit being flipped by the firewall
in the packet header. The bit in question is the Congession Window Reduced
or CWR bit. Under heavy load the target server is getting this bit as high
and since (I am guessing) its that way dropping the session yet its not near
capacity. Its a Microsoft server as well. Not that I am knocking that but.
Under the same situation a Linux/Apache server doesn't seem to care, and
goes about its business. Anyone heard of this? I did searches regarding this
but found (as per usual) tons of usless info. I'm not sure why the packets
are being changed by the ASA. I know there not hitting the firewall this way
(Packet capture) but they are getting changed. Config mishap? Is the ASA
throttling down stuff, and if so why not at the requesting party?
Maybe the middlebox along the path doesn't like tcp window scale
parameter being changed in the midway due to dropped tcp connections or
something. Could be specific to microsoft server. What does your pix
logs show?
Have you tried turning off 'tcp window scale' option on your windows
server? I believe this is enabled by default[0]. See if you can test this.
I've ran into similar problems using pix/nokia fw.
Hopefully this helps and you might want to bounce (do not crosspost :))
this thread off cisco-nsp.
ESXi doesn't require much Linux (just busybox), but I think the point
is that the VMkernel (the hypervisor) and the service console (Linux)
are separate entities. The SC is really a VM, so it depends more on
VMkernel than VMkernel depends on it.
)