Re: Monitoring outgoing IRC

From: Alexander Clouter (alex_at_digriz.junk-this.org.uk)
Date: 10/19/04

  • Next message: moo: "Re: Automatic blocking of attackers' IP" 
    Date: 18 Oct 2004 17:48:18 -0500

    On 2004-10-17, Newsbox <dontspamme@thanks.invalid> wrote:
    >
    > I get your point. I try to keep updated on new/ongoing security issues,
    > etc., and sometimes use IRC.
    >
    Well I noticed you are already looking at SANS which is a good place to
    start. Their @RISK newsletter is _very_ helpful; Monday's was particularly
    'interesting', my Windoze collegues are tearing their hair out meanwhile
    though....ho hum.

    Another thing you might like to think about are RSS feeds. Get yourself a
    Jabber Account[1] then use a remote JabRSS transport[2] and you get informed
    with a 'latency' of about 30 minutes. Easy to trim through all the
    background noise as well.

    > I was just looking for an easy way to monitor any/all IRC connections from
    > this system to be reassured that there were no unintended IRC connections,
    > as by trojan code. I have already taken precautions against that, but
    > layers of reassurances are better, if none too good to assuage my own
    > paranoid tendencies with respect to my own internet connected system
    > security.
    >
    Well the 'best' approach is where you blacklist everything and then poke
    holes as need be. This applies to all types of traffic. Of course there
    are many reasons why this can be impractical but I think (by the sounds of
    it) its possible in your environment:

    a) start with 'iptables -A FORWARD -j REJECT'[3] and unblock from there
            (rather a default policy of REJECT 'iptables -P FORWARD REJECT' but
            you get the idea :)
    b) install a transparently web proxy. This means that all web traffic is
            forced to go through the proxy and you can centrally white/blacklist
            sites
    c) as people start complaining certain things do not work (after you have
            already laided down what you consider 'valid') get them to explain to
            you why they need to be able to do task xyz and then decide if you
            should poke a hole for it
    d) if you do not deal with certain countries 'de-peer'[4] from them (you
            probably will want to make traffic going through the web proxy an
            exception)
    e) install 'snort' on the WAN (external internet facing) interface and learn
            how to read the logs. Do _not_ get trigger happy or overly-excited
            but learn what they mean (for example you will learn to not worry
            about portscans, unless they source from your LAN, probably after a
            while). Notice what people are doing and you might decide to make an
            'informed' decision about how to implement some iptables rules.

            I repeat again, do not be trigger happy with 'snort'; intrusion
            detection systems are rather good at producing many false positives
            (for example P2P traffic 'looks' like a portscan) unless well
            configured which is a tricky thing for anyone to do
    f) never forget about egress (outgoing) traffic and you should aggressively
            log anything 'unexpected' to play with in the morning as part of your
            'over-coffee' routine
    g) you might want to read the Adv-Routing-HOWTO on how to do some basic QoS
            so that an outgoing (D)DoS attack is converted to a puff of smoke
            rather than a huge fire. Lets imagine a trojan that fires out a
            stream of ICMP Echo (aka ping) packets as quickly as possible, this
            could easy saturate your connection. If you limit ICMP traffic to
            say 5kB/s (rather high never the less, but the point of the rule is
            to 'cap' any potential future problem) then a 5kB/s outgoing ping
            stream hopefully will not hurt compared to a potential 1MB/s one!
            You then have a iptables (or use snort) to pick up and log the
            excessive traffic. Make careful use of the LIMIT matching rule, even
            for the logging otherwise you might find /var/log filling up and DoS
            yourself!
    h) <insert countless other ideas; I want to go to bed.... :) >

    Do ask if you do not unstand clearly the advantages (and disadvantages) of
    the above approaches. These are not necessary the 'best' things, but they
    are relatively straight forward and sensible places to start.

    I will not of course go into any real detail as thats what Google, TLDP[5],
    Google Groups and USENET is for :)

    > Thanks for the suggested rule, very much !! It was what I was hoping for
    > when I posted. After some minor research, I added a rule based on it and
    > did not see anything logged (which is a good thing!). Unfortunately I
    > still have to add the rule maually each time I connect, several times a
    > day. That will be worked out as I look at this more carefully in coming
    > days. You gave me a giant leap forward, which I really appreciate.
    >
    This is distro specific and you will also find a number of packages probably
    suited for this. Check with your distro's website what is the 'best' way to
    do this.

    > "layer-7 filtering", sadly, leaves me once again in some kind of "newbie
    > hell", and that after several years of googling and reading. ... Don't
    > think I can really afford any heavy CPU expense, but thanks for the
    > pointer anyway, and I'll save it till later.
    >
    IPTables is a Layer 3 and 4 filter (if I remember properly, I never can
    remember my 'OSI Layer' diagram) which means you can pick about things like
    source/destination IP (this is the IP protocol, layer 3) and also things like
    port numbers and SYN flags[6] (layer 4).

    Layer 7 is actually the HTTP/SMTP/Jabber/MSN/IRC/etc protocol bit. The
    actual payload sent to and from the client/server. This would effectively
    enable you to say "if someone connects with IRC and says their 'nick' is
    'Bob' then REJECT the connection".

    This is of course avaliable for Linux[7] however the downside is it munches
    CPU cycles for breakfast/lunch/dinner and snacks inbetween..... :-/ It has
    its place but I'm not personally a keen fan of it; it would be a bad idea to
    base your security policy around a L7 firewall, however it would be equally
    foolish to not know one is avaliable if you need it. Remember to think
    scalibility though in Real Life(tm) :)

    > [snipped]
    >
    > need to do are important and important to protect, and those are the
    > things that earn our resources, efforts and our time.
    >
    Well more importantly it lets you know your system can look after its self if
    need be (however thats usually when Murphy's Law is invoked) and you can sit
    back and get down to more important things.....xpilot...usenet....plan9... :)

    At $ork we are always putting in new things to increase our potential
    'laziness' and so in the end we could sit back on a huge pile of cash coming
    in with little effort, counting it. Gives me a chance to take a breather and
    beat the minions into being more 'efficient'. Must polish up the "6 iron of
    'redemption'", then this is possibly the wrong crowd for that kind of talk :)

    Cheers

    Alex

    [1] http://www.jabber.org/
    [2] http://jabrss.cmeerw.org/ (subscription is jabrss@cmeerw.net)
    [3] don't get me started on those folk whom DROP rather than REJECT;
            (I wrote) the stealth section of
            http://support.metronet.co.uk/adsl/standard-emails/security.txt
            this is all getting re-written as I'm not explaining myself clearly
            in a couple of cases
    [4] 'de-peer' means no longer accept traffic to/from. A very simplistic
            example is if you only connect to UK IRC servers then de-peer with
            everything non-UK. Of course you need to think about what you are
            doing but I hope I am explaining myself clearly :) Use
            http://ip.ludost.net/ to create a list and drop into an iptables
            chain. Many people use this for their mailservers; "our company does
            no business with the US/China, block all mail from those
            countries....oh look spam has shot down 90%".
    [5] http://www.tldp.org/
    [6] the UDP and TCP layer, remember UDP and TCP is a completely different
            protocol to IP and is encapsulated in an IP layer to move across the
            Internet. To form TCP/IP and UDP/IP. Much like when you connect
            with a dialup modem you get PPP->IP->TCP where the whole lot is
            wrapped (encapsulated) in the PPP protocol
    [7] http://l7-filter.sourceforge.net/

    ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= East/West-Coast Server Farms - Total Privacy via Encryption =---

  • Next message: moo: "Re: Automatic blocking of attackers' IP"

    Relevant Pages

    • Re: Defense in Depth
      ... What is meant by "layers" of security, is this: the entry points that must be ... Physical Layer - Physical access to the resources. ... attacks and other attacks that go after the software itself. ... "layer" in one long chain (lots of firewalls). ...
      (Security-Basics)
    • Re: Forest/Domain in the "DMZ" to accomodate web, front-end servers
      ... Now as for ISA 2004 being a seamless application layer inpspection security ... out of it too, but I have 500 servers, and 3000 desktops to worry about. ...
      (microsoft.public.security)
    • Announcement: "A Treatise on Informational Warfare"
      ... Dear Security Focus Community: ... Treatise on Informational Warfare". ... for human against computerized agent, agent against agent, agent against ... Communications Layer 9 ...
      (Bugtraq)
    • Re: Botnets
      ... We are talking about IRC botnets... ... infect the system in the first place. ... block 443 will help you with security, ...
      (Pen-Test)
    • Re: Business flyers wont fly without hand baggage
      ... for the security of something that they should be securing ... No, they've added another sensible layer of protecting the data, no ... What outsourcing? ...
      (rec.travel.air)