Are these Brute Force Attempts

[simonc]

We keep on getting messages like these. I am not sure if its a hack attempt or internal system trying to connect

[2012-07-12 10:11:39] NOTICE[3202]: chan_sip.c:16565 handle_request_subscribe: Sending fake auth rejection for user <sip:311@OURIPADDRESS;transport=UDP>;tag=e374f411
[2012-07-12 10:11:39] NOTICE[3202]: chan_sip.c:16565 handle_request_subscribe: Sending fake auth rejection for user <sip:311@OURIPADDRESS;transport=UDP>;tag=e374f411
[2012-07-12 10:11:39] NOTICE[3202]: chan_sip.c:16565 handle_request_subscribe: Sending fake auth rejection for user <sip:311@OURIPADDRESS;transport=UDP>;tag=e374f411

[mcargile]

This could be, or it could be a misconfigured phone. If you are seeing hundreds of these scrolling by in the console, it is a brute force attack, and you should try and figure out the IP and block it.

[williamconley]

Check the IP of the "incident". If it is a user/office in your system, then they likely misconfigured a phone. Be happy you don't have fail2ban running. LOL

If the IP does not belong to someone you know, use iptables to block all traffice TO AND FROM that IP. Then look at setting up a "whitelist" solution before evening. Trust me when I say another IP will be attacking soon. If you are open for "testing passwords", the attacks will increase until you cannot use your server reliably several times per day.

Also of note: Once that level is reached, the whitelist solution will not "permanently, immediately fix" your problem, as these script puppies will hammer at the outside of your firewall for several days after setting up the whitelist. At that point you will likely need to change your IP address or wait a few days with on/off reliability until they give up and go home. And that's even with ping turned off. Many of these scripts are purely automated and will continue to attack even after you no longer exist. One they realize that you are allowing them to guess at passwords.

Their goal: access your asterisk platform, generate thousands of calls (general cost = $2000 per hour, historically).

[simonc]

how can we check the Incident IP address if they are happening only 3 At a time, and fromw hat i can see and copy pasted, there is no IP log, only a tag.

[williamconley]

/var/log/asterisk has log files with many possibilities depending on your setup.

The /etc/asterisk/logger.conf file controls what level of logging goes in which file.

Code: Select all

asterisk -rx "logger rotate"

will "activate" any new settings placed in logger.conf.

[striker]

For these kind of attack you wont get the ip of the hacker in the logs (fail2ban also wont work for these attacks) . you have to trace the ip using the iftop

also check the below settings in your sip.conf
alwaysauthreject = yes
allowguest=no

tracing the ip of the attacker using iftop
run the below command in the linux console
iftop -i eth0 -f "dst port 5060" ; " this show the ip interfacing the port 5060" or use iftop -P or iftop -i etho check google for iftop man page

/sbin/iptables -I INPUT -s ipaddressofthehacker -j DROP
service iptables save

foreg: /sbin/iptables -I INPUT -s XXX.XXX.XXX.XXX -j DROP ; where is the XXX.XXX.XXX.XXX is the hacker ip traced in the iftop command

[williamconley]

we usually do get the ip address of the attacker in our logs. sip registration fail attempts store the ip, ssh login attempts also log the ip.

[simonc]

I was reviewing the logs and found this :

[2012-06-30 22:38:30] NOTICE[3235] chan_sip.c: Registration from '<sip:cd201@208.66.68.18;transport=UDP>' failed for '65.94.76.188' - Device does not match ACL
[2012-06-30 22:38:30] NOTICE[3235] chan_sip.c: Registration from '<sip:cd201@208.66.68.18;transport=UDP>' failed for '65.94.76.188' - Device does not match ACL


Does that means taht they found the pasword for this specific user but got refused because i setup an ACL for it or was it refused because of non matching acl before the IP

By the way, those options are alredy set on my sip.conf : alwaysauthreject = yes
allowguest=no

[williamconley]

ACL mismatch does not allow password attempts. Fails before checking (ie: disqualified, refused to check).

[simonc]

we usually do get the ip address of the attacker in our logs. sip registration fail attempts store the ip, ssh login attempts also log the ip.

yes we do as well without a problema and also have fail2ban working and banning ip addresses on a daily basis!

Issue is that someone is trying to attack the system in an unconvential way for asterisk and it gives a tag instead of the Ip address.

handle_request_subscribe: Sending fake auth rejection for user <sip:311@OURIPADDRESS;transport=UDP>;tag=e374f411

[okli]

We got around this SIP attacks by changing the SIP signalling port to a random one in the higher range, in addition to the Fail2Ban and few other protections via IP tables.
Softphones use that new port and in IP tables created simple port forwarding rule to forward that port, only from our provider's IPs, to the internal address.
Fail2Ban attack reports dropped from 10-15 per day to 0, for the past 12 months.