A new hack?

Home » Asterisk Users » A new hack?
Asterisk Users 23 Comments

On Sat, 26 Nov 2011, Terry Brummell wrote:

> Install & Configure Fail2Ban then the host will be blocked from
> connecting. And no, it’s not new.

I don’t need Fail2Ban, thank you. But your advice might be useful to
others.

Gordon

>
> —–Original Message—–
> From: asterisk-users-bounces@lists.digium.com
> [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Gordon
> Henderson
> Sent: Saturday, November 26, 2011 6:55 AM
> To: Asterisk Users Mailing List Discussion
> Subject: [asterisk-users] A new hack?
>
>
> Or just an old one that I’ve not noticed before…
>
> Seeing lines like this in the logs:
>
>
> [Nov 26 08:47:17] NOTICE[789] chan_sip.c: Sending fake auth rejection
> for user “VOIP” ;tag=E2lb2p9BOJ
> [Nov 26 08:47:17] NOTICE[789] chan_sip.c: Sending fake auth rejection
> for user “VOIP”
;tag=XMDRarBM2w
> [Nov 26 08:47:19] NOTICE[789] chan_sip.c: Sending fake auth rejection
> for user “VOIP”
;tag=AaTE0L0oRj
> [Nov 26 08:47:21] NOTICE[789] chan_sip.c: Sending fake auth rejection
> for user “VOIP”
;tag=igsN240Wr5
> [Nov 26 08:47:23] NOTICE[789] chan_sip.c: Sending fake auth rejection
> for user “VOIP”
;tag=E8Nkbs0Aye
> [Nov 26 08:47:25] NOTICE[789] chan_sip.c: Sending fake auth rejection
> for user “VOIP”
;tag=LEvpc7tK6B
> [Nov 26 08:47:27] NOTICE[789] chan_sip.c: Sending fake auth rejection
> for user “VOIP”
;tag=WrIoZ92YPz
> [Nov 26 08:47:29] NOTICE[789] chan_sip.c: Sending fake auth rejection
> for user “VOIP”
;tag=kuGTjXr7Pd
> [Nov 26 08:47:31] NOTICE[789] chan_sip.c: Sending fake auth rejection
> for user “VOIP”
;tag=ygQBLSjH1m
>
>
> etc.
>
> The IP address is presumably the IP address of some compromised host (in
>
> Germany in this case, but I’ve noticed others around the globe so the
> software doing it would appear to be widespread) – it’s not a host that
> should be connecting in.
>
> I supect that some SIP PBX somewhare is vulnerable to having an account
> called “VOIP”, so this remote attack is trying to compromise that
> account.
>
> At least it’s only once every 2 seconds, so in that respect no worse
> than
> the multitude of pop/smtp/imap/ssh type attacks that hackers try…
>
> I’ve seen it on several servers now, always for account VOIP. I’m
> presuming the “fake rejection” is the side-effect of using
> alwaysauthreject in sip.conf. (if-so, then it’s doing the right thing)
>
> But something to look out for just in-case..
>
> Gordon
>
> —
> _____________________________________________________________________
> — Bandwidth and Colocation Provided by http://www.api-digital.com
> New to Asterisk? Join us for a live introductory webinar every Thurs:
> http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
> —
> _____________________________________________________________________
> — Bandwidth and Colocation Provided by http://www.api-digital.com
> New to Asterisk? Join us for a live introductory webinar every Thurs:
> http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>

23 thoughts on - A new hack?

  • On Sat, Nov 26, 2011 at 7:50 AM, Gordon Henderson
    wrote:

    Why is that?
    Even if they don’t compromise an account they are still using your
    bandwidth and resources on your machine.

  • Linux has excellent built-in subsystems to control firewalling and so on
    without resorting to external programs. It’s called iptables. If you know
    how to use them, then using an external resource such as fail2ban is
    unneccessary.

    For example, with iptables rules you can say something like: If a
    connection from a remote site to a local port happens more than (say) once
    a second then drop that connection.

    And that happens right at the kernel level without the need to run any
    userland software, write config files, monitor log files and so on.

    I’ve posted about it in the past – search the archives if you want to know
    more.

    Gordon

  • On Sun, Nov 27, 2011 at 8:47 AM, Gordon Henderson
    wrote:

    That’s like saying you don’t need FreePBX because you have this thing
    called Asterisk.

    Though I’ve never used Fail2Ban, it is an excellent example of
    “middleware” that looks at application level events and feeds updates
    to iptables.

    So the important blocking is happening in kernel mode, not userland.

    Your example:

    doesn’t always work well for some applications. Ever look at WebDAV
    traffic? Code me an iptables rule that figures out someone is doing
    bad things via WebDAV 🙂

  • On Sun, Nov 27, 2011 at 8:47 AM, Gordon Henderson
    wrote:
    So its not that you don’t need it, but you use something else.
    BTW, you were just proven wrong, you need it for this hack.

  • This may well turn out to just be troll fodder but I can not resist.
    I disagree with the above being very well put, personally I think it is
    the opposite of well put. Maybe I am misunderstanding the gist of the
    comment but, I do not NEED FreePBX, I have Asterisk makes perfect sense
    to me. I have been using asterisk for a few years now and have not yet
    found anything that I need to do with Asterisk that I must have FreePBX
    to accomplish. Could I do the same things with FreePBX on top of
    Asterisk, maybe. I am not an expert in iptables but I have been semi
    successful in adapting what others have done to fit my needs. I have
    found this to work better FOR ME than Fail2ban. I have used and will
    continue to use Fail2ban for other purposes because I am not an iptables
    expert. In my opinion one should find the tools that work best for you
    in your situation and use them. You may well change your mind in the
    future but that is the beauty of this industry, it changes all the time,
    what I feel works best today may well not be what I think works best
    tomorrow as new tools are developed and proven and also as I become more
    experianced with the old tried and true tools.
    As usual, just my 2 cents (US currency, exchange rates not compensated for)
    JohnM

  • In addition to the few hundred protected asterisk installations I run, I
    also run a few honeypots.

    Gordon

  • On Thu, Dec 1, 2011 at 8:13 AM, Gordon Henderson
    wrote:

    Then you should be able to proffer a better argument of why it isn’t necessary.

  • On Thu, Dec 1, 2011 at 8:15 AM, Gordon Henderson
    wrote:

    Protected? You don’t know that until the next hack comes out.

  • How is using Fail2Ban less resource intensive then me writing (by hand) iptable
    rules?

    Also, since both methods involve the use of iptables, where exactly is the
    bandwidth savings?

  • Fail2ban assumes that #1 your environment is (wide) open and #2 you will
    need to update iptables on an “instant response to attack” basis. If you
    are open enough, even fail2ban isn’t going to really help. If you have a
    sufficiently written set of iptables rules (or you aren’t allowing external
    SIP/TCP/UDP traffic) you shouldn’t (just my opinion) need fail2ban at all.

  • It depends on how you define resources and how much of those resources you
    have.

    Gordon (based on my understanding of his posts) does a lot of Asterisk
    systems on very limited hardware hosts. His approach uses iptables
    features to limit the number of SIP INVITES and REGISTERS per second per
    IP address.

    Thus, Gordon’s approach is more responsive (since it doesn’t require
    periodic log file scanning) and requires less hardware resources (since it
    doesn’t depend on running relatively ‘slothish’ resource intensive script
    interpreters like Perl or PHP periodically).

    If you have limited admin skills and more hardware resources, F2B makes
    sense.

    If you have more admin skills and limited hardware resources, Gordon’s
    approach makes more sense.

    Personally, I find any approach that tracks log files ‘hackish’ but if you
    centralize your logging (which I always do) it does allow you to detect
    patterns of abuse across multiple hosts.

  • On Fri, Dec 2, 2011 at 12:44 PM, Steve Edwards
    wrote:

    A very narrow solution to a fairly narrow attack surface and surely
    isn’t applicable to any medium to large scale solutions.

    So Fail2Ban is inefficient on how it reads log files? If so, that
    could be an informed criticism of Fail2Ban.

    Others would say that not using IPS/IDS/adaptive sec appliances is
    hackish but I’m not one of those.

    There are very efficient ways to read log files even with Perl on
    hardware no bigger than my Dockstar when coded properly, so “reading
    log files” isn’t hackish.

    Looking at advanced threats that are encrypted or otherwise located
    within legitimately large streams of UDP and TCP traffic are not going
    to lend themselves to some simpleton IP/port/rate iptables rule or
    even more complex iptables view into the data.

    The application log might be the ONLY place to correlate events. Good
    luck doing that with iptables alone.

  • Sorry I wasnt very clear in my first writing, I’ll try to clarify.
    Using iptables only detects one type of attack (aggressive
    connections). While his machines might be secure enough to allow any
    other attacks and still not compromise his machine, iptables will
    still allow them thru and therefore the attack will be using his
    bandwidth/resources, with f2b one can add as many rules as/when they
    arrive.

    In detection.

  • (This horse just won’t stay dead…)

    My apologies if I mis-attribute who wrote what.

    I think you are over-generalizing.

    You can write iptables rules to detect and respond to many types of
    attacks.

    Since F2B is just an automated front end to iptables you can have as many
    rules as you need with or without F2B. Also, since packets are ‘stopped’
    at the same place (iptables) any bandwidth savings would only be to
    services that you are running that either aren’t or can’t* be nailed down.

    How about ‘in responding to an attack your iptables rules don’t already
    mitigate and you do have F2B rules defined for?’ ‘Detecting’ an attack
    means close to nothing if you don’t respond to it 🙂

    I’m not hating on F2B, it’s just not a silver bullet nor is it appropriate
    for all environments.

    Your security needs depends on your environment. At this point in time,
    all of the hosts I manage for my clients exist in very limited
    environments and have very small attack surfaces. They are racked in
    secure data centers. They only accept SIP from clients with static IP
    addresses that we have an existing business relationship with. They only
    accept SSH connections from me. They only accept HTTP connections from me
    and my boss. That’s about it. I don’t see where F2B adds much value for
    me.

    *) Lots of admins think they can’t limit access to servers because they
    have ‘mobile’ users. Your users probably don’t need to access your servers
    from every single place on the Internet. If your users don’t come from
    China, North Korea, Iran, etc, you can block entire regions with a few
    rules and eliminate 80% of probes and attacks from reaching your servers
    in the first place. Apologies in advance if you happen to live in some of
    these regions — feel free to `s/China, North Korea, Iran/United States,
    Canada, England/g`

  • Possible. But working off the logs makes lots more sense for creating
    more accurate to the point rules, and to mention on the fly.

    You didn’t get my point. If someone is trying to exploit some type of
    dialplan hack in slow motion. iptables will probably not detect it and
    your machine is secure enough that the exploit doesn’t work, but the
    script kiddie behind the attack doesn’t know that and keeps trying.
    Your wasting resources and bandwidth. With f2b you can have him added
    to iptables after the first try. Once all packets are dropped from
    that IP, while the attacker is still using resources/bandwidth while
    trying after a while they will stop as all packets are dropped. The
    reason they are trying is because it wasn’t blocked but now that it is
    they will stop.

    I think you are just explaining my point. Correct me if I’m wrong.

    Agreed, like another poster said, its the easy way out since it’s an
    easy front end. The only reason for this thread is because someone
    mentioned he doesn’t *need* it.

    Speaking of which, how secure? I have biometrics access to about a
    dozen such centers. Once inside the center how hard is it really to do
    what you want?

    Well others keep their servers shut. While I’m sarcastic, I’m also
    trying to say its way to overdone. A good IDS/IPS will do, there is
    really no reason to this. Except in environments that require it, in
    my opinion national infrastructure etc.

  • Perhaps an other suggestion.
    If they are “true road warriors”, i presume they are capable of setting
    up an vpn to the company.
    In that case, only allow registrations/calls through the secured
    tunnel. Then it’s not any concern to asterisk.

    And if they can breach your tunnel, you have something else to worry
    about.

    hw

  • Well, that means opening up VPN connections from everywhere. Thats why
    I suggested turning off the server completely.