[c-nsp] Telnet FROM a PIX Appliance?

[Ted Mittelstaedt]

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of C. Jon Larsen
> Sent: Friday, July 04, 2008 7:30 AM
> To: Peder @ NetworkOblivion
> Cc: cisco-nsp at puck.nether.net >> Cisco-NSP Mailing List
> Subject: Re: [c-nsp] Telnet FROM a PIX Appliance?
>
>
>
> Ted,
>
> Peder is correct. Cisco bought the company that made the pix
> (NTI) because
> NTI was one of the first companies to have a decent working NAT overload
> implementation.

There was a set of patches to FreeBSD version 2.1 that added in
translation, that came out around 1995.  I had a running translator
years before IOS 11.2 came out with it and had a 60 person company
behind it.

> NAT was a big deal back then - around 1995/1996 and Cisco
> routers did not have NAT in the IOS until 11.2 I think.

Yes, and Cisco could have used the freely available NAT code
that was BSD-licensed (ie: free, NOT GPL, really free).  They
did not have to pay off the NTI guys for something already
available for free.  And they didn't.  They wanted the NTI
customer brainshare, and likely, to put a potential competitor out
of business.

> At that
> time UUnet and many other SPs were tossing out a full /24 for every t1,
> but the smaller ISDN and frac t1 based connections started coming
> with much
> smaller allocations, and PAT was something everyone (small customers)
> started wanting badly. There was a smattering of non cisco boxes that
> could do a little nat, but customers wanted  solid state hardware
> that was
> easy to configure or at least flexible enough to be able to
> configure for a
> variety of wan service offerings - smds, atm, frame, isdn, x.25 was still
> here and there, and on the lan side decnet, ipx/spx, netbeui etc were
> still in play.
>
> Cisco, Proteon and Wellfleet and 3com to a lesser extent
> were the big router players but none of them were addressing the
> emerging NAT market very well.
>
> NTI was a small company with good engineers that wrote a
> custom kernel that did what few others were doing. I saw a few customers
> that actually bought the NTI box or were going to buy the box
> BEFORE cisco
> bought NTI. When Cisco bought NTI and threw their marketing behind the
> PIX, and started pushing it to resellers, it took off because it was a
> good box that fit a niche market very well. In fact the original
> NTI boxes
> were again more of a nat box that a firewall. When you installed
> a pix you set
> the screening router (a cisco of course) up as the dmz firewall with its
> acl capability to protect the dmz hosts and the pix had the outbound nat
> config and the conduits for the inbound flow to the inside network. The
> original pixes were pretty limited as a firewall and of course had no
> capability for a 3rd or 4th interface. They were strictly used for the
> corporate/inside network interface/connect point.
>
> Customers bought PIXes at that time because they were easier than having
> to figure out how to setup a linux

Linux was a toy in 1995 nobody was using it for production anything.

> or Sun bastion host / proxy toolkit or
> fiddle with ipmasq for most companies that did not have in house un*x
> talent. Customers were running out of IPs to number their PCs (and MACs
> - remember the need to browse the internet killed appletalk and
> localtalk)
> that and the ISPs were not handing them out (/24s) like candy anymore.
>
> As far as firewall feature set on a router goes ... I had to
> laugh. I have
> always considered that somewhat fiddly / buggy. Good way to make a solid
> product (a cisco router) into something that needs more attention and is
> slightly less reliable - especially when implemented on low end hardware
> like 800s, or 16xx, or 17xx, 2610s, etc.

IOS 11.2 for the 2500 was the first that did NAT

> I have seen at least 3 or 4 fw
> feature set implementations on routers that were backwards - i.e.
> inspecting traffic in the wrong direction. There is also at least one
> config for the fwfs on cisco.com's website that has it backwards too that
> I ran across.
>

Yeah, I've seen that config too.  But, every IOS rev Cisco has
ever come out with has been full of bugs for at least the first 10
revisions.  In any case, putting them head-to-head today is a
very different fish-kettle than in the beginning.  I'll take a
2800 or 3800 series router with firewall on it over an ASA
any day.

> As far as cisco discontinuing the pix ?? Thats plain wrong. The PIX
> lives on, it just has a new name (ASA) so cisco can move upmarket
> and charge more for the same code base :)
>

Let's just say Cisco's not discontinuing a PIX-like firewall.  But
calling the ASA a PIX?  No, not at all.  The ASA is ever worse
to deal with than the PIX

Fortunately, I don't have to deal with either on new installs,
at any rate.  Our customers who used to demand PIXes and routinely
override my recommendations to buy a router aren't doing that
with the ASA due to the price hike.

> Of course the cpus are much faster in the ASA boxes, and it has a more
> extensible/modular hardware architecture than the pix and you can plug in
> the IDS/IPS modules, etc. The ASA boxes usually have a celeron cpu in the
> 2Ghz range whereas the pixes started of as 486 dx2 66MHz chips (yes
> really, with like 4MB or maybe 8MB of main DRAM) and worked their way up
> to 300 or 400Mhz PII chips in the beefier models.
>
> Cisco has no interest in migrating any customers from PIX/ASA to routers.
> They want to sell you BOTH

Heh.  Yep, and unnecessary.

> and a few Cat switches while they are at it :)
>

Cisco is a smart enough company to sell to people's preconceptions.
Such as, for example, the silliness that having a firewall that
allows outbound telnet is safer than allowing incoming telnet to
a bastion host (either inside or outside) and then having people
jump off from that to the inside.  Once you open a vector from the
outside to the inside, the firewall is compromised, no matter
how convoluted you make that vector.  Not to mention that the
vast majority of trouble comes in via e-mail anyhow.  But, you
don't see Cisco trying to educate people.  They simply make
products in every way, shape or form that do whatever people
want, no matter how stupid, and sit back and let people waste
money if they want.

> And finally, Peder is correct again about the Centri. Centri was
> a flaming
> pile of junk. It ran on windows nt server (workstation was also
> supported I'm pretty sure).
>
> Of course it was terrible (the centri) - windows nt was a
> terrible product
> that never really did get stable enough for use as a reliable pc server
> much less as a critical piece of network gear.

Vista today and MS Server are any different?

> Centri did have some
> really "impressive" guis tools for managing firewall configs. At that
> time the pix was popular but hard to configure for end customers who
> typically have net admins on staff and not network engrs (times
> really have not changed have they :). Customers wanted to manage their
> own boxes and not have to call an integrator every time an acl needed a
> tweak. Thus the pretty gui of the cenrti appealed (in theory). I
> never saw
> one get sold and work though. Couple of demo/evals, and it usually died
> there in the sales process :)
>
> It would have been near impossible for anyone to build a firewall based
> on windows 3.1 technology. Windows 3.1 did not have a true kernel
> or built
> in (native) tcp stack.

It most certainly did - it was the MS Networking Client
for DOS that had the TCP/IP protocol.  It only worked with LAN
cards, though.  MS even released a winsock that talked to that
stack.

Yes it was real-mode, and technically it wasn't "windows" code
but really most Windows 3.1 apps took over the system anyway,
to do their own thing, it's mainly a semantic argument.

> Remember Chameleon anyone ? trumpet winsock ?

Those got a boost because they would speak PPP/SLIP out the
serial port.  The MS Networking stuff wouldn't until Windows 95.

> Those DOS TSR-based "tcp mini kernels" as they were called were so
> unstable that a windows 3.1 or 3.11 based firewall would have keeled over
> the minute it saw real use. Those stacks were barely functional as a
> client, much less a server or firewall.
>

Once more, not true see:

http://www.ka9q.net/code/ka9qnos/

Many people ran this stuff for years, very stable it was.

> I dont remember any vendors coming out with windows based "firewalls"
> until win nt 4.0. Windows in all its versions just was not stable enough
> until then and recall that Windows 3.5 and up are not the same product at
> all as win 3.1. Win 3.1 was 16bit dos with a gui command shell and a
> gui api. Win 3.5.x and up was Cutler's 32bit rewrite of VAX and
> Microsofts first true operating system :)
>

Xenix was Microsoft's first true operating system in 1980, followed
by OS/2 in 1987 (joint with IBM).  Cutler and his Vomit Making System
rewrite didn't come along until '88.

> No way would cisco have purchased or built or sold or recommended
> to clients anything based on win3.1 other than maybe a terminal emulator
> to attach to a cisco serial console :)
>
> I remember a customer that badly wanted to migrate off of netware to
> "save" licensing $$. Remember this was before CALs and such and windows
> 3.5.1 was almost free as a network server. They had to boot the 3.5.1
> server every nite so it would not crash the next day. The netware
> 3.12 server had been up for like 3-4 years at a time :)
>

I remember similar nonsense from customers during that time period as well.

Ted