Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-Linux
[Top] [All Lists]

Re: Linux Hardening

Subject: Re: Linux Hardening
Date: Mon, 22 Oct 2007 20:13:37 +0200
On 2007-10-21 Liran Cohen wrote:
Ajai Khattri wrote:
On Wed, 17 Oct 2007, Liran Cohen wrote:
what is the machine's location on your network (LAN\DMZ etc...) what
is the machine role, you should ask yourself some questions before
approaching hardening, I would not put the same effort on a machine
which is located on my LAN as much as I would make sure that DMZ
machines are protected

I believe even machines on internal networks should all run local
firewalls at the very least. There's always some Windoze user using
Outlook and clicking on an email attachment they shouldn't click
on...

And then what? The services you need to be accessible in your LAN will
still be accessible (and thus exploitable) even if you run local packet
filters, because you need them to be accessible.

If any of your computers become infected because of someone clicking on
an attachment, your security concept has already failed several times,
and you should ask yourself some serious questions, including (but not
limited to):

- Why didn't the spam/malware filter on your mailserver catch the
  attachment?
- Why didn't the local virus scanner catch the attachment?
- If the attachment is an executable: why did your Software Restriction
  Policies (and temp directory settings) allow it to be executed?
- Why was an unneeded service running on the remote host?
- If it was started by a user: why did your Software Restriction
  Policies allow that?
- If the exploit was not a 0day: why was the system not up-to-date?

On top of that: running a packet filter always means running additional
code that may contain additional (remotely exploitable) bugs. There
already has been a case (W32/Witty.worm) where systems became vulnerable
*because* they were running a local firewall.

I completely agree providing you have the time and dont have a couple
of dozens of Linux machines to maintain daily, in many cases you have
to make a sensible choice  what would be worth more or in other words
asses where the risk is higher and invest most of your efforts there.

Reasonable risk assessments will most likely lead to the conclusion that
host-based packet filters in the LAN are not worth the effort.

Regards
Ansgar Wiechers
-- 
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq

<Prev in Thread] Current Thread [Next in Thread>