On Fri, 18 Aug 2000, Charlie Brady wrote:

> 
> On Fri, 18 Aug 2000 [EMAIL PROTECTED] wrote:
> 
> > I did something wrong on install?  Is it because as it is it is secure
> > enough?
> 
> We hope that it is secure enough. But we do want and intend to offer
> greater assurance than that.
> 
> > Surely it would be nice to drop and and allow packages at a
> > kernel level,  to provide for even more safety?
> 
> Yes, it would be.
> 
> > Or is there an addon?
> 
> Not *yet*. :-)

Has anyone started on one?  If so please let me know who as I would like
to assist. If not then I guess I might just have to start my own.


> As an aside, people frequently mention PortSentry, so I will make a few
> comments here.
> 
> - There have been some licensing concerns about the "free" status of
> PortSentry - I don't know what the current status is.
> 
> - Using PortSentry creates a significant risk of Denial of Service attacks -
> both deliberate and inadvertent.
> 
> - Using PortSentry does not protect you against exploitation of
> vulnerabilities which may exist in enabled services. It just might protect
> a vulnerable service if disabled services happen to be probed before the
> vulnerable service is attacked.
> 
> - The crackers are one step ahead of tools such as PortSentry in any
> case. They are now using slow scan techniques which cannot be reliably
> detected by tools such as PortSentry.
> 

Indeed,  I run portsentry on box.  Here are my comments on it:

- I agree about them slow port scan techniques.  I have noticed these in
my firewall logs,  instead of scanning port as quickyl as possible,  I see
a single port being scanned every 1-2 mins (sometimes more or less time
than that).  And indeed portsentry does not pick these up.  however after
having portsenty running for one week straight it successfully detected
and blocked the ips' of 12 full blown portscans.  Altrhough one of those
was from my ISP.  hmmm.

- While I agree that e-smith seems very secure as it is,  ipchains are
nice on top of everything.  If you agree I would like to start
implimenting maybe an add-on rpm for e-smith enabling ipchains support.  I
have a pretty decent set of chain rules now (from Trinity - OS mostly).
They block all all important stuff but don't feel too restrictive.  That
is my main problem with some ipchains rules I've tried. If one becomes too
restrictive in everything,  the end user ends up suffering from this. For
example by blocking too many ports AIM would not be able to connect.
Safer?  yes.  Users happy?  no.  Although they shouldn't be using it
anyways at work.  Heh.  But seriously it is possible to be too
restricting. However what i had in mind for e-smith was maybe three
levels,  that could be changed through e-smith manager.  Maybe a "secure",
"fairly open",  and "fort knox" level.  Secure could thus be default
ipchains set to DENY,  and specifically allow for all else.  fiarly open
(which wopuld be good for those wanting to play any sort of online games)
would be default chains of ACCEPT and specifically DENY certain protocols.
And fort knox would be DENY default rules and only alowing in the bare
necesaties. 

Let me know what the general feeling regarding this is.

Cheers,
Steve

Reply via email to