Bug 17483 - RFE:General security/networking config suggestion.
Summary: RFE:General security/networking config suggestion.
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 6.2
Hardware: All Linux
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2000-09-13 22:54 UTC by Harvey Stein
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-29 21:39:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Harvey Stein 2000-09-13 22:54:31 UTC
Would it be difficult to ship RH so that the default installation is
always reasonably secure?

What about doing the following:

 1. Default install enables IP firewalling.  It only accepts packets
    from  It doesn't forward packets.
 2. Default install sets up /etc/hosts.allow & /etc/hosts.deny so that
    the machine only accepts connections from
 3. When adding an IP interface, the system by default allows anything
    out of the box, but doesn't allow incoming SYN packets except on
    ports 1024-5999, 6010-.  The user could optionally list services
    & IP address masks for which incoming packets should be accepted.
    These would be added into IP firewalling & /etc/hosts.allow to
    allow it.

I'd think this would be much safer for the average clueless user,
would make the box work fine when dropped on a network (at least from
the point of view of a user sitting at the keyboard), would be
reasonably secure both on a local net & the internet, and would be
sufficently easy for the more clue-full user to set up specific
servers on, and would generally be easier to secure both for the
newbie & the hacker.

Pekka Savola <pekkas@netcore.fi> objected that:

You must be realistic that this can't be done; should not be done.
If a default firewall ruleset  were to be included it should be one that
would function without modifications for most people.  

My response was:

I think that what I'm proposing would work for most people without
modification.  I'm assuming that most people who install Linux don't
mean to be hosting network services, let alone hosting all networking
services for access by the world at large.  And, practically speaking,
the current config needs modifications by most people anyway - whether
it's closing off all services because it's really a workstation (which
is necessary because who runs Linux & doesn't connect to the
internet?) or securing the box by only allowing specific services in
because it really is a server on the internet or otherwise, or
configuring the thing to be a router or an IP masquerading gateway.

As far as I'm concerned, under the current configuration *everyone*
who installs Linux needs to muck with the configs to make their
machine reasonable & safe.

Under my proposal, the only time it needs adjustment is when someone's
trying to make a server available to outside boxes, at which point the
user could do it when installing the hardware or by running some
network config tool or other.  The info would be in the configs for
each interface (/etc/ssyconfig/network-scripts/ifcfg-*), so anyone
doing hand tweaking would see the defines there & could hand tweak
them.  Anyone using the standard config scripts would get options to
put this data into these config files.

Comment 1 Michael Fulbright 2000-09-14 19:04:58 UTC
Changing to 'enhancement' from 'security'.

I am assigning this to pbrown because this is a distribution issue, not an
installer issue. It may be facilitated
via the install process, but the decision needs to be a group one.

Comment 2 Preston Brown 2001-01-29 21:39:03 UTC
Beta 3 should include a reasonable set of these security suggestions.

Comment 3 Brock Organ 2001-02-19 19:39:22 UTC
verified changes in fisher public beta ...

Note You need to log in before you can comment on or make changes to this bug.