123456789
789
What you are seeing is not a result of a “hacked” system. The system is only doing exactly what it is configured to do according to FreePBX’s default dialplan.
The calls are simply coming in directly to your PBX from a remote SIP source (ie. PBX, softphone, et.al.) to the ‘s’ extension in the ‘from-sip-external’ context.
Let’s follow the call path:
Remote caller dials 's@YOUR_IP_ADDRESS’
Your PBX receives the call from an anonymous SIP source to extension 's’
There is no matching peer for the call, so Asterisk consorts to using the default context defined in sip_general_additional.conf:
context=from-sip-external
The call goes to the context ‘from-sip-external’, extension ‘s’. Here is the ‘from-sip-external’ context:
[from-sip-external]
;give external sip users congestion and hangup
; Yes. This is really meant to be _. - I know asterisk whinges about it, but
; I do know what I’m doing. This is correct.
exten => _.,1,NoOp(Received incoming SIP connection from unknown peer to ${EXTEN})
exten => _.,n,Set(DID=${IF($["${EXTEN:1:2}"=""]?s:${EXTEN})})
exten => _.,n,Goto(s,1)
exten => s,1,GotoIf($["${ALLOW_SIP_ANON}"=“yes”]?from-trunk,${DID},1)
exten => s,n,Set(TIMEOUT(absolute)=15)
exten => s,n,Answer
exten => s,n,Wait(2)
exten => s,n,Playback(ss-noservice)
exten => s,n,Playtones(congestion)
exten => s,n,Congestion(5)
exten => h,1,NoOp(Hangup)
exten => i,1,NoOp(Invalid)
exten => t,1,NoOp(Timeout)
If you are not allowing anonymous SIP peers, then the call is answered, 2 seconds of silence, the ‘ss-noservice’ message played, and congestion presented.
The callerID will come in as whatever the caller sets it to, as per your examples “asterisk”, “MeucciSolutions”, etc.
What you are seeing is easily reproduced from any remote SIP source; perhaps a result of poor default dialplan, but certainly NOT a “HACK”. What can you do if this is still bothering you? Gut the default dialplan like follows:
[from-sip-external]
;give external sip users congestion and hangup
; Yes. This is really meant to be _. - I know asterisk whinges about it, but
; I do know what I’m doing. This is correct.
exten => _.,1,NoOp(Received incoming SIP connection from unknown peer to ${EXTEN})
exten => _.,n,Set(DID=${IF($["${EXTEN:1:2}"=""]?s:${EXTEN})})
exten => _.,n,Goto(s,1)
exten => s,1,GotoIf($["${ALLOW_SIP_ANON}"=“yes”]?from-trunk,${DID},1)
exten => s,n,hangup
Immediately drop the call, no answer, no CDR, you can sleep at night 
fghij
Vedt -
For someone who has:
you write and eloquent diatribe with no foundation for your statements.
If you are suggesting that compromised code had made into the FreePBX or Asterisk SVN’s I suggest your scour the Sunday paper for tin foil coupons, your spy defense hat has been compromised and you need to reinforce it.
You are running a build provided by lylix.net. I am also going to make a leap of faith an assume their image has not been compromised.
You say the server has not been advertised, not sure what difference that makes. The ISP’s subnets are well known and under continuous scans and attacks. SIP being a simple ASCII based protocol is very easy to spoof identities. I can send you a call from the Pope or the White House.
If you wanted to share relevant information SIP logs and even packet traces would reveal the true source IP of the traffic. In today’s Internet it is near impossible to spoof a source IP address at layer 3.
There are known hacks to Linux to source remote calling attacks/abuses. These sources are dropped into the server through simple compromises via HTTP or even SSH.
Did you secure your box at turn up with iptables or did you leave all of the services exposed to the Internet?
This is a community support forum for the FreePBX software, why you choose this venue instead of the distributions forum escapes me.
If you simply wanted to vent or have a meaningful security dialog that’s cool.
I am unclear of your motives. Clearly you don’t trust the technology. Spending more time understanding would allow you to secure your system and properly evaluate the risks and benefits.
Scott
321
Let’s end this one here, OK?
No more wasting everyone’s time.
1/2 the story is only 1/2.
The 1/2 U see neither answered the underlying problems nor did anything but add whipped cream to a Careful Effort To Avoid Answering the Specific Security Problems Addressed in careful detail…that for perhaps obvious reasons, have been erased.
Click “Next Thread”
-30-
Yeah Bob - strangest thread I ever read. There was no ‘breach’ information in here.
Bottom line is the guy tossed up a new, wide open unsecured system and simply could not imagine why he was getting anonymous SIP traffic.
The messages where extremely long and said simply nothing.
Bizarre holier than thou attitude.
Funny too, calling me a code jock. I guess I acquired a new skill
"they’ now the posts are speaking collectively claim that the questions where not answered. I never saw an actual question in their entire rant, nor a useful suggestion.
Takes all kinds I guess…
As a multi-course SANS Institute graduate, I read through what wasn’t deleted by the original poster and see nothing but best practice recommendations.
IPTables, Fail2Ban and OSSEC are some very good measures to take wrt securing Asterisk based install.
Very strange thread, somebody got a bad fortune in their cookie.
Wow - 15 paragraphs of complete drivel, clearly you enjoy hearing yourself talk, or in this case reading your prose. Now there is your cheap shot
There are tens of thousands of Open Source telephony deployments in both the Enterprise and Commercial space, serving applications all over the world. Securing Asterisk on Linux is no different, nor does it require any practices beyond the extensive base of Linux security. A whole industry exists to secure Linux.
FreePBX was never intended to be exposed to threats and should be, as all administrator interfaces protected by proper perimeter security. Some of my more secure clients run an isolated IT management WAN for all infrastructure control application access, out of band terminal servers and metric collection (SNMP, RMON ....) While these management LANS provide the most extreme and physically isolated access reasonable security can be accomplished with proper access lists (I prefer them in the perimeter device) using IPtables.
In order to reap all the benefits of Unified Communications you have to expose SIP and RTP services to the big, bad Internet. Common practice is to use Fail2Ban or other IDS systems to minimize the effectiveness of brute force attacks. My standard LAMP installation includes a tight Fail2ban configuration. This solution is well documented on a number of sites and blogs.
[quote]By the way, source IP address falsification is unfortunately all too common in the criminal community[/quote]
This is a statement I have to qualify and debunk. The way the Internet is constructed, without physical access to an adjacent host (and again I am making a leap of faith that the main CO downtown has not been invaded by criminal elements) it is not possible to hide the source address of a packet or datagram. Communications are full duplex, the remote host has to be reachable, thus it must have a valid IP address. Modern firewalls reject packets without a reachable reverse path.
In the time it took you to author these 15 paragraphs you could have executed the 'yum install fail2ban' command and setup a few iptables rules. These are hardly obscure practices known only to a few guru's. The traffic in your CDR's would have been thwarted and this discussion muted.
Je serai ici long après que vous êtes allé
Enough.
“Drivel”?
You are embarrassing proud of yourself for a code jock.
You ducked all the questions and security issues with standard cooked answers to other things.
Your ‘wishful thinking’ and new “leaps of faith” about security on the Net are getting a little ludicrous.
Pure “Not Invented Here” thinking…and ducking the real issues.
What you don’t know about deep net professional security is plain to see among experts.
Don’t bother replying, because we are ending participation in this thread. You can flame to yourself and for your buddies.
Stick to basic coding and pay to go to some serious security seminars run by real experts. You may be a little surprised (+shocked) at what you hear. That’s good!
Anyway, with your present attitude, you will never ‘make it’ as a leader in the carrier world.
Bye bye…
Dear Administrator, Please close this thread. It has become counterproductive to discuss security issues here, as the responding party has become abusive. Given how it has degraded into a slagging session, and not a serious discussion of security issues, we would prefer to see the entire thread erased. We will consider another place to address these issues at a later date, perhaps a conference workshop, for example. Thank you for considering erasing the thread entirely, as it has become pointless, given the abusive and unprofessional replies.
-30-
I found a document, a pdf copy, of what they do. This company is based in Belgium. Below are part of the document and I quote:
"Meucci Solution’s platform will perform test calls towards your network from a large number of routes:
- Mobile Operators including MVNO
- Fixed Operators, including incumbent and alternative carriers
- VOIP operators such as Skyp and Gizmo
- Calling Cards
- Carrier Routes
- Carrier Exchanges "
“Meucci Solutions offers the possibility to send you real time notifications containing all SIM Boxes (& Leaky PBX) detected.”
So basing from the above line how could they detect a “Leaky PBX” without trying to hack our PBX servers, hmmm :)?
The way I understand their business is they are an anti small VOIP operator or calling card operators who used grey routes in their termination. They are pro big TELCO’s, TELCO’s who does not want small operators to compete with them. Especially those small operators who are using out of the box GSM gateways.
This is a 17 pages pdf file, anyone who want’s to received a copy of this file let me know.