| Summary: | ASTERISK-19348: With alwaysauthreject=yes AND allowguest=no Asterisk fails to report a SIP Security Event | ||||||
| Reporter: | Bruce B (bruceb444) | Labels: | |||||
| Date Opened: | 2012-02-13 10:39:59.000-0600 | Date Closed: | 2012-03-22 19:47:38 | ||||
| Priority: | Major | Regression? | No | ||||
| Status: | Closed/Complete | Components: | Channels/chan_sip/General | ||||
| Versions: | 1.8.9.2 10.1.2 | Frequency of Occurrence | |||||
| Related Issues: |
| ||||||
| Environment: | Attachments: | ( 0) asterisk-19348-auth_fake-sec-event_v1.patch ( 1) asterisk-19348-auth_fake-sip-log-event_v1.patch | |||||
| Description: | Asterisk should log source IP address of incoming calls when allowguest=no AND alwaysauthreject=yes but it doesn't. It seems to be a deficiency of allowguest feature. The only log found when there is an incoming call is this which doesn't include source IP address: NOTICE[10331] chan_sip.c: Sending fake auth rejection for device "Anonymous" <sip:Anonymous@anonymous.invalid>;tag=as4a1b8317 ***WARNING: source IP address in this MUST be pulled from OS network layer rather than relying on SIP Packets as spoofed source IP is not really the source IP. Better yet maybe include both spoofed source IP and true source IP in a message like this: 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 ***It's best to create this log in full log file as well. | ||||||
| Comments: | By: Matt Jordan (mjordan) 2012-02-13 10:54:11.199-0600 The log message coming from chan_sip should not be changed. Its reporting the From: header, which is similar to other NOTICE messages (for example, failing to authenticate a device). The purpose of the NOTICE message is informational only. The correct solution is to use the Security Event framework. The typical message output by the SIP security events should suffice. The AUTH_FAKE_AUTH case just needs to be implemented in security_events.c. By: Bruce B (bruceb444) 2012-02-13 11:41:36.413-0600 I agree with Security Event Framwork implementation but maybe chan_sip should have it as well because chan_sip does log a full notice with source IP address for failed registrations so why not do the same with failed call attempts as well? I think security event framwork would be a good start. Best By: Michael L. Young (elguero) 2012-02-13 16:52:20.080-0600 In looking at this, it should be as simple as a single line of code. A fake 401 is sent because someone is trying to make a call with an invalid account. Therefore, we will log this event as an invalid account ID security event. It is then up to whatever is monitoring the logs to react to this kind of event. Matt, let me know if you think this is sufficient. By: Bruce B (bruceb444) 2012-02-13 19:37:34.505-0600 Michael, thanks. Can this be applied to 1.8x LTS as well? I checked the security_events.c file there but I think it's much different. I think everyone has an interest with this being implemented in 1.8x. By: Michael L. Young (elguero) 2012-02-13 22:09:19.933-0600 Bruce, Unfortunately, chan_sip did not use the security events framework in 1.8. This was a new feature added to Asterisk 10. I think the security_events.c file you are looking at is the actual API for the Asterisk Security Framework which was added in 1.8 but only AMI used it. By: Walter Doekes (wdoekes) 2012-02-14 01:55:33.202-0600 As an aside: {quote}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{quote} 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: {quote} > 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} By: Bruce B (bruceb444) 2012-02-14 07:58:52.904-0600 Michael, In Asterisk 1.8x it shouldn't be that hard to add this and it's probably 4 lines in three places. Never done patches...attached is a very rough draft. Best, By: Bruce B (bruceb444) 2012-02-22 18:14:29.563-0600 Wondering what this is waiting for? Can it be committed already or move to feedback? Best, By: Mark Michelson (mmichelson) 2012-02-28 12:00:15.674-0600 It was just waiting to be assigned to a developer. As has been stated, since the IP address can be spoofed, it's only marginally helpful to log this information. I will add the security event to Asterisk 10+. Bruce B, since you have already created the log message for 1.8, feel free to keep it around, but we aren't going to add it because it sets a bad precedent for us. In other words, this is the beginning of a potential snowball effect of nit-picking log messages. Log messages are nice in discovering potential security issues. They're good for letting you know, in general, what is going on, but log messages are not necessarily written with the intention of helping to discover potential security issues in the same way that security events are. As a final note to Bruce B, I don't know how you created asterisk-19348-auth_fake-sip-log-event_v1.patch, but it is in a very strange format. Use either `diff -u` or `svn diff` in order to create patches. The 'patch' utility does not know how to handle the patch you created since the format is unusual. By: Bruce B (bruceb444) 2012-03-21 23:48:16.187-0500 Okay, we are back to the beginning after all the mailing list posts and creating this bug. I don't see the point of filing any Asterisk bugs. This is registered as a MAJOR bug but last person comes and says, "No, no...." To be honest, this doesn't make a difference for me any-more because we are moving to FreeSwitch and OpenSIPs as they are much more flexible and take security serious (to the point where OpenSIPs has a proactive security events PUSHED - not pulled - to Fail2ban). That is a truly responsible community project. "but we aren't going to add it because it sets a bad precedent for us. In other words, this is the beginning of a potential snowball effect of nit-picking log messages. Log messages are nice in discovering potential security issues. They're good for letting you know, in general, what is going on, but log messages are not necessarily written with the intention of helping to discover potential security issues in the same way that security events are." I am not sure what precedent you are talking about and don't mean to be rude but this bug is SERIOUS. Other versions of Asterisk spit out the attempts but this specific version doesn't. I don't know where one can find the reasoning to defend not to implement this back into the system. No this doesn't open a can of worms. This only helps make tighter security. Tell me one feature that makes Asterisk a security application? There is NONE. It's only the events and if they are not universal and change from version to version then there is no security. Unless you provide a venue for security there is no way one can secure a server. Events have to spit out for any security tool to work. At this point, I don't see any other rational but probably a business conflict with Digium's commercial products as bug was filed properly and discussions were done as well the right way only for it to get dropped. So, I am personally dropping this bug and don't care no more. Adios By: Bruce B (bruceb444) 2012-03-21 23:48:58.827-0500 Digium developers changed mind - probably due to business interest conflict. By: Michael L. Young (elguero) 2012-03-22 18:35:30.604-0500 Sorry you feel that way. I am not part of Digium at all... I doubt Digium had any part of this. You see, we are a community and the community decided to add a Security Events Framework to do what you want to accomplish. The only problem is that it was added in 1.8 without chan_sip generating events. We tried to offer a better solution than log messages but if you do not want to go that route, it is completely up to you. As was suggested by Mark, you are free to change your copy of Asterisk 1.8 to satisfy your needs to have a log message with the information. You could even use the Security Events Framework API to have chan_sip create the desired events. Since the current version of Asterisk and the future versions already have these security events there for chan_sip, there really is nothing to be fixed. In fact Mark already added my patch to generate events for fake authentication replies to Asterisk 10 and trunk, which is the event you were looking for. I am going to check with the devs on why this was not attached to this issue and closed out properly. We wish you well. By: Leif Madsen (lmadsen) 2012-03-22 19:47:38.106-0500 Per elguero on IRC, this issue was closed incorrectly as "Won't fix", when he points out the solution was committed to Asterisk 10 and trunk. Asterisk 10 revision: r357318 trunk revision: r357319 Issue now closed as "Fixed". By: motekpc (gavimobile) 2013-01-31 13:17:06.880-0600 Hey folks, so Ive also been searching the web for a solution to this issue using asterisk 1.8. To review the issue we are talking about, in the asterisk logs we see something like this "chan_sip.c: Sending fake auth rejection for device <sip:mysipserversip>;tag=seqgxjfs4r" and we dont know the ip of the attacker because our own servers ip is listed instead. so the patch here ASTERISK-19348 is not for asterisk 1.8. magically i was able to work this out on my own with asterisk 1.8. i havent tested this yet and this will not cause any damage to your server whatsoever. please understand that i am no pro. do this at your own risk! :-p *EDIT* _This is not the proper place to put this. This belongs on a blog post._ By: Michael L. Young (elguero) 2013-02-05 11:42:57.508-0600 motekpc, please stop posting your solution here on the issue tracker. If you look at this issue, you will see that this is not a proper fix and is not supported. Therefore, please do not post that here. Feel free to create a blog post to explain how you were able to do this and direct people there with your own disclaimer. https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-PatchandCodesubmission Again, this is not the proper place to be posting a step by step guide on how to modify Asterisk code. Thanks By: Martin Glazer (mglazer) 2013-04-04 12:15:38.560-0500 This addition does not work for me on 1.8.20.1 It adds the line to the logs, however the line still contains MY IP adddress and not the attackers. [2013-04-04 05:57:02] NOTICE[3003] chan_sip.c: heres the mofo 810<sip:810@MY.IP>;tag=cdba3225 [2013-04-04 05:57:02] NOTICE[3003] chan_sip.c: Sending fake auth rejection for device 810<sip:810@MY.IP>;tag=cdba3225 By: motekpc (gavimobile) 2013-04-18 05:30:59.998-0500 it actually does work. I catch each day tons of attackers! i dont know when or if i will have time to make a blog, however i believe i posted a more detailed and updated version elsewhere on the web. have a look for it and respond there for more details please. Michael, sorry if i caused trouble. Martin you probably have an error in the fail2ban filter file. the single quotes and the * must be in the right place. By: Vladimir Mikhelson (vmikhelson) 2013-04-24 01:08:15.701-0500 The solution stopped working in 1.8.21.0. Did anybody adapt it for the new version? By: Martin Glazer (mglazer) 2013-04-24 09:39:50.021-0500 motekpc - It is not a problem with the fail2ban scripts, I could not get your patch to work as it would still show the same info as the regular asterisk line (my IP address). Vladimir - I added this patch instead (for 1.8.20.1, not sure about .21) [edit: removed inline patch] By: Michael L. Young (elguero) 2013-04-24 10:23:00.115-0500 Guys, please stop posting on this closed issue and please stop posting code in the comments. That is not the proper way to attach patches. This is not the proper forum for an ongoing discussion of someones way of handling this which has already been discussed and decided that it is not the true and proper fix. Thanks By: Vladimir Mikhelson (vmikhelson) 2013-04-24 10:46:41.186-0500 Michael L. Young, As the Asterisk is an open source software and this tool, read JIRA, is deployed to exchange information related to its development, you are not in a position to dictate what information is suitable and which one is not as long as it is pertinent to the Asterisk development. Some users may agree with your original solution, i.e. switch to v.10, or whatever you meant by your comment of 13/Feb/12 10:09 PM. Martin tries to help other users. By removing his code you made a disservice to the community as the Asterisk Bug Tracker is the place to find solutions like this one. If you chose to remove the code from the body of the message where in my personal opinion it belonged, as it was concise and self-descriptive, you should have reattached it to the case and should have made a reference in the body of the comment. The issue is serious and needs serious attention as it is a network security issue. I was attacked for a number of days and had no idea where this attack(s) were coming from basically through the whole period after I switched to 1.8.21.0 as chan_sip was redesigned. The message to the effect that somebody failed to log in with the extension 9999 is insufficient at best as it does not provide any information for remediation. Please reconsider including the necessary code in 1.8 branch ASAP. I created a very dirty hack yesterday which helped me to isolate and shut down a couple attacks from Gaza. I am hesitant to post the code here as it is too inclusive. Ideally the patch should allow for a necessary forensics collection in the debug mode. The information should include the source IP and passwords attempted. It looks doable to me by anybody who knows the code and functions. Thank you, Vladimir By: Michael L. Young (elguero) 2013-04-24 10:59:22.131-0500 Vladimir, I understand your concern and desire to protect yourself. There is plenty of documentation and guidelines for securing Asterisk. I am sorry that you were attacked and didn't know about it. I am not trying to dictate what information is suitable. I am trying to direct you guys to the proper forums. As with any project, open source or otherwise, there are proper forums for such a discussion and certain guidelines that everyone in the community needs to follow in order to make sure things are handled properly. The issue tracker is not the proper forum. Please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-PurposeoftheAsteriskissuetracker I also tried to direct motekpc on how to post patches if he chose to do so and so far everyone has not followed that suggestion. Code submissions fall under the need to have a license for legal reasons. Therefore, I am not going to remove a patch and re-attach it under my license since it is not my code. Please try the asterisk-users mailing list. This is something you need to bring to the attention of the community and the issue tracker defeats what you are trying to accomplish because it limits this discussion to only those following this issue. You are free to modify your version of Asterisk as you see pleased. But, this is not the proper forum to discuss it. It is an issue tracker for which this issue has been treated, handled, and closed. https://wiki.asterisk.org/wiki/display/AST/Mailing+Lists https://wiki.asterisk.org/wiki/display/AST/IRC Thanks By: Vladimir Mikhelson (vmikhelson) 2013-04-24 11:05:21.203-0500 Michael L. Young, I am on the list, I did read the WiKi. Sorry, I did not know the code was attempted to be submitted with no appropriate license. That explains why it was not attached to the case. It probably still could have been left in-line as a comment in order to help others like myself. I still strongly recommend to reconsider the one-year-old decision to ignore the case. What happens here is a serious security bug / lack of design being ignored. Thank you, Vladimir | ||||||