[asterisk-users] SIP invite timeouts : how is someone sending invites from our server ??

[Tim S]

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

On Tue, Jan 2, 2018 at 2:30 PM, sean darcy <seandarcy2 at gmail.com> wrote:
>
> 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
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>      https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20180103/5242de7f/attachment.html>