Hack attacks?

newboy

Joined
Mar 11, 2009
Messages
60
Likes
0
Points
0
#1
Hi,

I think i am getting hack attacks on my system. Se the information:

Date Source Destination Src. Channel Account Code Dst. Channel Status Duration
1/7/2010 1:22 sip s SIP/91.194.85.4-08caee20 ANSWERED 20
1/8/2010 22:34 sip s SIP/91.194.85.4-08ce64a0 ANSWERED 20
1/8/2010 22:37 sip s SIP/89.250.132.9-08ce64a0 ANSWERED 20
1/9/2010 1:19 sip s SIP/91.194.85.4-08ce90e0 ANSWERED 20
1/10/2010 6:04 asterisk s SIP/113.105.152.101-09d948c8 ANSWERED 36
1/10/2010 6:04 asterisk s SIP/113.105.152.101-09d8c1e8 ANSWERED 36

What do you think? Are these hack attacks? How can i prevent these?
 

danardf

Joined
Dec 3, 2007
Messages
8,069
Likes
10
Points
88
#2
It seems that an attack, yes.

Maybe you must set Allow Anonymous Inbound SIP Calls: no into general Freepbx parameters!?

How can i prevent these?
There's lots of posts with this question. That's should be easy to find an answer. ;)
I think at fail2ban, for example....etc. Yet that "Allow Anonymous Inbound SIP Calls: no" should be sufficient
You've also "permit/deny".
 

DaveD

Joined
Nov 12, 2007
Messages
597
Likes
0
Points
16
#3
Do yourself a favor and install fail2ban for starters
and you can also use the iptables to ban ip ranges your system will never use
For ranges lots of info here http://www.parkansky.com/china.htm
 

pucky900

Joined
Feb 9, 2009
Messages
51
Likes
0
Points
0
#4
I've been getting the same thing. Came into the office from the weekend and saw about 20 "sip" calls. I'm running Trixbox but I'm sure Elastix is not much different in fixing the problem. I could block the IP address at the firewall, but the addresses keep changing. Here is the discussion at Trixbox forums and how I (at least hopefully) fixed the problem.

http://www.trixbox.org/forums/trixbox-f ... urce-calls

I've also have begun to see stuff coming in as "asterisk" too.
 

pucky900

Joined
Feb 9, 2009
Messages
51
Likes
0
Points
0
#5
You don't want to block anonymous sip calls because you will get calls into your system with the caller blocking their DID/CID number/ID. At one time I thought of blocking them since Telemarketers will do that but began to see our customers calling in doing the same.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#6
Anonymous SIP calls are nothing to with CallerID, it is whether the call originated from a server to which you are not registered, unless your VSP sends to an IP instead of a registration or you use ENUM or such then you should not have anonymous SIP calls allowed, 99% of folks fit in the disallow anonymous SIP calls category, further, if you don't know whether you fit in that category or not, then almost certainly you shouldn't allow anon SIP calls.

Further you should have a catchall that sends strange did info to the hangup context.

But as of Asterisk 1.4.20 or so then

alwaysauthreject=yes in sip*.conf will probably stop these calls

JM2CWAE

dicko

p.s. If occasional strange SIP calls concern you, then look in /var/log/secure , this will almost certainly scare you. Now you are aware of the risk, I suggest locking down your ssh server, not using the DMZ, setting up your firewall restrictively, and installing fail2ban or OSSEC should now be high on your list of things to do.
 

pucky900

Joined
Feb 9, 2009
Messages
51
Likes
0
Points
0
#7
Thanks for clarifying the Anonymous SIP calls... I always thought that had to do with DID being anonymous.
 

danardf

Joined
Dec 3, 2007
Messages
8,069
Likes
10
Points
88
#8
Hi dicko.

Maybe it should be urgent that Elastix provide some security modules.

Regards...
Now I go to look Gremlins II to night. :p :side: :silly: :woohoo:
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#9
DID = Direct Inward Dial
CID = Caller ID,

they sound the same but are very different the DID is in effect your "phone Number" if someone calls your server but want you to process some one elses phone number, then I suggest you shouldn't do that :)

Blocked or withheld or unavailable CallerID's are another thing and generally should have a destination, Known CID's can be more directly routed.
 

newboy

Joined
Mar 11, 2009
Messages
60
Likes
0
Points
0
#10
I Tried setting "Allow Anonymous Inbound SIP Calls?" to "NO" but as soon as i set it to no. i could not recieve calls from "Private" or "Blocked Numbers". It plays a message that the number you have dialed is not in service.

I tried creating a new Inbound rule with CID as Private or Blocked. But still the same thing happens.
 

Patrick_elx

Joined
Dec 14, 2008
Messages
1,120
Likes
0
Points
0
#11
that means that your trunks are not properly setup and instead of receiving a call from the specified trunks you were receiving the calls from the anonymous context...
 

newboy

Joined
Mar 11, 2009
Messages
60
Likes
0
Points
0
#12
I can recieve calls. The system woirks fine with normal calls. Its only the calls with blocked or private numbers that are not coming through.

I have checked the trunks again. All the settings are according to "Elastix without tears" and i had posted them on the forum as well, previously and everyone said that the settings were fine.

Can you please explain a bit more on what can i do to fix this problem.
 

pucky900

Joined
Feb 9, 2009
Messages
51
Likes
0
Points
0
#13
I changed mine to "No" and it does seem to be working for me. I tried calling my system from Skype which is giving me a source of Restricted and Clid of Anonymous which is what I get when people are blocking their number. Since making these changes, I haven't seen any hacking attacks. You may want to check with your VSP for your correct trunk settings. I'm using Bandwidth and my truck settings are very different than what's in the With Out Tears manual.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#14
The hover-over help for the CID field is

Caller ID Number:

Define the Caller ID Number to be matched on incoming calls.

Leave this field blank to match any or no CID info. In addition to standard dial sequences, you can also put Private, Blocked, Unknown, Restricted, Anonymous and Unavailable in order to catch these special cases if the Telco transmits them.

So to start, in the inbound routes for your DID's leave them blank, and become more restrictive as you become more familiar with how it works.
 

pucky900

Joined
Feb 9, 2009
Messages
51
Likes
0
Points
0
#15
What I did was define the incoming route DID with each one of our phone numbers and leaving the Clid blank. Then created a catch all with DID&Clid blank and that getting terminated. I figure that if they ain't calling our numbers directly... they're up to no good.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#16
Exactly, now add

alwaysauthreject=yes

to your sip_general_custom.conf files, to further protect your server or you might find that you are still being hammered at the registration level, it's just that no calls will be made, but your are still giving out more info than you want.
 

pucky900

Joined
Feb 9, 2009
Messages
51
Likes
0
Points
0
#17
Thanks for the great info
 

Patrick_elx

Joined
Dec 14, 2008
Messages
1,120
Likes
0
Points
0
#18
newboy said:
I can recieve calls. The system woirks fine with normal calls. Its only the calls with blocked or private numbers that are not coming through.
If you are not showing us your setup or your logs we will have a hard time to help you.

copy the log of an incoming call working and one not working.
 

newboy

Joined
Mar 11, 2009
Messages
60
Likes
0
Points
0
#19
Here are the logs

Incoming call Not Working

Here is the log from the debug:

== Manager 'admin' logged off from 127.0.0.1
-- Executing [s@from-sip-external:1] GotoIf("SIP/899060XXXXXXXXXX-b770b460", "0?from-trunk||1" in new stack
-- Executing [s@from-sip-external:2] Set("SIP/899060XXXXXXXXXX-b770b460", "T IMEOUT(absolute)=15" in new stack
-- Channel will hangup at 2009-11-27 22:24:31 UTC.
-- Executing [s@from-sip-external:3] Answer("SIP/899060XXXXXXXXXX-b770b460", "" in new stack
-- Executing [s@from-sip-external:4] Wait("SIP/899060XXXXXXXXXX-b770b460", " 2" in new stack
-- Executing [s@from-sip-external:5] Playback("SIP/899060XXXXXXXXXX-b770b460 ", "ss-noservice" in new stack
-- <SIP/899060XXXXXXXXXX-b770b460> Playing 'ss-noservice' (language 'au'
== Spawn extension (from-sip-external, s, 5) exited non-zero on 'SIP/899060116 1001255-b770b460'
-- Executing [h@from-sip-external:1] NoOp("SIP/899060XXXXXXXXXX-b770b460", " Hangup" in new stack
-- Executing [h@from-sip-external:2] Set("SIP/899060XXXXXXXXXX-b770b460", "D ID=s" in new stack
-- Executing [h@from-sip-external:3] Goto("SIP/899060XXXXXXXXXX-b770b460", " s|1" in new stack
-- Goto (from-sip-external,s,1)
-- Executing [s@from-sip-external:1] GotoIf("SIP/899060XXXXXXXXXX-b770b460", "0?from-trunk|s|1" in new stack
-- Executing [s@from-sip-external:2] Set("SIP/899060XXXXXXXXXX-b770b460", "T IMEOUT(absolute)=15" in new stack
-- Channel will hangup at 2009-11-27 22:24:36 UTC.
-- Executing [s@from-sip-external:3] Answer("SIP/899060XXXXXXXXXX-b770b460", "" in new stack



When i receives the call it just plays the no service message





Log for Incoming call "Working"

Executing [s@from-sip-external:1] GotoIf("SIP/8990601161001255-b7605788", "1?from-trunk||1") in new stack
-- Goto (from-trunk,s,1)
-- Executing [s@from-trunk:1] Set("SIP/8990601161001255-b7605788", "__FROM_D ID=s") in new stack
-- Executing [s@from-trunk:2] Gosub("SIP/8990601161001255-b7605788", "app-bl acklist-check|s|1") in new stack
-- Executing [s@app-blacklist-check:1] LookupBlacklist("SIP/8990601161001255 -b7605788", "") in new stack
-- Executing [s@app-blacklist-check:2] GotoIf("SIP/8990601161001255-b7605788 ", "0?blacklisted") in new stack
-- Executing [s@app-blacklist-check:3] Return("SIP/8990601161001255-b7605788 ", "") in new stack
-- Executing [s@from-trunk:3] ExecIf("SIP/8990601161001255-b7605788", "0 |Se t|CALLERID(name)=61425861832") in new stack
-- Executing [s@from-trunk:4] Set("SIP/8990601161001255-b7605788", "FAX_RX=d isabled") in new stack
-- Executing [s@from-trunk:5] Set("SIP/8990601161001255-b7605788", "__CALLIN GPRES_SV=allowed_not_screened") in new stack
-- Executing [s@from-trunk:6] SetCallerPres("SIP/8990601161001255-b7605788", "allowed_not_screened") in new stack
-- Executing [s@from-trunk:7] Goto("SIP/8990601161001255-b7605788", "ivr-4|s |1") in new stack
-- Goto (ivr-4,s,1)
-- Executing [s@ivr-4:1] Set("SIP/8990601161001255-b7605788", "MSG=custom/Ma inIVR") in new stack
-- Executing [s@ivr-4:2] Set("SIP/8990601161001255-b7605788", "LOOPCOUNT=0") in new stack
-- Executing [s@ivr-4:3] Set("SIP/8990601161001255-b7605788", "__DIR-CONTEXT =default") in new stack
-- Executing [s@ivr-4:4] Set("SIP/8990601161001255-b7605788", "_IVR_CONTEXT_ ivr-4=") in new stack
-- Executing [s@ivr-4:5] Set("SIP/8990601161001255-b7605788", "_IVR_CONTEXT= ivr-4") in new stack
-- Executing [s@ivr-4:6] GotoIf("SIP/8990601161001255-b7605788", "0?begin") in new stack
-- Executing [s@ivr-4:7] Answer("SIP/8990601161001255-b7605788", "") in new stack
-- Executing [s@ivr-4:8] Wait("SIP/8990601161001255-b7605788", "1") in new s tack
-- Executing [s@ivr-4:9] Set("SIP/8990601161001255-b7605788", "TIMEOUT(digit )=3") in new stack
-- Digit timeout set to 3
-- Executing [s@ivr-4:10] Set("SIP/8990601161001255-b7605788", "TIMEOUT(resp onse)=10") in new stack
-- Response timeout set to 10
-- Executing [s@ivr-4:11] Set("SIP/8990601161001255-b7605788", "__IVR_RETVM= ") in new stack
-- Executing [s@ivr-4:12] ExecIf("SIP/8990601161001255-b7605788", "1|Backgro und|custom/MainIVR") in new stack
-- <SIP/8990601161001255-b7605788> Playing 'custom/MainIVR' (language 'au')
== Spawn extension (ivr-4, s, 12) exited non-zero on 'SIP/8990601161001255-b76 05788'
-- Executing [h@ivr-4:1] Hangup("SIP/8990601161001255-b7605788", "") in new stack
== Spawn extension (ivr-4, h, 1) exited non-zero on 'SIP/8990601161001255-b760 5788'
 

Patrick_elx

Joined
Dec 14, 2008
Messages
1,120
Likes
0
Points
0
#20
newboy said:
Here are the logs

Incoming call Not Working

-- Executing [s@from-sip-external:1] GotoIf("SIP/899060XXXXXXXXXX-b770b460", "0?from-trunk||1" in new stack


Log for Incoming call "Working"
Executing [s@from-sip-external:1] GotoIf("SIP/8990601161001255-b7605788", "1?from-trunk||1") in new stack
You'll notice that both calls are coming from the context from-sip-external (no context set up in the trunk ?), but both are routed differently (different sip info sent by the provider ?).

Post your trunk config and the log with a 'sip set debug' to show what your provider is sending you.
 

Staff online

Members online

Latest posts

Forum statistics

Threads
30,901
Messages
130,885
Members
17,561
Latest member
marouen
Top