Hardening Fedora
by Will Yonker
Hello all,
Is there a hardening Fedora guide that is kept
current? I did a quick Google search but only found some information
for FC2 & 3.
If not, is there any interest in having
one?
---
Will Y.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
12 years, 4 months
Security release criterion proposal
by Adam Williamson
Hey, all. The topic of whether and which security issues should block
releases has come up several times before. While we haven't actually had
many really serious security issues to worry about since the
introduction of the current release criteria system, I think it's
certainly something we should take into account. At the same time, it's
fairly established in practice that we don't just consider anything
worth issuing a CVE for as a release-blocking bug. So, to capture what I
believe would be the intent of the project, I propose this as an Alpha
release criterion for F16 onwards. (For those on devel and security
lists who may not be completely familiar with the release criteria /
blocker system, this would mean that any bug for an issue which breached
the criterion should be considered a release blocker for any Alpha, Beta
or Final release).
# There must be no known remote code execution vulnerability which could
be exploited during installation or during use of a live image shipped
with the release
Points to consider:
* Possible variants to the type of vulnerability covered...do we also
want to make local privesc vulns blocking? Conversely, do we want to
make only remote *root* execution vulns blocking? I don't know if anyone
would want to go as far as making DoS vulns release blocking, but speak
up if you would! (Of course there is again the local/remote distinction
to consider there: 'all DoS vulns' would be a much tighter standard than
'remote DoS vulns').
* The caveat about where the issue is exploitable is important because
if you can't exploit it from the installer or a live image, it becomes
less relevant whether we ship with it or not, because you would be safe
with the first post-install update assuming we submitted an update for
the issue promptly. But it may be the case that we want to broaden it
out to also cover issues that can be exploited from a default DVD
install, if we consider the window between install and first update (if
updates repos aren't used during installation) to be unacceptable.
* We have a system whereby the criteria get more onerous from Alpha to
Beta to Final, so it could be the case that we accept worse security
issues in Alpha than in Beta and so on; we could have a loose criterion
for Alpha and a tighter one for Beta. In this case it felt sensible to
me to just go with one criterion, but please say if you disagree.
* The aim of the release criteria is more to codify existing practice
than to extend it; we have taken security issues as release blockers
before and considered but rejected less serious ones, but we have done
so on an ad hoc basis. I tried to write the criterion to reflect our
past practice on this. So precedents are important here; if you have any
that contradict the proposed criterion, please do cite them.
Feedback please! Thanks :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12 years, 4 months
Default Fedora installation suffers from egregious configuration flaw
by dirk cummings
On a default install of Fedora 14, and also the latest release candidate for 15, the user is presented with:
An iptables rule that opens port 22 to the worldsshd service automatically startedsshd_config with default option: PermitRootLogin yes
It's like every new install comes with the keys to the castle hanging on outside of the door for anyone who comes knocking.
I find this situation a serious oversight in light of the fact that Fedora obviously values security (like selinux, or how the installer forces a minimum password length, etc)
Any experienced linux user will know to check iptables and disable unnecessary services, but I wouldn't expect this from a new linux user (exactly the people the refreshed GNOME experience is supposed to attract). I think the default configuration should be in the name of security, and sshd should not be listening on a default port with an open rule with root login enabled.
~Team Edward~
12 years, 4 months
Re: Default Fedora installation suffers from egregious configuration flaw
by Joe McManus
As a compromise why not change IP Tables to only allow connections
from the local subnet to SSH on reboot/firstboot ?
i.e. DHCP gets IP address 192.168.1.200 with subnet mask 255.255.255.0
so connections are allowed in from 192.168.1.0/24.
-Joe
Message: 8
Date: Thu, 19 May 2011 07:18:38 -0600
From: Kevin Fenzi <kevin(a)scrye.com>
Subject: Re: Default Fedora installation suffers from egregious
configuration flaw
To: <security(a)lists.fedoraproject.org>
Message-ID: <20110519071838.5f49864a(a)ohm.scrye.com>
Content-Type: text/plain; charset="us-ascii"
On Wed, 18 May 2011 17:35:38 -0700
dirk cummings <sexynaya2010(a)hotmail.com> wrote:
>
> On a default install of Fedora 14, and also the latest release
> candidate for 15, the user is presented with:
>
> An iptables rule that opens port 22 to the worldsshd service
> automatically startedsshd_config with default option: PermitRootLogin
> yes It's like every new install comes with the keys to the castle
> hanging on outside of the door for anyone who comes knocking.
>
> I find this situation a serious oversight in light of the fact that
> Fedora obviously values security (like selinux, or how the installer
> forces a minimum password length, etc)
>
> Any experienced linux user will know to check iptables and disable
> unnecessary services, but I wouldn't expect this from a new linux
> user (exactly the people the refreshed GNOME experience is supposed
> to attract). I think the default configuration should be in the name
> of security, and sshd should not be listening on a default port with
> an open rule with root login enabled.
The reason for this has been headless installs. Ie, if you install via
vnc or the like, and finish the install and reboot and don't have
access to the physical console, ssh is your only way to access the
newly installed machine and setup accounts, etc.
If someone can come up with a solution that covers this case, we could
revisit this, but it's not an case thats easy to fix in any kind of
clean way. ;(
If it's brute force attacks that are the vector of concern, perhaps we
could look at a default hashlimit rule in front of the ssh. (ie, 1
attempt per minute or the like).
kevin
12 years, 4 months
Ruxcon 2011 Call For Papers
by cfp＠ruxcon.org.au
Ruxcon 2011 Call For Papers
The Ruxcon team is pleased to announce the call for papers for the seventh annual Ruxcon conference.
This year the conference will take place over the weekend of 19th and 20th of November at the CQ Function Centre, Melbourne, Australia.
The deadline for submissions is the 30th of July.
* What is Ruxcon?
Ruxcon is the premier technical computer security conference in the Australia-Pacific region. The conference aims to bring together the individual talents of the best and brightest security folk in the region, through live presentations, activities and demonstrations.
The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security.
Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community.
For more information, please visit http://www.ruxcon.org.au
* Presentation Information
Presentations are set to run for 50 minutes, and will be of a formal nature, with slides and a speech.
* Presentation Submissions
Ruxcon would like to invite people who are interested in security to submit a presentation.
Topics of interest include, but are not limited to:
o Mobile Device Security
o Virtualization, Hypervisor, and Cloud Security
o Malware Analysis
o Reverse Engineering
o Exploitation Techniques
o Rootkit Development
o Code Analysis
o Forensics and Anti-Forensics
o Embedded Device Security
o Web Application Security
o Network Traffic Analysis
o Wireless Network Security
o Cryptography and Cryptanalysis
o Social Engineering
o Law Enforcement Activities
o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc)
Submissions should thoroughly outline your desired presentation subject.
If you have any enquiries about submissions, or would like to make a submission, please send an e-mail to presentations () ruxcon org au
The deadline for submissions is the 30th of July.
If approved we will additionally require:
i. A brief personal biography (between 2-5 paragraphs in length).
ii. A description on your presentation (between 2-5 paragraphs in length).
* Contact Details
Presentation Submissions: presentations () ruxcon org au
12 years, 4 months
Ruxcon 2011 Call For Papers
by cfp＠ruxcon.org.au
Ruxcon 2011 Call For Papers
The Ruxcon team is pleased to announce the call for papers for the seventh annual Ruxcon conference.
This year the conference will take place over the weekend of 19th and 20th of November at the CQ Function Centre, Melbourne, Australia.
The deadline for submissions is the 30th of July.
* What is Ruxcon?
Ruxcon is the premier technical computer security conference in the Australia-Pacific region. The conference aims to bring together the individual talents of the best and brightest security folk in the region, through live presentations, activities and demonstrations.
The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security.
Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community.
For more information, please visit http://www.ruxcon.org.au
* Presentation Information
Presentations are set to run for 50 minutes, and will be of a formal nature, with slides and a speech.
* Presentation Submissions
Ruxcon would like to invite people who are interested in security to submit a presentation.
Topics of interest include, but are not limited to:
o Mobile Device Security
o Virtualization, Hypervisor, and Cloud Security
o Malware Analysis
o Reverse Engineering
o Exploitation Techniques
o Rootkit Development
o Code Analysis
o Forensics and Anti-Forensics
o Embedded Device Security
o Web Application Security
o Network Traffic Analysis
o Wireless Network Security
o Cryptography and Cryptanalysis
o Social Engineering
o Law Enforcement Activities
o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc)
Submissions should thoroughly outline your desired presentation subject.
If you have any enquiries about submissions, or would like to make a submission, please send an e-mail to presentations () ruxcon org au
The deadline for submissions is the 30th of July.
If approved we will additionally require:
i. A brief personal biography (between 2-5 paragraphs in length).
ii. A description on your presentation (between 2-5 paragraphs in length).
* Contact Details
Presentation Submissions: presentations () ruxcon org au
12 years, 4 months
