7 thoughts on - SIP Invite Timeouts : How Is Someone Sending Invites From Our Server ??

• What’s your setting for “allowguest” (under [general]) in
  /etc/asterisk/sip.conf ?

  What are your firewall rules for UDP 5060?

  Antony.

• Script kiddies trying to find vulnerable systems that they can make calls on. Lock down the box with iptables and use fail2ban to block them. The via is probably bogus unless a box at the DoD was comprimised.

• allowguest=no alwaysauthreject = yes

  The only firewall rules for UDP 5060 forward the packets to asterisk.

  sean

• I don’t see how fail2ban would help. asterisk isn’t rejecting anything. There’s no attempt with username/password.

  How could I use iptables to “lock it down” ? We get sip calls from all over. Is there something about the incoming packet we could use ? For instance , any packet containing a VIA instruction ? For that matter, can SIP be configured to drop any VIA request?

  sean

  —

• fail2ban is most useful for blocking registration attempts.    I handle non-registration call attempts by allowing guests, point them to a jail context, which runs Log(WARNING,fail2ban=’${CHANNEL(peerip)}’)   I set a fail2ban rule to match that line logged from Asterisk.

  —

• IMHO, manual IP-tables is probably better for those who have a single provider – whitelist only your SIP trunk provider’s IP adress (or address pool). But… that leads onto a train of thought that might help.

  First, realize you don’t have to manually read your security logs, you can script that – and scripts can do things based on the data you are seeing. But let’s start with a topology based on the “Divide and Conquer” principal for a clean ideal SIP internet connection:

  – If you have an SIP trunking provider and you want to lock down access
  between it and Asterisk – get a separate IP address, and whitelist the
  access to it.
  – Put your public SIP entry-point on a separate IP address, and pop out
  a DNS entry for *sip.**domain.root* and get cracking with the rules that
  limit privileges for that public “anyone” class of user. Limit the SIP
  public portal IP to only handle VoIP (SIP), this is where fail2ban can be
  helpful.
  – Look for ANY attempts to sniff the SIP only IP address for any
  other ports/protocols – and block them for 2 days (limited time as some
  addresses are DHCP and will move around).
  – Asterisk does decent logging, so use that to your benefit. As user
  account credential failures come out, you’re going to be generating logs to
  that effect. Sniff those logs and when you start seeing failures, trigger
  a script to limit your rate at the firewall from that port. After a few
  failures you can block that IP for 5 minutes, and send and email to your
  admin for them to take a look. For script kiddies that should be enough to
  send the message, but not enough to kill off actual customers. You don’t
  want to even try to permanently block IPs, especially if you’re a business.
  – Now think about your dialplan – you give someone a number to dial
  into right? (i.e. incoming*@sip.domain.root*) So… take a look at
  the incoming requested extension. An incoming call from the public user
  should go to a controlled context, if the incoming caller asked for the
  right target, well then you pipe them to your incoming context – if any
  other extension was dialed, log it… use that log data, trigger a filter,
  send your admin an email, start working it…
  – Outgoing calls NOT going to a SIP trunking provider? Either:
  1. Run it through your incoming sip.domain.root IP address (separate
  from your trunk provider IP), or…
  2. (Better) run it through a separate IP address that only does
  outgoing SIP calls (so, three IPs for VoIP: 1) SIP-trunk, 2)
  SIP-incoming,
  and 3) SIP-outgoing).
  – Now use fail2ban and IP-tables to start punishing kiddies for trying
  to set up a session on your outgoing-only IP address. Logic behind it: if
  they were calling your incoming address and not mucking with packets or
  just sniffing, they wouldn’t be here…
  – Unless, that is, they called back a number that called them. So
  you put a simple dial plan in place that plays a message about what number
  to actually call back for regular service (maybe take a message?), log it,
  notify the admin – yadda, yadda, yadda… Don’t reward people for dialing
  your outgoing number, control your lines of communication on your terms. 😉

  Any other stuff you see in logs outside normal call flow (any rule violation in Asterisk that generates a security log entry), log it, trigger a fail2ban block with a script, but do this for a week or more. The security logging in Asterisk is very useful, but it’ll be up to you to figure out how you want to integrate the log entries generated into actionable information, and what actions you want to perform. Personally I
  like to consolidate all my logs using a tool like Rsyslog or Graylog
  (pub-subs are good for this type of logic and archiving), so that I can get a bigger picture look at what’s happening on my network. The firewall and your Asterisk have to kind of work together to create an environment that is conducive to good business, while keeping the bad guys out.

  An analogy: think of it like the firewall is the police, and Asterisk or really anything behind the firewall are the citizens. If none of the citizens calls the police to tell them they don’t like something, the police never do anything to fix it. Fail2ban and the scripted rules based on logging data are the city ordinances to be enforced with slaps on the wrist and fines, and the firewall rules are the basic “ten commandments”
  laws (if you will) the firewall can enforce if it sees someone breaking them, by sending them to jail or deporting them.

  Keep your logs, rotate them, back them up. If someone from DoD or more likely the FBI gets in touch with you or your ISP asking why you’re probing a government phone system, that’s probably when you’re going to want to have your logs available, and be able to demonstrate you’ve taken steps to mitigate your exposure. Be aware it’s not *JUST* you, it’s the whole internet getting probed for this stuff (and your IP address is guaranteed to be a valid output of some random number generator), and that means the government too. They have systems in place to handle those attackers who are shall we say “serious”.

  Hopefully this was useful.

  Best Regards,

  -Tim

• Thanks for the suggestion. Works great! 🙂