Re: Sun Solaris login bug patches out

From: Cy Schubert - ITSD Open Systems Group (Cy.Schubert@uumail.gov.bc.ca)
Date: 01/02/02 

From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
To: Jan-Philip Velders <jpv@jpv.xs4all.nl>
Date: Wed, 02 Jan 2002 14:36:27 -0800

In message <Pine.LNX.4.05.10201010115230.32509-100000@jp-gp.vsi.nl>,
Jan-Philip
 Velders writes:
>
> > From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
> > Subject: Re: Sun Solaris login bug patches out
> :) My objection is the generalization of the 'reboot' issue, and the
> overall 'rush' to install the latest greatest patches. In my
> experience there are a lot of admins who install a patch the moment
> they see one announced. But when asked what the patch is for, most of
> them don't know...

Obviously that can be problematic too. IMO both extremes should be
avoided.

>
> > > [ ... ]
> > Applications that require 24x7 availability should be installed on
> > clustered systems.
>
> Or have other failsafe procedures taken.

Each application needs to be managed differently. Most depends on
business requirements. However management may require 24x7 but not be
willing to invest in the infrastructure to achieve 24x7. In that case
it is questionable whether the business requirement actually requires
24x7, otherwise the investment would be made. I've seen too many
instances where 24x7 was expected but when time came to actually make
the investment, the rubber didn't hit the road. One can only judge the
objective by the what is performed to achieve that objective.

>
> And breaking that expectency is very hard.

I recall taking an IBM course about managing customer expectations. It
is difficult but it can be done.

>
> > [ ... ]
> > It's been documented that historically 80% of exploits are perpetrated
> > by insiders, e.g. employees. Your firewall protects you from the 20%
> > of the attacks that come from the outside. On the inside you need to
> > make sure that your software is as resistant to attack as possible.
>
> Yes, but you have to differentiate between network based attacks (PoD
> etc.) and host based. In my experience a lot of users also have a
> notion of not being 'trusted' by the admins, because all those patches
> fixing host based root compromises are installed...

Internal attacks can be network attacks. For example, a Oracle server
which only allows Oracle admins to login while everyone else uses
sql*net or some distributed application. In large organizations, such
a government, users may be trusted by management however they may be
considered untrusted or semi-trusted by they sysadmin group. Creating
multiple firewalls within an organization may be unfeasible due to the
expense involved. An alternative would be to apply patches on a
regularly scheduled timetable.

Also, security through depth suggests that more than one layer of
security be used. Patching systems on a regularly scheduled basis +
applying emergency patches as required, in addition to other good
security practices may foil an attempt regardless of the source
(internal or external) in the event that one of the security layers may
fail. IMO applying vendor recommended patches every 3-4 months, 6
months at the latest, is the last layer of defence.

>
> You have to balance it out. Which risks are deemed acceptable for
> which systems ?

Obviously. For example, we manage a system that is not connected to
the network and has one authorized user. We don't patch it, ever. The
risk of remote exploit of this system is 0. The risk of local exploit
is ~ 0. For systems connected to the network, the very least thing we
can do is apply patches at regular intervals (in addition to other good
practices such as good passwords, etc.).

> > > [ ... SGI IRIX 6.2 machine ... ]
> > > Even if it were unfiltered from the Internet, it's a rather secure
> > > system, and doesn't warrant any updates/patches/whatever...
>
> > Would you be willing to put your job on the line for that?
> > Probably not.
>
> yes.
> I know who stripped the system, and trust in his capabilities.

You're more adventurous than I am. I wish you the best of luck.

>
> The same goes for my own workstations, those also are rather secure.
> My servers are a bit different, certain r-services are deemed
> 'necessary', but I try to isolate and compartmentalize problems and
> possible entry-points...

Replace the "r" services with ssh.

>
> > A port scan might be a good idea to make sure you don't have any
> > surprises waiting for you.
>
> Port State Service
> 22/tcp open ssh

This I can understand. In many cases this is needed and is the
solution to many remote access issues.

> 23/tcp open telnet

Why would you need telnet if you already use ssh?

> 111/tcp open sunrpc

Why is this in use? The list you posted did not include any RPC
services or did you post a complete list? Is it possible that you have
an NFS server running on this system?

> 513/tcp open login
> 514/tcp open shell

Both of these can be replaced by ssh. Both can be exploited through
DNS cache poisoning and IP address spoofing. IP addresses of trusted
hosts can be spoofed by other hosts on the same physical network as the
host you trust and can be used to spoof TCP connections. Also, rlogind
and rshd have poor MITM attack detection. SSH V1 is better and SSH V2
is the best to protect against this.

>
> Remote operating system guess: IRIX 6.2 - 6.5
> Uptime 149.444 days (since Sat Aug 4 15:50:29 2001)
>
> Port scans - as well as other tools - are an essential part of every
> admins toolkit. Apart from setting something up secure, you also have
> to monitor, check etc.

You've posted some useful information about your SGI so far. What is
its IP address? (I promise not to touch it). :)

>
> > Regards,
> > Cy Schubert
>
> Kind regards,
> JP Velders
>

Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/Alpha Team Email: Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD
Ministry of Management Services
Province of BC
                    FreeBSD UNIX: cy@FreeBSD.org

Relevant Pages

  • Re: Is Windows 98 SE More Secure Than OS X?
    ... So you don't see any importance in the fact that the hackers had SSH ... copy of OS X and install it clean on a Mac. ... nudge nudge> ... Funny that the more M$ patches their POS, ...
    (comp.sys.mac.advocacy)
  • Re: Puzzling printing problem - help!
    ... They could then install patches, got SSH working, etc. ... Bill Vermillion - bv @ wjv. ...
    (comp.unix.sco.misc)
  • Re: Instead of freebsd.com, why not...
    ... > come out in the last year that require rebooting during their install. ... > attacks and other trouble on the Internet today. ... Another little Microsoft secret for Microsquish ... I've installed the patches for the JPEG vulnerability. ...
    (freebsd-questions)
  • Re: Puzzling printing problem - help!
    ... > second server and then re-name ... They could then install patches, got SSH working, etc. ...
    (comp.unix.sco.misc)
  • Re: Puzzling printing problem - help!
    ... > second server and then re-name ... They could then install patches, got SSH working, etc. ...
    (comp.unix.sco.misc)