|
I'm a DCAP (DIGIUM CERTIFIED ASTERISK PROFESSIONAL). I don't work with Asterisk any more, but I'm pretty good with it, if any one needs any Asterisk help please feel free to ask.
|
#
¿
Apr 30, 2015 19:54
|
|
|
|
| # ¿ Apr 16, 2024 08:06 |
|
|
Bohemian Cowabunga posted:I am a Lync 2013 server administrator How much do you drink per day?
|
|
#
¿
May 6, 2015 14:33
|
|
|
Bohemian Cowabunga posted:Dont mention the war One of my absolute favorite IT stories is from when I was in an airport shuttle from the airport in Seattle. A guy gets on the shuttle and stands next to me, he's wearing an OCS shirt. I ask him if he worked for Microsoft, and if he was a developer for Lync, he says he used to be, but when HP decided to use Lync MS just sort of gave him to them, so now all he does is manage HP's Lync installation, but he used to be a developer for the platform. He asked if I was a Lync admin, I mentioned that I was working on a big roll out with a customer now. He looked me in the eyes, and said "I'm really sorry, I really am." Then we both looked down at our feet in silence until the bus stop.
|
|
#
¿
May 6, 2015 14:54
|
|
|
Bohemian Cowabunga posted:Hahaha, yeah that says alot. Wanna simultaneously slap the guy and buy him a beer. My experience with Lync was really bad, since I had a customer, maybe 100 users, tell me they want to deploy Lync 2010. I had never done that before, but I told my boss (I was a consultant) and he said "good, just figure it out and charge them per hour." I asked if we could farm it out and I was told no. So I got a bunch of books on Lync, and spent a week reading them and setting up some VMs to learn it. The worst part was that I kept finding out you need to buy more things to get more functions. You need Lync, then a Lync Front End Server, then a TMG server, etc. It was bad because I kept having to tell my manager, and then the customer, that we needed to buy more licenses and servers (they refused to virtualize anything). They were getting increasingly upset at me (both my manager and the customer) since I was sinking so much time and money into it. But I knew nothing about it, so what else was I supposed to do? Finally I had it 90% working, except the mobile client, and I begged my manager to let me hire out and get a couple hours with someone that could help. He agreed, and eventually I got a guy to remote in and check it out. Turns out my SSL Cert was incorrect, fixed that, and it all worked fine. Then I got it working with Asterisk, which was also a nightmare. EDIT: My advice for anyone working with Asterisk and SIP: Learn to use Wireshark, and learn to read a SIP trace. Figure out how to do tcpdump on your server and just snatch a few minutes of calls and decode it. Get really familiar with what a good SIP session looks like. And then do weird things, like hang up one end, while leaving the other end up, be silent on a call for a minute, dropping a call from the console, unplugging a phone in the middle of a call, etc, and see what it does. My biggest problem in the world of Asterisk is providers that don't know how to troubleshoot their SIP trunks, because their people don't get what SIP packets look like and should do. If I have calls drop after a minute, and I clearly see your server send me a GOODBYE, then clearly something is odd on your end. When users complain about "calls sounding bad", which they will, learn to calmly and politely ask them to explain specifically what happened. Echo? Feedback? Static? Did you both hear it, or just one side? Was the all inbound/outbound? What DID specifically did the caller dial to get in, what did you dial out? For users that were really problematic, but I couldn't figure out what the problem was, I would get them a little notebook and leave it next to their phone and ask them to write down as soon as there was a problem, all the details, so I could get a really good handle on it. Next is to learn how to handle carriers. I was forever calling Broadview or Paetec about a PRI having issues, and they'd say "oh, it looks fine from here." So I'd unplug the cable from the smart jack or power off the IAD and say "does it look good now?" and if they said "sure, I don't see any change," I'd immediately ask for their manager since there's no way you are doing anything. This guaranteed me results. Also keep detailed call records of problem calls, since most carriers can only access the last 24 hours of call records to see what happened. If we are in a anecdote mood, I have several stories about crazy clients with VOIP problems making me want to kill myself. One that comes to mind is after a roll out of Aastra 57i's to a client, a guy called in complaining his phone wouldn't stop ringing. He had called on his cell phone so I could hear it. Sure enough his phone is just ringing over and over. But the volume is modulating, quiet, loud, quiet, loud. He's furious. I'm stumped, but I ask him "sorry, but this is a stupid question but are you just hitting the volume up and down keys over and over? And he says "YES THATS THE PROBLEM WHEN I HIT THEM THE PHONE RINGS" He's furious, so I tell him those are volume keys, so stop pressing them and it will stop ringing. He does, it gets quiet, and he's says "that's nonsense" and hangs up. Super-NintendoUser fucked around with this message at 15:31 on May 6, 2015 |
|
#
¿
May 6, 2015 15:07
|
|
|
One of the biggest insecurities of SIP is just a pretty simple brute force attack. Essentially, when a malicious SIP attack happens, the attacker first brute forces extension numbers, so he starts at 100, then 101, 102, etc. Most SIP servers will respond "invalid extension" for ones that don't exist, but then when they hit a valid extension, the SIP server responds "Ok, whats the password word?" Then they know they have a valid username, and can brute force the extension password. You can configure the server to respond "invalid extension" or not respond at all to an invalid extension, if they don't have the right password in the initial AUTH that way the attacker never gets through step 1 of brute forcing a valid username HOWEVER All this is mitigated if you install FAIL2BAN. If you don't have that on your Asterisk box DO IT NOW. This daemon will troll log files of everything, not just SIP, for failed authentications. You point it to a log file, tell it what the failures look like in the log, and then it will count the occurrences of that string, and if it hits a threshold, usually five or six, it'll automatically add a IPTables rule to block that IP Address. Go, install it now, I'll wait. The law is written in such a way that the end user, not the Telco that gives them the SIP service, is responsible for their security. So if someone hacks your box (which will be attempted) and makes a million international calls outbound, YOU are responsible for the charges. So secure your system.
|
|
#
¿
May 7, 2015 19:14
|
|
|
Bohemian Cowabunga posted:We are talking with a software house that might develop some application that you can call into and punch some numbers. Asterisk is what most people would use. I've configured a lot of asterisk systems people can call into and punch numbers. It can do pretty much anything you'd ever way. This is a double edged sword, since it does EVERYTHING, so it's hard to define exactly what you want.
|
|
#
¿
May 7, 2015 20:44
|
|
|
|
| # ¿ Apr 16, 2024 08:06 |
|
|
wolrah posted:edit: Also a lot of SIP servers support randomly auto-generating passwords that are usually long hex strings. If your platform can do this, use it. Fail2Ban might not get a chance to do its job if you have a common extension (as noted the scanners often start at 1000) and the password is weak. Alphanumeric "extensions" also help, but these are not commonly used since direct SIP calling has never caught on and they end up having to map to a number for most people to use anyways. Wait, so PASSWORD=extension isn't a good idea? What if the extension is a three digit number. That's 999 possible options. How can a computer possible hack that?
|
|
#
¿
May 7, 2015 20:51
|
|