I have been getting thousands of junk calls into my system. Is there a way to identify the IP address of the call so I can block them in iptables?
Thanks
post an output of /var/log/asterisk/full filtered for a suspect call.
Thank you very much.
cat /var/log/asterisk/full | grep “WARNING” | grep “Ext. s:” | grep “Rejecting unknown SIP connection from”
This isolates them for me and then I have been blocking
iptables -I INPUT -s 108.61.0.0/16 -j DROP
Consider setting up fail2ban , the standard asterisk regexes catch such attacks.
I have fail2ban. Its not catching it. I get them one after the other all day.
Maybe your jail is not aggressive enough, are the IP’s in the fail2ban log as warnings?
You can check it’s “catches” with
fail2ban-regex (logfilename) (filterfilename)
Is this correct. I think SIP may not be what it is asking for.
fail2ban-regex /var/log/asterisk/full SIP
No not SIP , it is the name of the file that defines the filter that you have set up for the asterisk jail, possibly /etc/fail2ban/filter.d/asterisk.conf but that would depend
fail2ban-regex --help
In that file will be the regexes that are used to match the logfile in my case
failregex = ^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Registration from '[^']*' failed for '<HOST>(:\d+)?' - (Wrong password|Username/auth name mismatch|No matching peer found|Not a local domain|Device does not match ACL|Peer is not supposed to register|ACL error \(permit/deny\)|Not a local domain)$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Call from '[^']*' \(<HOST>:\d+\) to extension '\d+' rejected because extension not found in context 'default'\.$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Host <HOST> failed to authenticate as '[^']*'$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s No registration for peer '[^']*' \(from <HOST>\)$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Host <HOST> failed MD5 authentication for '[^']*' \([^)]+\)$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Failed to authenticate (user|device) [^@]+@<HOST>\S*$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s hacking attempt detected '<HOST>'$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s SecurityEvent="(FailedACL|InvalidAccountID|ChallengeResponseFailed|InvalidPassword)",EventTV="([\d-]+|%(iso8601)s)",Severity="[\w]+",Service="[\w]+",EventVersion="\d+",AccountID="(\d*|<unknown>)",SessionID=".+",LocalAddress="IPV[46]/(UDP|TCP|WS)/[\da-fA-F:.]+/\d+",RemoteAddress="IPV[46]/(UDP|TCP|WS)/<HOST>/\d+"(,Challenge="[\w/]+")?(,ReceivedChallenge="\w+")?(,Response="\w+",ExpectedResponse="\w*")?(,ReceivedHash="[\da-f]+")?(,ACLName="\w+")?$
^(%(__prefix_line)s|\[\]\s*WARNING%(__pid_re)s:?(?:\[C-[\da-f]*\])? )Ext\. s: "Rejecting unknown SIP connection from <HOST>"$This seems to be the rule grabbing the log file warning
^(%(__prefix_line)s|[]\sWARNING%(__pid_re)s:?(?:[C-[\da-f]])? )Ext. s: "Rejecting unknown SIP connection from "$
My fail2ban is completely stock from the distro. There are so many config files and rules, I have never tried to tinker with it. I presume this is supposed to put this type of warning in jail.
Sorry I dont use " the distro." But I can assure it works well when done right.
There was a note from @jfinstrom a month (maybe two) ago that talked about a “yum update” (?) that needed to be done to get some of these new failure messages into the fail2ban config.
You may also want to make sure your distro is up to date by runnig the update scripts found here: http://wiki.freepbx.org/display/PPS/Updating+FreePBX+Official+Distro
They update the FPBX modules, but also Asterisk, Dahdi. Linux and the rest.
I am up on the scripts. I also ran a yum update for a different reason (dropping calls because of the 13.8 asterisk queue bug). After that update, my iptables -L included several different categories, and it seemed to start catching some of those issues. Thanks everyone for all the help and suggestions!