<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello,<br>
    </p>
    <div class="moz-cite-prefix">On 27.07.20 11:32, Mark Boyce wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:72A2E5F6-86B0-4E2C-B512-4C2F0D06F6FA@darkorigins.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div class=""><br class="">
      </div>
      Hi
      <div class=""><br class="">
      </div>
      <div class="">Sounds very similar to the way I’ve been heading,
        working on multi layer defence like this;</div>
      <div class=""><br class="">
      </div>
      <div class="">1) Already Blacklisted -> drop</div>
      <div class=""><br class="">
      </div>
      <div class="">2) Very naughty things we should never see (SQL
        injection/scanner) -> Add to permanent blacklist & drop</div>
    </blockquote>
    <p><br>
    </p>
    <p>This make sense as well. Probably we should extend sanity module
      for doing such checks over the relevant parts of the message
      (R-URI, From/To headers, Call-ID).<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:72A2E5F6-86B0-4E2C-B512-4C2F0D06F6FA@darkorigins.com">
      <div class=""><br class="">
      </div>
      <div class="">3) Rate Limiting . Using temp blacklist, banning for
        x mins.</div>
      <div class=""><br class="">
      </div>
      <div class="">4) If not an “Invite/Register” and IP not on list of
        IPs we have seen auth previously, drop. (Gets rid of all the
        Option/Subscribe scanners)</div>
      <div class=""><br class="">
      </div>
      <div class="">5) “Not for us” user/domain check -> drop.
         (good, as it ignores all those invites from <a
          href="mailto:100@1.1.1.1" class="" moz-do-not-send="true">100@1.1.1.1</a>.
        Bad, as it means a badly configured UA trying to talk to us on
        IP domain doesn’t get an Auth challenge)</div>
      <div class=""><br class="">
      </div>
      <div class="">6) Normal Challenge Auth, with failure rate limit</div>
      <div class=""><br class="">
      </div>
      <div class="">(Using details retrieved as part of Auth)</div>
      <div class=""><br class="">
      </div>
      <div class="">7) If not in $au:$ip:$ua.. cache Check IP / GeoIP
        Countries / Device UA / etc. Caching result</div>
      <div class=""><br class="">
      </div>
      <div class="">8) Check if endpoint / user / etc is disabled (means
        disabling a single endpoint doesn’t end up banning entire IP for
        Auth failures)</div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class="">Most of which is coded by hand inside cfg file at
        the moment.  Couldn’t quite get security module etc to work
        quiet how I wanted the logic to work.</div>
    </blockquote>
    <p>that's not easy indeed -- every time I think I should wrap all
      the conditions I have in a recent config into a "security" module
      (for the sake of easing provisioning), a different pattern pops up
      that I have to cover or there is a new deployment with different
      call scenarios/end points behaviour that is reusing only a few
      from the previous config.</p>
    <p>Making such a module with very flexible policies stored in
      database will be very complex, hard to define the format of the
      rules, which can end up being harder to manage than just combining
      modules and conditions in configuration file.</p>
    <p>Cheers,<br>
      Daniel<br>
    </p>
    <blockquote type="cite"
      cite="mid:72A2E5F6-86B0-4E2C-B512-4C2F0D06F6FA@darkorigins.com">
      <div class=""><br class="">
      </div>
      <div class="">Cheers</div>
      <div class="">Mark</div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
        <div><br class="">
          <blockquote type="cite" class="">
            <div class="">On 27 Jul 2020, at 10:08, Daniel-Constantin
              Mierla <<a href="mailto:miconda@gmail.com" class=""
                moz-do-not-send="true">miconda@gmail.com</a>> wrote:</div>
            <br class="Apple-interchange-newline">
            <div class="">
              <meta http-equiv="Content-Type" content="text/html;
                charset=UTF-8" class="">
              <div class="">
                <p class="">Hello,</p>
                <p class="">what worked quite well so far for me was
                  maintaining ipban and ipallow htables, adding to
                  ipallow the address of a successfully authenticated
                  request and adding to ipban the address of a flooding
                  end point (detected via pike or pipelimit) which is
                  not in ipallow.</p>
                <p class="">Of course, skipping trusted fixed ip end
                  points (e.g., pstn gateways).<br class="">
                </p>
                <p class="">Most of the end points send the REGISTER and
                  once authenticated and gets back 200ok, then they
                  flood with SUBSCRIBE for BLF/MWI/Presence, but at that
                  moment, the IP is in ipallow. I also maintain an
                  userban htable where to keep username:ip if that user
                  failed to authenticate 5 times in a row.<br class="">
                </p>
                <p class="">Anyhow, adding more layers of trusting
                  levels is better.</p>
                <p class="">Cheers,<br class="">
                  Daniel<br class="">
                </p>
                <div class="moz-cite-prefix">On 27.07.20 10:45, Mark
                  Boyce wrote:<br class="">
                </div>
                <blockquote type="cite"
                  cite="mid:DA1FDE75-0065-46E9-AFDA-BB33DE660096@darkorigins.com"
                  class="">
                  <meta http-equiv="Content-Type" content="text/html;
                    charset=UTF-8" class="">
                  Hi
                  <div class=""><br class="">
                  </div>
                  <div class="">I only have ubuntu to hand.  The latest
                    v20.04 still seems to include a country db version,
                    although it’s from Dec 2019.</div>
                  <div class=""><br class="">
                  </div>
                  <div class="">Completely agree on security, and still
                    wondering how much admin overhead maintaining it is.</div>
                  <div class=""><br class="">
                  </div>
                  <div class="">At the moment I’m thinking of layering
                    it like this;</div>
                  <div class=""><br class="">
                  </div>
                  <div class="">- Fixed IP</div>
                  <div class="">- Dynamic IP but Fixed ISP (AS)</div>
                  <div class="">- Mobile but Fixed/Limited Country<br
                      class="">
                    <div class="">- Mobile no restrictions</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">Also playing with matching User-Agent
                      from headers against a list of RegEx’s to verify
                      that the endpoint is the make/model expected.  </div>
                    <div class=""><br class="">
                    </div>
                    <div class=""><br class="">
                    </div>
                    <div class="">GeoIP Module - Great.  I’ll have a
                      look at module source and try to document what’s
                      involved.</div>
                    <div class=""><br class="">
                    </div>
                    <div class=""><br class="">
                    </div>
                    <div class="">Cheers</div>
                    <div class="">Mark</div>
                    <div class=""><br class="">
                      <blockquote type="cite" class="">
                        <div class="">On 27 Jul 2020, at 09:14,
                          Daniel-Constantin Mierla <<a
                            href="mailto:miconda@gmail.com" class=""
                            moz-do-not-send="true">miconda@gmail.com</a>>
                          wrote:</div>
                        <br class="Apple-interchange-newline">
                        <div class="">
                          <div class="">Hello,<br class="">
                            <br class="">
                            indeed, I noticed a while ago MaxMind
                            requires registration to fetch the<br
                              class="">
                            latest database, from that point I was still
                            using a local copy of an<br class="">
                            older version for testing. Are the major
                            Linux distros still shipping it?<br class="">
                            <br class="">
                            I can add lookup of AS to the module -- it
                            would be appreciated and<br class="">
                            speed up things if you can give some
                            references/links to the API/library<br
                              class="">
                            docs for it.<br class="">
                            <br class="">
                            As for how much security it can bring, as
                            always, it depends. If you<br class="">
                            have only fixed lines customers, then it can
                            be an extra check. But if<br class="">
                            the people can use mobile apps, they can go
                            in parks, or public places<br class="">
                            and use mobile carriers or public wifi
                            networks. Also, I encountered<br class="">
                            situations when people do vpn from their
                            mobile and show up as coming<br class="">
                            from another country, a matter where the vpn
                            server is located.<br class="">
                            <br class="">
                            In general, the more restrictions you can
                            set for end point locations,<br class="">
                            the better. Still, they can be compromised
                            even if they are inside a<br class="">
                            known isp network...<br class="">
                            <br class="">
                            Cheers,<br class="">
                            Daniel<br class="">
                            <br class="">
                            On 23.07.20 12:18, Mark Boyce wrote:<br
                              class="">
                            <blockquote type="cite" class="">Hi all<br
                                class="">
                              <br class="">
                              Just looking at the latest GeoIP2 MaxMind
                              databases (now requires registration, but
                              still free) and noticed that they also
                              include the AS (ISP) lookup one in the
                              free offering.<br class="">
                              <br class="">
                              Wondering if this is another way to
                              facilitate better security for users on
                              dynamic IP. Typically working from home
                              these days.<br class="">
                              <br class="">
                              So, rather than just limiting an end
                              device to a country we could limit it to a
                              particular ISP within that country.<br
                                class="">
                              <br class="">
                              Has anyone tried this? Have I missed a
                              reason why this wouldn’t help?  Admin
                              overhead not worth it?<br class="">
                              <br class="">
                              Thoughts?<br class="">
                              <br class="">
                              Best regards<br class="">
                              Mark<br class="">
                              -- <br class="">
                              Mark Boyce<br class="">
                              Dark Origins Ltd<br class="">
                              <br class="">
_______________________________________________<br class="">
                              Kamailio (SER) - Users Mailing List<br
                                class="">
                              <a
                                href="mailto:sr-users@lists.kamailio.org"
                                class="" moz-do-not-send="true">sr-users@lists.kamailio.org</a><br
                                class="">
                              <a class="moz-txt-link-freetext"
                                href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users"
                                moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br
                                class="">
                            </blockquote>
                            <br class="">
                            -- <br class="">
                            Daniel-Constantin Mierla -- <a
                              href="http://www.asipto.com/" class=""
                              moz-do-not-send="true">www.asipto.com</a><br
                              class="">
                            <a href="http://www.twitter.com/miconda"
                              class="" moz-do-not-send="true">www.twitter.com/miconda</a>
                            -- <a
                              href="http://www.linkedin.com/in/miconda"
                              class="" moz-do-not-send="true">www.linkedin.com/in/miconda</a><br
                              class="">
                            Funding: <a
                              href="https://www.paypal.me/dcmierla"
                              class="" moz-do-not-send="true">https://www.paypal.me/dcmierla</a><br
                              class="">
                            <br class="">
                          </div>
                        </div>
                      </blockquote>
                    </div>
                    <br class="">
                    <div class="">
                      <div style="letter-spacing: normal; text-align:
                        start; text-indent: 0px; text-transform: none;
                        white-space: normal; word-spacing: 0px;
                        -webkit-text-stroke-width: 0px; word-wrap:
                        break-word; -webkit-nbsp-mode: space;
                        line-break: after-white-space;" class="">
                        <div style="orphans: 2; widows: 2;" class=""><br
                            class="">
                        </div>
                        <div style="orphans: 2; widows: 2;" class="">-- </div>
                        <div style="orphans: 2; widows: 2;" class="">Mark
                          Boyce</div>
                        <div style="orphans: 2; widows: 2;" class="">Dark
                          Origins Ltd</div>
                        <div style="orphans: 2; widows: 2;" class="">e: <a
                            href="mailto:mark@darkorigins.com" class=""
                            moz-do-not-send="true">mark@darkorigins.com</a></div>
                      </div>
                    </div>
                    <br class="">
                  </div>
                </blockquote>
                <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="http://www.asipto.com/" moz-do-not-send="true">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda" moz-do-not-send="true">www.linkedin.com/in/miconda</a>
Funding: <a class="moz-txt-link-freetext" href="https://www.paypal.me/dcmierla" moz-do-not-send="true">https://www.paypal.me/dcmierla</a></pre>
              </div>
            </div>
          </blockquote>
        </div>
        <div class=""><br class="">
          -- <br class="">
          Mark Boyce<br class="">
          Dark Origins Ltd<br class="">
          e: <a href="mailto:mark@darkorigins.com" class=""
            moz-do-not-send="true">mark@darkorigins.com</a><br class="">
        </div>
      </div>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Funding: <a class="moz-txt-link-freetext" href="https://www.paypal.me/dcmierla">https://www.paypal.me/dcmierla</a></pre>
  </body>
</html>