Can’t Block Intrusion

Home » Asterisk Users » Can’t Block Intrusion
Asterisk Users 11 Comments

I am running Asterisk 16.9 on FreeBSD 12.1-RELEASE-p1. I keep seeing lines like this in my logs.

[Apr 1 13:30:33] NOTICE[101155][C-00004526] chan_sip.c: Call from ”
(45.143.220.235:5356) to extension ‘2037’ rejected because extension not found in context ‘unauthenticated’.

I have a script that checks for things like this and adds them to my packet filter (pf). Everything seems to work up to a point. The IP
address gets added to my AUTOBLOCK table. The second rule, right after the friends whitelist, blocks any IP in that table. If I try to ping or traceroute to it I can’t get through. I ran netstat -a and sockstat -c and the IP address does not show up in the connections. Every test suggests that the system is doing exactly what I want it to do.

The weird thing is that the attempts don’t stop. That IP continues to try different numbers. There are two ways that I have found so far to actually stop the attack. One is to completely stop Asterisk and then restart it. Obviously not a good option on a production switch.

The other way is to null route the IP. That stops it cold. That’s better but it needs me to manually intervene. However, it does make it clear that the IP address is not being faked somehow.

I also tried doing “pfctl -k 45.143.220.235” but that says that no connections were dropped. It looks like pf is convinced that the connection is gone.

So, can anyone suggest why the attack keeps happening?

—
D’Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation – Propelling Business Forward http://www.VybeNetworks.com/
IM:darcy@VybeNetworks.com VoIP: sip:darcy@VybeNetworks.com

—

11 thoughts on - Can’t Block Intrusion

  • D’Arcy Cain writes:

    But yet, new packets from that IP address reach asterisk. It seems almost entirely clear to me that you have a firewall problem, not an asterisk problem.

    I would test this out with a remote machine under your control, and packet trace. I would check for a buggy firewall rule that is somehow accepting packets from new tcp or udp packets as matching an old connection state object. I would check for the new attempts as coming from something that matches the original “connection”, even if UDP.

    You say “continues to try”, but surely you are not surprised that packets arrive at your computer. I think you are surprised that they make it to asterisk. But your language doesn’t quite line up with that. Am I misinterpreting?

    —

  • This could well be but Asterisk is the only thing that continues to communicate.

    Here is the first four lines from “pfctl -sr”:

    pass in quick on bge0 from to any flags S/SA keep state block drop in log quick on bge0 from to any block drop in log quick on bge0 from to any block drop out log quick on bge0 from any to

    Unless pf is broken I can’t see how anything besides my “friends” can be getting through.

    Maybe. By “try” I don’t mean “try to get through”. I mean “try to access my switch”. They aren’t actually breaking in. My passwords are strong enough to frustrate them.

    —
    D’Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation – Propelling Business Forward http://www.VybeNetworks.com/
    IM:darcy@VybeNetworks.com VoIP: sip:darcy@VybeNetworks.com

    —

  • D’Arcy Cain writes:

    agreed that I can’t see it.

    Yes, but the fact that the sender is sending packets is no surprise. The issue is about how those are handled. I think you need to use tcpdump and turn up firewall debugging.

    —

  • Or the stateful entry still exists when the table entry is updated.

    Does your script also issue a command to kill existing states from that host after it has updated the table, e.g.  pfctl -k 45.143.220.235

    Larry.

  • block drop in log quick on bge0 from to any block drop out log quick on bge0 from any to

    Am I misunderstanding pf? I thought that that would block TCP, UDP, ICMP and anything else trying to get through.

    Since I started looking at this closer I did find that only some connections have this problem. Most get blocked as soon as the IP is passed to the AUTOBLOCK table.

    —
    D’Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation – Propelling Business Forward http://www.VybeNetworks.com/
    IM:darcy@VybeNetworks.com VoIP: sip:darcy@VybeNetworks.com

    —

  • Hmm, missed that in your original post. Could ‘pfctl -K’ be of help, I
    would suggest either removing ‘quick’ from your ‘pass’ rule or placing that line after the ‘block’ rules.

    Larry.

  • Yes, as I said in my OP that’s the actual command that I used.

    —
    D’Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation – Propelling Business Forward http://www.VybeNetworks.com/
    IM:darcy@VybeNetworks.com VoIP: sip:darcy@VybeNetworks.com

    —

  • I suspect you have a good understanding of pf.

    Have you included in your script running ‘pfctl -k ‘ to kill any states that may exists after you update your table?

    In pf, like IP Filter, the last matching rule wins.

    What can’t be determined from the information provided is whether any connections that have been established from networks you have listed in the table , also appear in the table.

    Removing the ‘quick’ parameter from the rule for will allow packets to fall through to the next rules. Alternatively, moving the
    ‘pass’ rule to below your ‘block’ rules will allow any connections originating from networks listed in your     table and also exists in the table, will be blocked.

    Larry.

    —

  • Pretty good I think. As with everything I am always willing to learn more.

    I haven’t yet because I want to watch the effect of doing it. When I
    see the problem happening I run that manually and watch to see if it stops the attack in its tracks or if I still have to null-route it. Once I know that it is working I will add it to the script.

    Subject to the “quick” keyword of course.

    Absolutely positive. FRIENDS is a static table with exactly eight entries. It is mainly for protection against our office and a few special hosts such as our VoIP provider being locked out. I can guarantee that the IP that I showed in the OP was not a friend.

    It’s a safety thing. Even if someone in the office makes a mistake I
    don’t want them blocked. Same for other friends.

    I haven’t seen the issue today. One thing that I did was to move the anti spoof line further up. I thought that anti-spoof would block wherever it was. Could the location be important?

    —
    D’Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation – Propelling Business Forward http://www.VybeNetworks.com/
    IM:darcy@VybeNetworks.com VoIP: sip:darcy@VybeNetworks.com

    —

  • Didn’t matter. It happened again.

    I did do something though. I added a bunch of netblocks to my ENEMIES
    table. In case anyone wants to use them here they are:

    45.143.220.0/24 # 1,547,018 attempts
    77.247.109.0/24 # 629,717 attempts
    185.53.88.0/24 # 302,581 attempts
    88.80.148.0/24 # 89,271 attempts
    185.36.81.0/24 # 78,886 attempts
    37.49.230.0/24 # 69,700 attempts
    116.202.203.0/24 # 39,838 attempts
    185.4.224.0/24 # 30,I845 attempts
    103.145.12.0/24 # 26,746 attempts
    103.145.13.0/24 # 19,203 attempts

    Note that the comments are stripped from the actual file used by pf.

    The attempts are over a period of just under two weeks. As you can see, the worst offender was the block that included the IP that I showed in my OP.

    —
    D’Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation – Propelling Business Forward http://www.VybeNetworks.com/
    IM:darcy@VybeNetworks.com VoIP: sip:darcy@VybeNetworks.com

    —