<div dir="ltr">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.<div><br></div><div>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:<br><div><br></div><div><ul><li>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.</li><li>Put your public SIP entry-point on a separate IP address, and pop out a DNS entry for <i><b>sip.</b></i><b><i>domain.root</i></b> 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.</li><ul><li>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).</li><li>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.</li><li>Now think about your dialplan - you give someone a number to dial into right? (i.e. incoming<b><i>@sip.domain.root</i></b>)  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...</li></ul><li>Outgoing calls NOT going to a SIP trunking provider?  Either:</li><ol><li>Run it through your incoming sip.domain.root IP address (separate from your trunk provider IP), or...</li><li>(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).</li></ol><ul><li>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...</li><li>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. ;-)</li></ul></ul></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 <i>JUST</i> 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".<br><div class="gmail_extra"><br></div><div class="gmail_extra">Hopefully this was useful.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Best Regards,</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Tim</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 2, 2018 at 2:30 PM, sean darcy <span dir="ltr"><<a href="mailto:seandarcy2@gmail.com" target="_blank">seandarcy2@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don't see how fail2ban would help. asterisk isn't rejecting anything. There's no attempt with username/password.<br>
<br>
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?<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
sean<br>
<br>
<br>
<br>
-- <br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
Check out the new Asterisk community forum at: <a href="https://community.asterisk.org/" rel="noreferrer" target="_blank">https://community.asterisk.org<wbr>/</a><br>
<br>
New to Asterisk? Start here:<br>
     <a href="https://wiki.asterisk.org/wiki/display/AST/Getting+Started" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wik<wbr>i/display/AST/Getting+Started</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
  <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" rel="noreferrer" target="_blank">http://lists.digium.com/mailma<wbr>n/listinfo/asterisk-users</a></font></span></blockquote></div><br></div></div></div></div>