Re: Basic question about ipchains being useful
> > http,
>
> Beware of security alerts.
>
> > ftp,
>
> Beware of security alerts, big-time.
>
> > smtp,
>
> Which MTA?
>
> > ssh,
>
> beware of security alerts.
>
> > bind
I'm using these packages with the latest versions in
stable : postfix, apache 1.3.9 (quite old btw but not
necessarily a problem), bind 8.2.3, openssh 1.2.3
I installed wu-ftpd from testing because I've read
that version 2.6.0 in stable had a security hole
(fixed in 2.6.0-5.1 so it wasn't really required
anyway)
My idea is not to look at security alerts but trust
that debian maintainers will do it, I have a daily
cron
job which mails me if "apt-get -s upgrade" says
something
should be upgraded, is this not reasonable ?
Is there any case where a package with a known exploit
was not upgraded quickly in stable ?
> ) with ipchains/iptables you have a choice of
accepting, rejecting or
> dropping packets. If you reject them, they know you
exist. If you drop
> them, they have to wait for a timeout before they
know anything about you -
> you can play dead.
Yes but what should I want to drop them, as I would
only deny
packets for services I'm not running, a potential
attacker would
just get a timeout for services which aren't running
anyway.
> a2) you get the ability to filter TCP access to BIND
right out. Chances are
> you won't miss it, except for your secondary
nameservers.
I've read that I shouldn't filter out DNS requests for
DNS because big
requests which must be fragmented have to use TCP
instead of UDP.
> b) you get logging of *all* packets that don't make
it through, not just
> the ones snort says are interesting. (Bear in mind
that snort, with all the
> best will in the world, is only retroactive.)
In which case is there a rule interesting for me which
I could setup with
ipchains and not with snort ? Both tools are a bit
redudant. The only case
I'm thinking at is to deny access to opened services
to hosts from which
snort logged an attack attempt.
> c) you get the ability to filter invalid / spoofed
IP#s in the firewall *as
> well as* with rp_filter.
> d) you get the option of egress filtering. If you
know you should never be
> accepting packets from port 25 to the private IP#
range, you can drop them
> and you'll find out when someone cracks you through
BIND and tries to mail
> home.
Rigth, but more generally about the interest of
ipchains : if I have to consider
such packets are dangerous, it means that opened
service are not secured, can't
I just rely on having most recent versions installed
and be confident but for
zero day exploits ?
Thanks for your help
Julien
___________________________________________________________
Do You Yahoo!? -- Pour faire vos courses sur le Net,
Yahoo! Shopping : http://fr.shopping.yahoo.com
Reply to: