All of lore.kernel.org
 help / color / mirror / Atom feed
From: "curby ." <curby.public@gmail.com>
To: hbeaumont hbeaumont <ahlist@gmail.com>
Cc: netfilter@lists.netfilter.org
Subject: Re: blocking irc + botnets
Date: Thu, 4 Aug 2005 15:59:38 -0600	[thread overview]
Message-ID: <5d2f3791050804145926b9c143@mail.gmail.com> (raw)
In-Reply-To: <bc5becf6050804100426d8357a@mail.gmail.com>

On 8/4/05, hbeaumont hbeaumont <ahlist@gmail.com> wrote:
> I want to find a way to make sure that we have an extra layer of protection
> to make sure our servers weren't DOS'ing other boxes - even if it was
> only for a short time until an admin logged in to check the source of the
> outgoing traffic spike.

I'm a big fan of layers . =)

Even though there's only so much that netfilter can do as it generally
only looks at the lower half of the network stack, you can restrict a
lot.  For example, servers don't usually need originate much traffic
at all.  Trust and allow a few IPs for patch servers, time servers,
and DNS servers as opposed to allowing general outgoing traffic out to
ports 21,80,123,53,etc.

Log (with flood limits) dropped outbound traffic.  /dev/rob0 makes a
good point that logging is often useless.  If you have log analysis
tools that are monitored, they can possibly detect everything from
misconfigured software to malicious and mischevious users.

Something else you can do is proxy whatever small subset of external
services your servers can reach.  This can help prevent someone from
tunneling random things over port 80, for example (popular since it's
seldomly filtered).

You might also set netfilter to allow certain programs or users to go
out of certain ports.  I.e. root can go out on port 123 to synchronize
the clock, but a user cannot.  Of course, the more you restrict users,
the more unhappy they get!


  reply	other threads:[~2005-08-04 21:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-02 15:41 blocking irc + botnets hbeaumont hbeaumont
2005-08-02 16:55 ` Daniel Lopes
2005-08-02 18:36   ` R. DuFresne
2005-08-03 16:18 ` Maxime Ducharme
2005-08-04  7:43 ` Jan Engelhardt
2005-08-04 17:04   ` hbeaumont hbeaumont
2005-08-04 21:59     ` curby . [this message]
2005-08-05  6:26     ` Jan Engelhardt
  -- strict thread matches above, loose matches on Subject: below --
2005-08-02 16:37 Piszcz, Justin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5d2f3791050804145926b9c143@mail.gmail.com \
    --to=curby.public@gmail.com \
    --cc=ahlist@gmail.com \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.