Mailinglist Archive: opensuse-security (601 mails)

[Ragnar Beer <rbeer@xxxxxxxxxxxxxxxxx>]

I'm using SuSE Linux since 5.3 and was always annoyed by having to 
deselect  bazillions of packages that I didn't need and switch off 
all kinds of services when I wanted a simple and secure webserver. 
That's why after a lot of thinking I finally changed to OpenBSD which 
I think is *the* choice for an OS secure out of the box, because it's 
number one goal is to be secure. It's easy to install and easy to 
maintain.
Still SuSE is my first choice for workstations.

Ragnar


> How bout it SuSE? I have bought every version of SuSE since 5.0,
> I have Installed >30 SuSE servers for various clients and given
> away 200 copies of the SuSE 6.4 demo CD at a Govt Expo (in Australia)
> (Thanks to Michaela Geuthner [mailto:mg@xxxxxxx] for the promo material
> he shiped me at short notice from Germany)
> I love SuSE, and thinks it's the best Distro available, yet, a 
> disabled by default
> policy would IMHO be the best thing SuSE could ever do.
> As far as I'm concerned the only thing that should be enabled by default is
> sshd and _thats's_ even debatable.
> Face it, it's not going to make it any harder for your average desktop
> flunkie who want's to setup a kde box and browse the web. If they want
> to run a personal web server or ftp server then that _should_ know how
> to enable it from inetd.conf etc, or they should NOT be running the thing.
>
> I think the harden SuSE script, and SuSE firewall is brilliant, but 
> half of the
> things harden_suse does should be _default_ not options available in an
> optional package in the sec series....
>
> PLEASE PLEASE make a few simple changes to the defaults to help make
> SuSE the most secure Mainstream linux distro out there in.
>
>
> Peter Nixon
> Senior Security Consultant
> IT Audit & Consulting (ITAC) Pty Ltd
> http://www.itaudit.com.au
> mailto:petern@xxxxxxxxxxxxxx
>
>
> --snip--
>
> > To: BUGTRAQ@xxxxxxxxxxxxxxxxx
> >
> > Aleph One wrote:
> > >  CERT Advisory CA-2000-17 Input Validation Problem in rpc.statd
> > >
> > >     Original release date: August 18, 2000
> > >     Source: CERT/CC
> > >
> > >     A complete revision history is at the end of this file.
> > ..
> > >  RedHat
> > >
> > >     http://www.redhat.com/support/errata/RHSA-2000-043-03.html
> >
> > It should be noted that Red Hat states:
> > "Although there is no known exploit for the flaw in rpc.statd, Red Hat urges
> > all users running rpc.statd to upgrade to the new nfs-utils package."
> >
> > This is wrong.
> >
> > Because of a message posted by "ron1n - <shellcode@xxxxxxxxxxx>" on the 5th
> > of August to Bugtraq.
> >
> > I quote:
> > "Included below is an exploit for the recently exposed linux rpc.statd
> > format string vulnerability[0]. I have tailored it towards current Redhat
> > Linux 6.x installations. It can easily be incorporated into attacks against
> > the other vulnerable Linux distributions."
> >
> > I hope Red Hat updates this information.  Although I really hope they'll
> > just disable rpc.* services, most things in inetd, and other daemons *BY
> > DEFAULT*.  If a user can't figure out how to turn on a service, they
> > probably shouldn't be running the service in the first place.  This alone
> > would stop most of the "remote root in default" problems that Red Hat (and
> > other Linuxes) seem to face.  OpenBSD gets this correct, how hard can it be
> > for the various Linux distrubtions to insert some #s in inetd.conf, or have
> > things chmod -x by default?
> >
> > --
> >     www.kuro5hin.org -- technology and culture, from the trenches.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: suse-security-unsubscribe@xxxxxxxx
> For additional commands, e-mail: suse-security-help@xxxxxxxx