<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic An unsolicited ICMP reply in Security e-Series</title>
    <link>https://community.hpe.com/t5/security-e-series/an-unsolicited-icmp-reply/m-p/6365531#M242</link>
    <description>&lt;P&gt;Why would some important computers on my network start sending ICMP replies an external IP address when there was never an ICMP Ping Request (echo)? Seeing 0 hits via any search mechanism for this specific scenario, thought we'd share our findings.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We searched in vain for something which would incite a reply where there was no echo. We knew when it started, we knew where it was trying to go, but finding out why was problematic. Network Monitor confirmed the packets were sourcing from the victims but will not reveal the process generating the traffic. Process Monitor is conspicuously silent during the time in question. Changes made to the file system around zulu were clean. A memory dump wasn't of assistance. Hashes of binaries were legitimate. Prefetch was benign. The interval of the echo reply was consistent. There are no matches for a multitude of string/word variants for obfuscating the target IP.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Rewording our searches&amp;nbsp;reveals the article /t5/Systems-Management-OpenView-OP/ICMP-heartbeat/ where Drew Dimmick (THANK YOU) writes "OVO ... does implement an additional status monitoring capability based on a "heard from" (not polling) heartbeat monitor - the agents send icmp replies to the manager *unasked for* - the management server monitors if its heard from the node in the last x time and will interrogate the node with a direct ping &amp;amp; rpc call if it isn't heard from - this reduces the overhead of the status monitoring, as OVO will only actively poll nodes when they have not been heard from. Both OVOW and OVOU implement heartbeat polling with this approach (icmp reply) as its extremely network efficient and very low overhead on the receiving systems (tcp requests are many times more expensive)"&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;This helped us focus on the most recent install performed by another team of OVO. The suspicious activity and change were close enough. Performed a "net stop opcmsga" &amp;amp; the beacon ceases. After enabling logging we find in \Program Files\HP OpenView\data\log\trace_hang\ agentrc_xxxx.trc the smoking gun. "I_am_alive-pkg" logging "Sending ICMP reply" to prim.mgr , albeit WITH THE IP INVERSED. Address: 1.2.3.4 becomes Address: 4.3.2.1&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So are we really the first people to have discovered that this mechanism is totally disfunctional?&lt;/P&gt;&lt;P&gt;Hope this is helpful for someone out there in Networking / Security.&lt;/P&gt;</description>
    <pubDate>Thu, 13 Feb 2014 14:27:20 GMT</pubDate>
    <dc:creator>31douglas</dc:creator>
    <dc:date>2014-02-13T14:27:20Z</dc:date>
    <item>
      <title>An unsolicited ICMP reply</title>
      <link>https://community.hpe.com/t5/security-e-series/an-unsolicited-icmp-reply/m-p/6365531#M242</link>
      <description>&lt;P&gt;Why would some important computers on my network start sending ICMP replies an external IP address when there was never an ICMP Ping Request (echo)? Seeing 0 hits via any search mechanism for this specific scenario, thought we'd share our findings.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We searched in vain for something which would incite a reply where there was no echo. We knew when it started, we knew where it was trying to go, but finding out why was problematic. Network Monitor confirmed the packets were sourcing from the victims but will not reveal the process generating the traffic. Process Monitor is conspicuously silent during the time in question. Changes made to the file system around zulu were clean. A memory dump wasn't of assistance. Hashes of binaries were legitimate. Prefetch was benign. The interval of the echo reply was consistent. There are no matches for a multitude of string/word variants for obfuscating the target IP.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Rewording our searches&amp;nbsp;reveals the article /t5/Systems-Management-OpenView-OP/ICMP-heartbeat/ where Drew Dimmick (THANK YOU) writes "OVO ... does implement an additional status monitoring capability based on a "heard from" (not polling) heartbeat monitor - the agents send icmp replies to the manager *unasked for* - the management server monitors if its heard from the node in the last x time and will interrogate the node with a direct ping &amp;amp; rpc call if it isn't heard from - this reduces the overhead of the status monitoring, as OVO will only actively poll nodes when they have not been heard from. Both OVOW and OVOU implement heartbeat polling with this approach (icmp reply) as its extremely network efficient and very low overhead on the receiving systems (tcp requests are many times more expensive)"&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;This helped us focus on the most recent install performed by another team of OVO. The suspicious activity and change were close enough. Performed a "net stop opcmsga" &amp;amp; the beacon ceases. After enabling logging we find in \Program Files\HP OpenView\data\log\trace_hang\ agentrc_xxxx.trc the smoking gun. "I_am_alive-pkg" logging "Sending ICMP reply" to prim.mgr , albeit WITH THE IP INVERSED. Address: 1.2.3.4 becomes Address: 4.3.2.1&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So are we really the first people to have discovered that this mechanism is totally disfunctional?&lt;/P&gt;&lt;P&gt;Hope this is helpful for someone out there in Networking / Security.&lt;/P&gt;</description>
      <pubDate>Thu, 13 Feb 2014 14:27:20 GMT</pubDate>
      <guid>https://community.hpe.com/t5/security-e-series/an-unsolicited-icmp-reply/m-p/6365531#M242</guid>
      <dc:creator>31douglas</dc:creator>
      <dc:date>2014-02-13T14:27:20Z</dc:date>
    </item>
    <item>
      <title>Re: An unsolicited ICMP response</title>
      <link>https://community.hpe.com/t5/security-e-series/an-unsolicited-icmp-reply/m-p/6369073#M246</link>
      <description>&lt;P&gt;It would be helpful to include the full URL to that post:&lt;/P&gt;&lt;P&gt;&lt;A target="_blank" href="https://community.hpe.com/t5/Systems-Management-OpenView-OP/ICMP-heartbeat/m-p/3626930#M56990"&gt;http://h30499.www3.hp.com/t5/Systems-Management-OpenView-OP/ICMP-heartbeat/m-p/3626930#M56990&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;You might want to give Drew a Kudos.&amp;nbsp; :-)&lt;/P&gt;</description>
      <pubDate>Sun, 09 Feb 2014 00:59:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/security-e-series/an-unsolicited-icmp-reply/m-p/6369073#M246</guid>
      <dc:creator>Dennis Handly</dc:creator>
      <dc:date>2014-02-09T00:59:38Z</dc:date>
    </item>
    <item>
      <title>Re: An unsolicited ICMP reply</title>
      <link>https://community.hpe.com/t5/security-e-series/an-unsolicited-icmp-reply/m-p/6581022#M260</link>
      <description>Agent version 11.13 with patch HFWIN_13044 resolves this issue.</description>
      <pubDate>Thu, 21 Aug 2014 06:47:19 GMT</pubDate>
      <guid>https://community.hpe.com/t5/security-e-series/an-unsolicited-icmp-reply/m-p/6581022#M260</guid>
      <dc:creator>31douglas</dc:creator>
      <dc:date>2014-08-21T06:47:19Z</dc:date>
    </item>
  </channel>
</rss>

