Security Forum Wanted?

Discussion in 'General' started by donhwyo, Feb 14, 2009.

  1. donhwyo

    Joined:
    Aug 8, 2008
    Messages:
    293
    Likes Received:
    0
    In another thread I can't find any more there was talk of a forum dealing with security. Does anybody else think this would be a good idea? It could include some best practices and things like how to install failtoban or what ever. I feel it would be a good thing, anybody else?

    Don
     
  2. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0
    I'm for it.
    I think that the more security we will have on a basic Elastix, the more users will be joining us.
     
  3. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    How about a start:

    This works for me with fail2ban:
    (stolen with full acknowledgements to NERDVITTLES and PBXINAFLASH, thanks guys nice work)

    Code:
    #!/bin/bash
    # to fool the script into running on Elastix
    touch /etc/fail2ban.conf
    #to make the notices  more informational
    yum -y install jwhois
    # to go somewhere that is appropriate
    cd /usr/src
    mkdir fail2ban
    cd fail2ban
    # get the script and run it
    wget http://nerdvittles.dreamhosters.com/pbxinaflash/source/fail2ban/fail2ban-update
    echo "Please read and fully understand the script you are about to run before so doing"
    echo "It's origins are from a possible dark place . . . . (press enter to continue)"
    read ok
    less fail2ban-update
    echo "If you agree that this script is a good thing press enter, if not press control c"
    read ok2
    chmod +x fail2ban-update
    ./fail2ban-update
    # to fix the  sender and receiver of notices root, (you can edit this file for appropriate behavior)
    sed -i 's/fail2banXXXXXpbx.dyndns.org/root/g' /etc/fail2ban/jail.conf
    sed -i 's/XXXXXlocalhost/root/g' /etc/fail2ban/jail.conf
    
    
    please replace the XXXXX's with the character we use to separate the user from his domain in an email address (Stupid brain-dead forum software messing with me again!)

    apparently fail2ban@pbx.dyndns.org is a risk to type in the "code" section (spam bots will get you, but fine in the non "code" part which of course the spambots won't read )
     
  4. wiseoldowl

    Joined:
    Aug 19, 2008
    Messages:
    251
    Likes Received:
    0
    For those who may not care to just run a script that is not originally intended for use with Elastix, or who may simply want a better understanding of the process, see this link:

    Fail2Ban (with iptables) And Asterisk

    I'm always just a little reticent to recommend a script from over there (PiaF or Nerd Vittles) for the simple reason that they can change it at any time, and you never know what the change might do. In this case the script is downloading and installing software and there's always a possibility it may install something that's not compatible with Elastix. I would not be so worried about that at the time these messages were originally posted, but if someone finds this six months or a year from now and tries to follow these instructions, there's at least a slim chance that something will be incompatible between the software installed by that script and the then-current Elastix distribution.

    Of course, I would hope that by then either fail2ban or something with similar functionality would be included in the Elastix ISO and/or upgrade, but you never know about that either.
     
  5. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    I can't disagree with wiseoldowl in principal, (Within the context of the thread I usually have a whole bunch of caveats and provisos attached to my posts, I will add them to my signature from now on).

    I of course read the script as I would anything I download, even from here. before running it. It will not run as-is on an Elastix box. There are several over theres of course but Ward Mundy and his cohorts at Nerdvittles/PIAF show by far more integrity and security consciousness than any distribution I am aware of, (They also release security patches and updates between releases)

    Had I trixboxified it and removed all references to "over there" and pretended it was mine, I hope I would have been seen through and exposed although it would not then have apparently been from "over there". (as ever, caveat implementor)

    fail2ban is open source and fully documented on their web site, the paif script merely installs it and adds some rules particular to asterisk and voip traffic, these they themselves pretty well stole from wiseoldowl's quoted reference to voip-info, I added a missing "whois" binary to our distribution and fooled that script into thinking we had actually got an old version of fail2ban in our distribution. and fixed the sender and receiver email addresses to be functional.

    As we here in Elastix have at least started to take security seriously, I suggest everyone peruses this

    http://nerdvittles.com/?s=fail2ban

    for a very complete and wide sweeping article on security.

    (p.s. I have modified my script to hopefully attest to some legitimate security concerns)


    edit: Anecdotally, I myself in the last six months have analysed post-mortem some of these sip attacks, some come in at the rate of hundreds per second (say goodbye to extension 201 almost immediately) and fail2ban would be ineffective due to its inertia (and 201 will be "owned" by something somewhere in a large university in a large country somewhere in south east asia half an hour later, after fail2ban releases its ban) without further essential securities in place, I can't stress how important it is to not have extension the same as passwords as a minimum first line of defence, If you do right now, please change them immediately, turn off anonymous sip connections in the "general" section unless you really need it. browse the size and contents of your /var/log* files regularly. and only allow 5060 from the smallest part of the network that you can get away with, if you don't then it will only be a matter of time before you (or in my case and far worse, one of my clients) are inundated with calls from pissed off people complaining of calls you made (and yes you did) in the middle of the night selling them viagra or trying to scam their credit card numbers. to my eternal discredit, I have been there and done that once, it's not pretty!
     
  6. torontob

    Joined:
    May 18, 2008
    Messages:
    219
    Likes Received:
    0
    Fail2ban is something that I have to still implement. But I think the following would help too:

    How about something like "master-password" something like "passwd-master" from PBXinaFLASH where all of database, FreePBX, Elastix, and CentOS passwords can be updated. Also, how about a bulk extension password changer?

    I actually use the new FreePBX 2.5.beta bulk extension along with random.org digit generator to get random passwords assigned to voicemail and SIP secret.

    Also, iptables!!!!!!!!!!!

    Maybe all of above can be worked on seperately and then brought together by one single script. Who wants to add more to what Dicko (fail2ban) has done? :p
     
  7. wiseoldowl

    Joined:
    Aug 19, 2008
    Messages:
    251
    Likes Received:
    0
    What do you mean, by its inertia?
    And there you have it - one reason I don't like using Nerd Vittles scripts. In this case, some genius made the decision to release the ban after 30 minutes - that's just crazy. People, if the password is programmed into your endpoints (phones, adapters or what-have-you) then there is no reason anyone should ever mistype it. Therefore if there is a failure after three attempts the ban should be measured at least in hours, and better yet in days. But the NV script doesn't ASK you how long you want the ban to be, it just ASSUMES you'll be happy with 30 minutes. Well, I'd be a whole lot happier with a day or two or three!
    And you really DO need it if you want to accept ENUM calls. For all the FUD spread about Anonymous SIP, everybody forgets that's only for INCOMING calls. It does NOT mean that anyone can place OUTGOING calls through your system anonymously. Remember, nobody can do anything if you allow incoming anonymous SIP that the can't do by simply connecting to one of your incoming numbers. The trick is to send such calls directly to an IVR that forces them into the paths you want them to be able to take.
    Let's see. Is there an easy way to get to those from the Elastix interface? Nope, not really. You can click on Reports and the Asterisk Logs but it will not show you the size, nor the contents beyond 30 lines. Most people simply won't do this (unless they are the geeky Linux type that lives for this stuff, or they are paid to do it). The real answer is to develop better tools to monitor the log and to squawk like heck if it detects an attack (using e-mail, SMS messages, robo-calls to select extensions, or whatever it takes to get someone to take a look NOW).
    And what part would that be, if you have offsite SIP extensions. You also forget another effective measure: Make use of the deny and permit fields on the extension setup pages (you may need an upgraded version of FreePBX for that, however).
    How could someone trying to hack our server affect one of your clients? :p Your hints are mostly good (except, I think, for the one about turning off Anonymous SIP - it's advice like that which makes ENUM calls not work) but the fact of the matter is that the Asterisk developers are the ones that could make the biggest difference. We shouldn't even need to use external programs like fail2ban - that level of security should by all rights be built into Asterisk. Why does Asterisk simply log repeated bogus attempts without having a way to say "enough is enough already"?!
     
  8. Chilling_Silence

    Joined:
    Sep 23, 2008
    Messages:
    488
    Likes Received:
    0
    Good post there by wiseoldowl.

    I agree, 30 minutes is *far* too short ... If you're an Administrator setting up your Endpoints, then the password ideally should be complex enough that you *must* copy / paste it. If you have an Ext of 700 and a Password of 700, thats just asking for trouble ...

    To be honest, running my installs all off 4GB CF cards, we turn off pretty much all logging by default and only turn it on if there's something that we specifically diagnose. Some kind of alerting for our NagiOS system could be cool though, that checks every 2 minutes and sends SMS alerts :D That said, if it were just saying "Hey, somebody tried to get in, we've blocked that IP", then I wouldnt really care. That sort of thing can come through as a regular email that I'll get to reviewing in my own good time, mostly because I know the system has taken care of itself :)

    You'd only have to worry about inbound calls if you were allowing DISA, having it announced on your IVR, a weak password, or leaving it open without the proper Caller-ID restrictions. Otherwise the worst most people can do is simply use up all your bandwidth by flooding your system with calls, or bugging your receptionist one call at a time :p

    Its my understanding you've got just as much chance of SSH being compromised through brute-force login attempts as you do SIP. Sure its *possible* to do a MITM attack, but again its my understanding its easier to do traditional phreaking rather than cracking a SIP user account.

    I have been wrong in the past though ;)
     
  9. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    wiseoldowl:

    From the dictionary.com site:-

    in
     
  10. wiseoldowl

    Joined:
    Aug 19, 2008
    Messages:
    251
    Likes Received:
    0
     
  11. wiseoldowl

    Joined:
    Aug 19, 2008
    Messages:
    251
    Likes Received:
    0
    Another security thought: Limit connections

    This is just an additional tip for at least limiting your exposure to the type of fraud we've been discussing. Let's say you have a relatively small system and someone does manage to pretend to be one of your SIP extensions. What you then want is to limit the damage they can do.

    For example, if no one ever makes international calls, route such calls to an ENUM trunk - most will fall on the floor and the ones that don't will be connected at no cost to you. If you only call one or two international destinations, then make routes for those specific numbers, not the entire country. Don't have routes for countries you never call and never would call - be specific in your routing. Remember there is no limit to the number of entries in route dial rules so be specific rather than general - don't send something like 011. or 00. to a trunk; actually specify the country codes you will allow and omit the ones you won't. This will stop you from being hit with bills for thousands of dollars of calls to Nepal, or Cuba or some other high-cost location you'd never have any reason to call.

    Also, in your trunk configuration, utilize the Maximum Channels option - if your organization would never in your wildest dreams have more than four simultaneous calls going out on a particular trunk, then set the maximum channels to 4 (mouse over the words "Maximum Channels" and read, so you will know whether incoming calls are being counted in that limit).

    The idea is to make it so that if, despite your best efforts, someone does break in and has their way with your system for a few hours, at least they aren't going to be able to do anything that costs you a huge $$$ amount. And if their goal is to complete high-cost calls (or many simultaneous calls) on your dime, they may just decide your system is useless to them and move on to a system that's more compliant.
     
  12. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Re:Another security thought: Limit connections

    My original post was based on:-

    a) a real attack 6 months ago that was successful and (painful)
    b) attacks that have and do occur occasionally.
    c) An attempt to supply a script that was in my opinion easy to implement and effective (for me).

    The nature of the attack, I summarized, (I should have said SIP Message Body not SIP packet body, mea culpa. I claim neither authority nor expertize. but I do stand by my analysis.

    wiseoldowl, yes we differ philosophically, this is a forum and should be expected, no I wish no fight with you, and respect your opinions. We are both I believe opinionated. No harm no foul.

    Should anyone care to limit accepted networks to the bare essentials:-

    whois <IPaddress> will almost always return the nature of the network of the ip address probed , pragmatically use the smallest network returned, for example using roadrunner in the US the and looking up a particular ip within that ISP, the networks returned are

    76.173.240.0/21
    76.168.0.0/13

    where 76.173.240.0/21 is the smaller network
    Whenever that client is given an address it will fall within that network.
    this applies to dsl, cable or wireless networks.
    I suggest only a very few iterations of this process will garner the networks that fully encompass your clients, roving or otherwise.

    as ever just my 2cents worth.
     
  13. wiseoldowl

    Joined:
    Aug 19, 2008
    Messages:
    251
    Likes Received:
    0
    Re:Another security thought: Limit connections

    Okay, this is good to know as far as it goes, but it leaves me wondering "so then what"?

    Let's use another example. Let's say you have a particular extension coming in from a particular IP address associated with Verizon DSL. Whois returns this:

    NetRange: 98.108.0.0 - 98.119.255.255
    CIDR: 98.108.0.0/14, 98.112.0.0/13

    Now, I assume you would say that 98.108.0.0/14 is the smaller network. The problem is: What, exactly, are you supposed to DO with that information?

    Let's make it simple: Assume you've upgraded FreePBX to version 2.5.1, so you have the "deny" and "permit" fields. Both "deny" and "permit" are by default set to 0.0.0.0/0.0.0.0 (Permit overrides Deny, so they deny all addresses, then permit all addresses). Now, I'm assuming you could set that extension's permit setting to 98.108.0.0/14 (is that even valid syntax here)? That would prevent impersonating that extension from elsewhere. If that's not what you had in mind, what else would you do with that information (again, assuming you want ENUM calls to come in from unspecified locations that you might not know about in advance)?

    The fly in the ointment is that theoretically Verizon could latch onto another block of IP address (perhaps from one of their acquisitions) and move some or all of their DSL customers to that block without warning. While I admit that's probably not going to happen often, it's still a possibility. And also, what if the hacker you're trying to lock out also happens to be using Verizon DSL?

    And also, this doesn't really explain how you deal with a roaming extension that might try to use a "hotspot" anywhere in the U.S.A. or Canada. I don't know how you possibly could, unless there is a "magic list" somewhere of all valid IP addresses in those countries.

    Just trying to further my understanding of this.
     
  14. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Re:Another security thought: Limit connections

    wiseoldowl:

    previously I noted that:-
    rasterisk -x "sip show peers" |grep '\.'|grep -v '192.168.'
    would list all your roaming extensions
    say

    333/333 98.108.23.44 D N A 5060 OK (45 ms)

    was one answer

    and

    whois 98.108.23.44

    returns:-

    [Querying whois.arin.net]
    [whois.arin.net]
    .
    .
    NetRange: 98.108.0.0 - 98.119.255.255
    CIDR: 98.108.0.0/14, 98.112.0.0/13
    .
    .

    then your extension with an IP address of
    98.108.23.44

    falls within the returned network
    98.108.0.0/14

    You can guarantee the this phone will always have an IP address within that network.

    So you open up your firewall to allow inbound connections (on top of access from your inbound VOIP providers) from:-
    98.108.0.0/14 on port 5060.
    (In reality (and you happened to choose a huge network) replacing /14 with /16 is probably equally effective with a far smaller network alowed).

    DSLAM's and head end cable routers use far smaller networks and empirically exploring your external clients will expose identifiable networks that you can expect to find, maybe Verizon Comcast, Time Warner et al. in your catchment area.

    This is certainly not a "one size fits all" solution and if you have users who roam to east asia, and east europe then all bets are off, and this process won't work for you. (This is is a restrictive policy by my choice) yet the vast majority of the folks here are not in that position and I believe my pragmatic approach (just "one" part of my plan) will work for them as it does for me it , so I threw it in, I guess not for you however.

    Don started this thread to explore security concerns, can we explore the offered solutions (only one so-far) I was hoping for more. wiseoldowl, may I ask you directly (without rancor or challenge) if you have anything constructive to offer here?


    I'm done with butting heads on this issue please can we move on?
    I reiterate:
    My postings here are derived from my experiences, and might or might not have value to you, please accept what you care to and reject anything you disagree with or offends you.
     
  15. torontob

    Joined:
    May 18, 2008
    Messages:
    219
    Likes Received:
    0
    Re:Another security thought: Limit connections

    Not to stop you too from giving out all those good info ;) but to pose a question about fail2ban, I am wondering if setting ban to something like 18000000 seconds would do any harm or even to set it to 999999999999999999999999999999999999999999999999999999 seconds rather than 1800? Aside from the fact 1/1000000000000000000000000000000000000000000000 light million years you might be using that same dynamic IP and not being able to connect to your own network or there any other negative sides to banning an IP in fail2ban for good?

    Thanks,
     
  16. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Re:Another security thought: Limit connections

    torontob:



    Absolutely no harm, 18000000 is nearly 30 weeks, and quite within the realm of uptime for a linux box, Although I perused the fail2ban python script a while ago, I can't say I remember (that CRS again) the size of the the variable used for the timeout my suspicion is that 9999999999999999999999999999999999999999999999999999999999999999999999999999999999 will break somthing, Fail2ban dynamically rewrites the iptables , on reboot or iptables restart then those changes are lost. So if you need to ban someone for life, then please statically set it in your firewall (hardware or ip-tables). (it is possible and even recommended that you edit your configs to specifically not ban your self in fail2ban, (like I did to myself over the weekend while trying to set up a useless POS soft-phone)), (note to self, do what you say not what you do) luckily my timeout was 1800 so no wasted gas)

    (I appreciate the humor, but really, this is really serious stuff here, "Behave!" or I'll have you banned from the Internet for good!)
     
  17. Chilling_Silence

    Joined:
    Sep 23, 2008
    Messages:
    488
    Likes Received:
    0
    Re:Another security thought: Limit connections

    Thats all very well and good about restricting usage to people from the same ISP, but thats still an awfully big list of "potential" IP's that an attacker could use.

    My thoughts are:
    Unless you're connecting via a VPN, dont waste your time with restricting IP's for roaming users (Unless they happen to have a single static IP and wont roam but rather are just external from your LAN). Its not worth the hassle and you can still be "hacked" by somebody from within your own ISP. To be honest thats where most script-kiddies start, scanning the IP ranges they themselves are on.
    Why?
    They generally respond the fastest, as traffic doesnt have to leave the ISP.

    Once a malicious user has had a good go at breaking into your system, if they've not done so within a relatively small time-frame, they'll move on. If the packets are being dropped, they dont continue to bombard a "non-existant" box unless they know its potentially weak.
    With that in mind, ban the IP Address for a good period of time, 1 week or more. On the very very very remote chance (Even more remote than your system is of being compromised) that your External user gets an IP address thats been banned, get them to restart their router at home to fix the problem by obtaining a new IP.

    IMO there appears to be a lot more spreading of FUD around VoIP Security rather than sound, useful advice on the subject.
     
  18. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Re:Another security thought: Limit connections

    Hopefully to return this thread to it's original purpose.

    I propose that

    http://nerdvittles.com/?s=fail2ban

    is a source of sound, useful advice on this subject.

    using a weak password against an extension is extremely ill-advised.

    Protection is better than no protection.

    Humility trumps hubris.

    There is room for more than one opinion in a forum.

    Your comments please . . .
     
  19. wiseoldowl

    Joined:
    Aug 19, 2008
    Messages:
    251
    Likes Received:
    0
    Re:Another security thought: Limit connections

    I guess not, especially if it involves messing with firewalls (where's the firewall configuration utility in Elastix)? For just a brief moment I had a glimmer of hope that you were actually onto something that we non-Linux-experts could use, but I guess not so much.

    By the way, how would YOU know what position "vast majority of the folks here" are in? I ask that because I would guess that just about every Elastix user has at least one or two "roamers" on the system (even on personal systems, I would bet that most users have at least one laptop with a softphone client). Maybe I'm wrong, but I'm not going to assert that "the vast majority" are in any particular situation.
    Probably not unless you consider pointing out the flaws in your offered solutions as constructive, which I'm guessing you don't. I understand that your offered solutions may be helpful to some other people who have the same attitude about security that you do, and are in the same situation you are, and I also understand that part of your attitude is a result of being burned once. But the point I keep coming back to is that ultimately we need solutions that every Elastix user can implement (and ideally, something every Asterisk user can implement). Here we have a system where almost everything is configurable from a GUI and then we go and tell a user, "Oh, and by the way, you need to implement good security, but there's no convenient way to do it and you're probably going to be guessing at some of the settings." That just isn't going to fly (I could add "for the vast majority of users" to this sentence, but I would not have any more data to back that up than you did).
    I think it's pretty obvious, I am rejecting that which I disagree with (and nothing in this discussion has offended me, except perhaps the fact that you apparently think I am offended). :) If by "can we please move on" what you really mean is, "Can I post something that you disagree with and not have you comment on it", that's only a maybe and depends on how strongly I feel about something and how busy I am with other things. This is, after all, a discussion forum, not a pulpit or a lectern. That said, I'm not into beating expired equines and it may well be that there's nothing more to be gained by further posts on this subject.
     
  20. wiseoldowl

    Joined:
    Aug 19, 2008
    Messages:
    251
    Likes Received:
    0
    Re:Another security thought: Limit connections

    Finally a post I can agree with almost 100%, especially the last sentence! I say ALMOST because, at least on the ISP we use, you can restart the cable modem 100 times and you are still going to get the same IP address UNTIL one day the cable company decides to reconfigure their system (usually during the wee hours of the morning), at which point they assign you a new IP address that usually bears no similarity whatsoever to your old address (not even the first octet is the same). Nice folks that they are, they give you no warning whatsoever when they are about to do this, and the only way you know is because your Internet connectivity suddenly dies until you try rebooting the cable modem, at which point you come up with this completely new IP address.

    Now imagine one of your users is using this company for their ISP, and you get over-confident because they've had that same IP address for the past six months or even the past year, and assume it will never change, and decide to only accept calls for their extension from that single IP address. Then later, maybe much later, the cable company starts moving things around and suddenly that extension can no longer connect, and you forget all about the fact that you're only allowing connections from their old IP address, so you spend hours trying to troubleshoot the problem. Not good.

    I'm aware that some ISP's do operate as you have described, and assign a new IP address at each reboot, but there are others that apparently associate an IP with a particular MAC address (until they decide to change it) and in that case no amount of rebooting will make a difference.
     

Share This Page