Difference between revisions of "Talk:Asterisk"

From Fail2ban
Jump to: navigation, search
(report bugs, + 1.8 syslog format fixed in 0.9)
 
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Education ==
+
'''IMPORTANT'''
  
When you are in need of a custom term paper, essay, [http://www.bestdissertation.com custom papers], research paper , dissertation or any other writing services, just remember that we have the professional essay writing help you need at a price you can afford.
+
If you have log samples that don't work:
 +
a) Test it with the latest filter ( https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/asterisk.conf )
 +
b) [https://github.com/fail2ban/fail2ban/issues Report an issue] with the log samples that don't work.
 +
 
 +
 
 +
 
 +
 
 +
I have the following asterisk failures in syslog (not /var/log/asterisk/messages)...
 +
 
 +
Sep 30 19:53:49 hostname asterisk[30888]: NOTICE[30924]: chan_sip.c:18390 in handle_request_register: Registration from '"123"<sip:123@phone.example.net>' failed for '192.0.2.1' - Wrong password
 +
 
 +
Sep 30 19:57:43 hostname asterisk[30888]: NOTICE[30924]: chan_sip.c:18390 in handle_request_register: Registration from '"123"<sip:321@phone.example.net>' failed for '192.0.2.1' - No matching peer found
 +
 
 +
Sep 30 19:59:03 hostname asterisk[30888]: NOTICE[30924]: chan_sip.c:18390 in handle_request_register: Registration from '"123"<sip:123@phone.example.net>' failed for '192.0.2.1' - Username/auth name mismatch
 +
 
 +
 
 +
The filter I am using (which appears to work for all the above log entries) is as follows...
 +
 
 +
failregex = NOTICE[[][0-9]*]: chan_sip.c:.* Registration from .* failed for [']<HOST>['].*$
 +
 
 +
 
 +
You should change logger time format in /etc/asterisk/logger.conf
 +
[general]
 +
dateformat=%F %T
 +
 
 +
For full information check http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk
 +
 
 +
== New REGEX for Asterisk 1.8 ==
 +
 
 +
(Fixed for Fail2ban 0.9)
 +
 
 +
Asterisk 1.8 includes the port number in the log entry so it broke the existing regex for detecting the host IP.<br><br>
 +
 
 +
Here is a sample of the new logs for a bad password login attempt<br>
 +
<code>
 +
Nov  4 18:30:40 localhost asterisk[32229]: NOTICE[32257]: chan_sip.c:23417 in handle_request_register: Registration from 'XXXXXXXXXXXXXXXXX' failed for '192.168.200.100:36998' - Wrong password<br>
 +
</code>
 +
 
 +
Notice the port is listed with the offending IP separated by a colon.<br><br>
 +
 
 +
Here are new regex's that work by not including the colon port number in the <HOST> variable that gets passed to iptables. Edit your asterisk filter in the /etc/fail2ban/filters.d/ directory accordingly.
 +
 
 +
<code>
 +
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Wrong password<br>
 +
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - No matching peer found<br>
 +
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Username/auth name mismatch<br>
 +
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Device does not match ACL<br>
 +
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Peer is not supposed to register
 +
</code>
 +
 
 +
== Asterisk + Fail2ban  ==
 +
 
 +
Fail2ban can not be used w/Asterisk simply because Asterisk does not log enough info for fail2ban to take action. More info: http://forums.asterisk.org/viewtopic.php?p=159984
 +
There should be a big disclaimer warning users about this issue.

Latest revision as of 01:38, 14 March 2014

IMPORTANT

If you have log samples that don't work: a) Test it with the latest filter ( https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/asterisk.conf ) b) Report an issue with the log samples that don't work.



I have the following asterisk failures in syslog (not /var/log/asterisk/messages)...

Sep 30 19:53:49 hostname asterisk[30888]: NOTICE[30924]: chan_sip.c:18390 in handle_request_register: Registration from '"123"<sip:123@phone.example.net>' failed for '192.0.2.1' - Wrong password

Sep 30 19:57:43 hostname asterisk[30888]: NOTICE[30924]: chan_sip.c:18390 in handle_request_register: Registration from '"123"<sip:321@phone.example.net>' failed for '192.0.2.1' - No matching peer found

Sep 30 19:59:03 hostname asterisk[30888]: NOTICE[30924]: chan_sip.c:18390 in handle_request_register: Registration from '"123"<sip:123@phone.example.net>' failed for '192.0.2.1' - Username/auth name mismatch


The filter I am using (which appears to work for all the above log entries) is as follows...

failregex = NOTICE[[][0-9]*]: chan_sip.c:.* Registration from .* failed for [']<HOST>['].*$


You should change logger time format in /etc/asterisk/logger.conf

[general]
dateformat=%F %T

For full information check http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk

New REGEX for Asterisk 1.8

(Fixed for Fail2ban 0.9)

Asterisk 1.8 includes the port number in the log entry so it broke the existing regex for detecting the host IP.

Here is a sample of the new logs for a bad password login attempt
Nov 4 18:30:40 localhost asterisk[32229]: NOTICE[32257]: chan_sip.c:23417 in handle_request_register: Registration from 'XXXXXXXXXXXXXXXXX' failed for '192.168.200.100:36998' - Wrong password

Notice the port is listed with the offending IP separated by a colon.

Here are new regex's that work by not including the colon port number in the <HOST> variable that gets passed to iptables. Edit your asterisk filter in the /etc/fail2ban/filters.d/ directory accordingly.

Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Wrong password
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - No matching peer found
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Username/auth name mismatch
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Device does not match ACL
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Peer is not supposed to register

Asterisk + Fail2ban

Fail2ban can not be used w/Asterisk simply because Asterisk does not log enough info for fail2ban to take action. More info: http://forums.asterisk.org/viewtopic.php?p=159984 There should be a big disclaimer warning users about this issue.