Snort mailing list archives
Re: TMG Firewall Client long host entry exploit attempt
From: Patrick Mullen <pmullen () sourcefire com>
Date: Tue, 4 Mar 2014 14:18:01 -0500
Carlos, Both of the Shared Object Rules you mention (sids 19187 and 21355) are open source. You can download and read the source from the Open Source rule pack on snort.org. Sid 21355's (mismatched TXID) source has a long description at the top that explains how it works and includes some examples of when it could false positive. In a nutshell, the problem is UDP is not stream-based and we have a limited amount of "stuff" we keep track of for performance reasons, so a condition can arise where we store the TXID for a queried domain, then store the TXID for the same queried domain from another packet, stuff makes us forget the first TXID when the response with that TXID is received, causing the response TXID to not match the only TXID we have stored (which is the one from the later request). This usually won't happen unless you have a non-caching server and multiple users request the same domain at the same time. But it can happen. I don't think the "-k none" had any effect on this, but it's possible, I suppose. This rule provides good detection, but if it's causing problems I recommend you disable it since that is the default state for that rule. Sid 19187 is looking for DNS responses that have excessively long (according to the vulnerable software) host entries. This rule has known false positive issues because some hosts have very long alias lists that cause this rule to alert even though it is non-malicious traffic but do keep in mind that despite no ill intent the traffic WOULD crash the vulnerable software. This rule is disabled by default because of its known issues with falsing on legitimate traffic. My recommendation is to follow the recommended policy of disabling both of these rules after ensuring your environment is not susceptible to the related risks. Thanks, ~Patrick On Mon, Mar 3, 2014 at 6:28 AM, Carlos G Mendioroz <tron () acm org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joel Esler (jesler) @ 03/03/2014 00:53 -0300 dixit:On Mar 2, 2014, at 4:05 PM, Carlos G Mendioroz <tron () acm org <mailto:tron () acm org>> wrote:Signed PGP part Thanks Joel, as I said, that one is like sweeping under the carpet, right ?No, any Snort instance should be tuned to its environment.I would concurr if the rule had some known false positives (none documented) or if I was running some particular soft that could be causing benign triggers, which I'm not. That being the case, it seems a good case to troubleshoot the rule, either it or my installation has some fault.Snort is surprisingly quiet too. Other than this, it seems all the bad guys went on vacation...Try running with "-k none" turned on.I will, but I fail to understand why. I'm not seeing cheksum errors. In fact, in 10 minutes I have now (after suppressing 3:19187 and adding - -k none) some 3:21355:2 - mismatched txid. Fact is, I checked one of the triggering events and the TXID was ok. (answer had same TXid as query). - -Carlos-- *Joel Esler | *Threat Intelligence Team Lead |Open Source Manager | Vulnerability Research TeamOn this one, it seems that the rule is triggering on answers to a ROOT dns query. That one also makes me wonder why is bind asking for that. -Carlos Joel Esler (jesler) @ 02/03/2014 17:59 -0300 dixit:The easiest way to deal with this one is, if you aren't running the tmg firewall client, shut the rule off. -- Joel Esler Sent from my iPhoneOn Mar 2, 2014, at 6:51, "Carlos G Mendioroz" <tron () acm org<mailto:tron () acm org>>wrote:Hi, I've recently installed snort on a home border server. (again, this is a complete re-install of my place infrastructure :) I keep snort running, not frequently updated, just to have some sense of activity. Upload alerts to dshield too. This time, snort remained way too silent. But 3:19187:2 is firing with many of my server's DNS queries. (bind9 forwarder) I've search for clues but this seems to be an so rule and I don't know how to troubleshoot this. I guess I can disable the rule, but that's just going to hide the issue. I do have a capture of one incident triggering the rule, not that it is difficult to reproduce ( Help ? TIA,------------------------------------------------------------------------------Flow-based real-time traffic analytics software. Cisco certified tool.Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool.http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________Snort-users mailing list Snort-users () lists sourceforge net<mailto:Snort-users () lists sourceforge net> Go tothis URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-usersPlease visit http://blog.snort.org to stay current on all the latest Snort news! -- Carlos G Mendioroz <tron () acm org <mailto:tron () acm org>>- -- Carlos G Mendioroz <tron () acm org> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMUZ0AACgkQ7qM4U9dTH3+29gCfREkEC/wuraIhOq6WM+fdUsol DAAAoIhu8Fd6SG1BGo/VSb48Jr03xu0Q =ZuaT -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users Please visit http://blog.snort.org to stay current on all the latest Snort news!
-- Patrick Mullen Response Research Manager Sourcefire VRT
------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users Please visit http://blog.snort.org to stay current on all the latest Snort news!
Current thread:
- TMG Firewall Client long host entry exploit attempt Carlos G Mendioroz (Mar 02)
- Re: TMG Firewall Client long host entry exploit attempt Joel Esler (jesler) (Mar 02)
- Re: TMG Firewall Client long host entry exploit attempt Carlos G Mendioroz (Mar 02)
- Re: TMG Firewall Client long host entry exploit attempt Joel Esler (jesler) (Mar 02)
- Re: TMG Firewall Client long host entry exploit attempt Carlos G Mendioroz (Mar 03)
- Re: TMG Firewall Client long host entry exploit attempt Joel Esler (jesler) (Mar 03)
- Re: TMG Firewall Client long host entry exploit attempt simegnew yihunie (Mar 03)
- Re: TMG Firewall Client long host entry exploit attempt waldo kitty (Mar 04)
- Re: TMG Firewall Client long host entry exploit attempt Carlos G Mendioroz (Mar 02)
- Re: TMG Firewall Client long host entry exploit attempt Patrick Mullen (Mar 04)
- Re: TMG Firewall Client long host entry exploit attempt Carlos G Mendioroz (Mar 04)
- Re: TMG Firewall Client long host entry exploit attempt Patrick Mullen (Mar 04)
- Re: TMG Firewall Client long host entry exploit attempt Carlos G Mendioroz (Mar 04)
- Re: TMG Firewall Client long host entry exploit attempt Joel Esler (jesler) (Mar 02)
- Re: TMG Firewall Client long host entry exploit attempt Randal T. Rioux (Mar 04)