| Summary: | ASTERISK-20506: With alwaysauthreject=yes AND allowguest=no Asterisk fails to report Attacker's IP Address | ||||||||
| Reporter: | MBH (mbh) | Labels: | |||||||
| Date Opened: | 2012-10-03 06:34:00 | Date Closed: | 2012-10-17 17:29:18 | ||||||
| Priority: | Major | Regression? | |||||||
| Status: | Closed/Complete | Components: | Channels/chan_sip/General | ||||||
| Versions: | 1.8.15.1 | Frequency of Occurrence | Constant | ||||||
| Related Issues: |
| ||||||||
| Environment: | CentOS release 5.8 (Final), Kernel 2.6.18-308.8.2.el5.028stab101.1, 32-bit, running on an OpenVZ VPS. | Attachments: | ( 0) sipdump.pcap | ||||||
| Description: | My Asterisk box is being brute forced and I'm getting messages in the logs referencing my box's IP instead of the attacker's: [2012-10-03 03:49:45] NOTICE[28161]: chan_sip.c:22723 handle_request_invite: Sending fake auth rejection for device 5550000<sip:5550000@AsteriskIP>;tag=396cbe1b The notice message is not logging the attacker IP at all, thus cannot be blocked using fail2ban. The same is mentioned here: http://lists.digium.com/pipermail/asterisk-users/2011-March/260377.html and here http://forums.digium.com/viewtopic.php?t=78988 I'm using type=peer, alwaysauthreject=yes, allowguest=no | ||||||||
| Comments: | By: Matt Jordan (mjordan) 2012-10-03 08:32:03.944-0500 This issue is already fixed in Asterisk 10+ by including the appropriate message in the Security Event Framework. This has been a contentious issue, and I understand that the fact that the log message has not been changed in Asterisk 1.8 is a point of frustration. As Walter pointed out on ASTERISK-19348, there are limiting factors in Asterisk 1.8 that prevent us from being able to conclusively provide the IP address of the attacker: {quote} As an aside: chan_sip.c: NOTICE[xxxxx]: Call attempt was made from SPOOFED SOURCE IP: x.x.x.x with TRUE SOURCE IP: x.x.x.x There are so many IP addresses in a packet, and none of them qualifies as the "spoofed source IP". Relevant IPs for a request would probably be: VIA_SENT_BY_IP (from the top Via header) and APPARENT_SOURCE_IP (from the socket layer), where the latter can still be easily spoofed in many cases (see UDP spoofing). Pavel Troller already mentioned that in the mailing list: > In that case maybe Asterisk can pull the IP from network layer of the OS?! Of course it can, but please be informed, that at least on systems I'm running, a lot of attacks are done with spoofed source IP addresses {quote} I'm open to discussing this again with anyone who cares to address the points listed above. By: Michael L. Young (elguero) 2012-10-03 11:31:00.808-0500 There have been some discussions, if I recall properly, on other ways you can protect yourself. Something that I remember researching some time back and finding was that you could use IPtables to throttle the attack using "-m recent". For instance, you can limit the bursts to help mitigate any DDoS. Then when an attack from an IP hits their limit of say 20 hits within 30 seconds, you drop the packet. You can "-j LOG" the dropped packet and have fail2ban take action to ban the IP based on the system log. There are other ways to protect your self that doesn't require the Asterisk log to contain the IP address. Using the above suggestion along with the Asterisk log file can be very effective. Granted, it is much easier if you only had to check one place. By: MBH (mbh) 2012-10-04 05:26:29.068-0500 "but please be informed, that at least on systems I'm running, a lot of attacks are done with spoofed source IP addresses" If that is the case, and I'm sure it's correct, then how is the issue resolved in Asterisk 10? Also, Asterisk 8 is supposedly Long Term Support. Is the reason for not fixing this, because it may require an overhaul of existing functions? Someone in asterisk IRC channel suggested a simpler option than iptables throttling: Accept anonymous calls, generate a special event, ban them. This works if you do not accept anonymous calls by default, otherwise, you're back to iptables voodoo. By: Matt Jordan (mjordan) 2012-10-04 09:54:37.569-0500 This got fixed in 10+ by virtue of the security event framework, which is the appropriate mechanism for reporting security related information to external entities. Since that was a new feature in 10+, it wasn't a candidate for backporting. Part of the issue here is that the only mechanism available in 1.8 are Asterisk log messages, which are not standardized for consumption by external applications. For example, if we change the log format message for any message that someone may potentially use in an external application, we have now broken their integration. We have to be very, very cautious about any patch that gets applied in these situations. The security event framework - and its module that logs such events to a log file - has a standard format. So it doesn't have this limitation. For Asterisk 1.8, I'm certainly open to any solution that solves this problem, while addressing people concerns regarding how much it claims to solve and/or addressing all aspects of peoples issues with the approach, and that does so in a fashion that won't break existing implementations of Asterisk 1.8. As an aside, something being an LTS does not mean that it gets the new features developed for later versions - in fact, if anything, the opposite is true. The fact that this was readily solved in 10+ is because of new features developed for those versions. Backporting those new features to 1.8 would not only violate the feature policy for Asterisk, but would be highly intrusive and inject significant risk. I don't think that's the appropriate way to handle this. By: MBH (mbh) 2012-10-04 10:28:23.846-0500 Thank you for the explanation Matt. I guess I'll move to Asterisk 10 and get over with it. I assume the log output is fail2ban-friendly, correct? Also, I did not suggest that LTS should get new features. I was wondering on why an LTS build wasn't patched/fixed, and since you said that the security event framework is new, then it shouldn't be backported, as it's not a bug fix but an enhancement. As for Asterisk 1.8, it was mentioned before that the IPs can be spoofed, and logging them to ban them is kind of pointless. You've suggested throttling via iptables & I mentioned that for the setups that do not need anonymous calls, they can enable them, log these specific calls and send them to a busy-tone/congested end, then use the IP to ban them. Other than that, I honestly don't see a reliable way within asterisk 1.8 to handle such a problem. Maybe the default configs should be updated to mention this security problem and that it can be avoided with v10, or if v8 is necessary, stick to the proper security procedures (type=peer, alwaysauthreject=yes, allowguest=no), ...etc. to prevent user enumeration. By: MBH (mbh) 2012-10-08 12:54:19.197-0500 Hello again. I have installed Asterisk 10 & enabled the security logging in logger.conf and I still get the same auth rejection messages in /var/log/asterisk/messages with a fake IP, but security doesn't show anything. [2012-10-07 21:23:55] NOTICE[5847] chan_sip.c: Sending fake auth rejection for device 201<sip:201@AsteriskIP>;tag=9e4a1889 [2012-10-07 21:23:55] NOTICE[5847] chan_sip.c: Sending fake auth rejection for device 201<sip:201@AsteriskIP>;tag=9e4a1889 [2012-10-08 00:49:20] NOTICE[5847] chan_sip.c: Sending fake auth rejection for device "sipvicious"<sip:100@1.1.1.1>;tag=3465326661643461313363340132303932393039303130 [2012-10-08 01:15:55] NOTICE[5847] chan_sip.c: Sending fake auth rejection for device "sipvicious"<sip:100@1.1.1.1>;tag=34653266616434613133633401343838323735373533 [2012-10-08 04:37:03] NOTICE[5847] chan_sip.c: Sending fake auth rejection for device 101<sip:101@AsteriskIP>;tag=cab0f2e6 [2012-10-08 04:37:03] NOTICE[5847] chan_sip.c: Sending fake auth rejection for device 101<sip:101@AsteriskIP>;tag=cab0f2e6 [2012-10-08 10:42:13] NOTICE[5847] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@94.231.83.138>;tag=B9JloXj8Qp [2012-10-08 10:42:13] NOTICE[5847] chan_sip.c: Sending fake auth rejection for device "unknown" <sip:unknown@94.231.83.138>;tag=fDCq85udqo The time stamp of these attacks is not related to the events listed in asterisk's security log. This is the last thing I saw in my security log: [2012-10-08 10:57:56] SECURITY[5827] res_security_log.c: SecurityEvent="InvalidAccountID",EventTV="1349693876-568238",Severity="Error",Service="SIP",EventVersion="1",AccountID="001972592283580",SessionID="0x95e4290",LocalAddress="IPV4/UDP/AsteriskIP/5060",RemoteAddress="IPV4/UDP/37.8.25.94/5071" By: Michael L. Young (elguero) 2012-10-08 13:09:05.735-0500 MBH, what SIP methods are these messages coming from? INVITE, REGISTER or what? By: MBH (mbh) 2012-10-08 13:12:04.165-0500 How can I tell? It's not mentioned in the logs. By: Michael L. Young (elguero) 2012-10-08 13:14:11.001-0500 Turn on sip debug at the console and you should see what method is being requested. By: MBH (mbh) 2012-10-08 13:17:11.464-0500 Done. I'll wait for new attacks & get back to you. (suspense!) By: Matt Jordan (mjordan) 2012-10-08 13:59:46.046-0500 You shouldn't have to wait for an attack. Have something that isn't defined (a guest) attempt to register. Does that report anything in the security logs? Have something that isn't defined attempt to make a call. Does that report anything in the security logs? IIRC, the issue here was always about INVITE requests, not REGISTER requests, but it would be good to verify both scenarios. By: MBH (mbh) 2012-10-09 05:56:22.907-0500 The security logs are still empty & I got new scans: [2012-10-09 07:57:06] NOTICE[5847] chan_sip.c: Sending fake auth rejection for device "sipvicious"<sip:100@1.1.1.1>;tag=3465326661643461313363340133303336393537373332 [2012-10-09 07:58:07] NOTICE[5847] chan_sip.c: Sending fake auth rejection for device "sipvicious"<sip:100@1.1.1.1>;tag=34653266616434613133633401393134323035333330 Enabling the SIP debugging option didn't add any info on whether it's INVITE or REGISTER. By: MBH (mbh) 2012-10-09 05:57:11.850-0500 Note: I enabled the debugging like this: $asterisk -r >sip set debug on If I missed anything, let me know. By: Michael L. Young (elguero) 2012-10-09 09:22:49.543-0500 Well, the point of sip set debug on was to see the sip messages from the console and see what was coming in and out from your pbx. The reason for my asking if it was INVITE or REGISTER is that sip only reports security events for those two methods. By: Rusty Newton (rnewton) 2012-10-10 17:25:16.571-0500 MBH, can you grab a SIP pcap of the traffic in question and attach to the issue? Otherwise the output of the previously mentioned "sip set debug on" inline with your full log output? https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: MBH (mbh) 2012-10-12 05:31:21.229-0500 SIP tcpdump for an attack By: MBH (mbh) 2012-10-12 05:33:44.198-0500 There's nothing in my security log file but I have this in my messages file: [2012-10-12 04:07:36] NOTICE[5847]: chan_sip.c:22739 handle_request_options: Sending fake auth rejection for device "sipvicious"<sip:100@1.1.1.1>;tag=3465326661643461313363340131313537303236303335 This single attack was recorded in the tcpdump I attached. By: Michael L. Young (elguero) 2012-10-12 13:25:19.084-0500 According to your pcap, you are receiving a sip OPTIONS request. That is why it is not being displayed in the security logs. By: MBH (mbh) 2012-10-12 13:27:32.366-0500 So how can we go on about making it to report it? Shouldn't it report all sorts of attacks by default, instead of being selective to INVITE or REGISTER? By: Michael L. Young (elguero) 2012-10-12 13:51:42.934-0500 First of all, Asterisk does not decide what is an attack and what is not. The only thing it does is report events that might be of interest in a way that a tool, module, script, human being, etc. can parse the log and make a decision on what it wants to do with that information. As of right now, only INVITE and REGISTER methods are being reported because that is all the initial implementation of security events in chan_sip was programmed for. INVITE and REGISTER methods are, say, probably more of interest versus OPTIONS (not to say that it shouldn't be reported). From SIP RFC: {quote} The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without "ringing" the other party. For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. {quote} Since INVITES are what creates a call, OPTIONS is probably not as big of a concern. So, it was not added at the time. In order to get the reporting of OPTIONS added, it would require adding the appropriate code to Asterisk and that would not show up until Asterisk 12 since that would be considered a new feature. But, you are always free to add it yourself and even contribute the code if so desired. Otherwise, we have to wait for someone to be able to contribute the additional code or see if someone like myself gets the time to add it. More than likely, someone is scanning for an open PBX that would allow phone calls and since your box has the appropriate security settings in place, they are probably moving on. According to the pcap, correct me if I am wrong, you are not getting hammered or anything from this scan. By: MBH (mbh) 2012-10-13 03:46:54.444-0500 From what I see, they're probing for valid users & passwords, once hit, then they initiate REG & INV directly without being detected as malicious by the security module. For all I know, the culprits could also be reading this exact thread, happy about the outcome. The pcap capture is indeed for a single session, but that was out of the norm. I usually get 10-20 scans a day, though. By the way, the user Thor in the Digium forums did mention that attacks will move to other aspects of SIP from INV & REG, and that was in July 2011: http://forums.digium.com/viewtopic.php?t=78988#p160425 and a sample code was already posted, and it's odd that no one considered other SIP functions. The bug report that this is considered a duplicate of was in Feb & it was submitted to the trunk, so I'm guessing Thor should've reported it as a bug here instead of ranting in forums. By: Walter Doekes (wdoekes) 2012-10-13 04:47:44.418-0500 You do have a valid point there. auth_options_requests=no (the default) does mitigate the OPTIONS problem. But there are indeed a couple of other methods that do get the authentication process working and they should be sent to the security framework. \[Make new bug report #1] But.. the dump that you've shown us does not contain any failed username/password attempt. It only shows authenticationless probing attempts. I'd be interested first when asterisk sends out the 403, not already on the 401/407. As for patches to the original warnings: I too prefer to see ast_sockaddr_stringify(&p->recv) rather than the From header. If only because it's easier to find valid clients that send out crap by IP than by content. \[Make new bug report #2] (And then there are check_auth() and handle_response() which incorrectly report the To address instead of the From (or the auth-user). \[Make new bug report #3]) So, while I do stand by the fact that UDP source addresses can in many cases be spoofed, there are cases when you want to know them (and possibly even block them). By: Rusty Newton (rnewton) 2012-10-17 17:29:18.071-0500 Looks like we have determined this is not a bug. It's becoming a discussion of a feature request or improvement. I'm going to close this issue as "Not A Bug". Anyone can feel free to open a new issue as a feature request, so long as it includes a patch for the behavior being discussed in this report. Continued discussion of the potential feature improvement should happen in #asterisk-dev on IRC or else the asterisk-dev mailing list so that others who are interested may be more likely to see it. Thanks all! By: Matt Jordan (mjordan) 2012-10-18 08:48:26.778-0500 Well, only slightly. As Walter pointed out, there are at least three bugs that could occur out of this. Walter's already created a new issue for two of those. | ||||||||