FAQ: How do I Block Heartbleed on NetScaler?

Q: Is NetScaler affected by Heartbleed vulnerability?

A: Heartbleed is one of the most impactful vulnerability identified in the recent history of SSL protocol. Heartbleed is a bug identified in OpenSSL’s implementation of TLS heartbeat extension which allows intruders to get information from the server’s memory thereby revealing potential user data which was assumed to be safe using TLS. OpenSSL runs in majority of sites hosted in the internet which makes this a widely impacted one. The secure information that is shared with the server is now accessible by the attacker and this action is completely undetectable.

Use cases

  • Andy wishes to interact in a secure fashion (some arbitrary, some known) free from Heartbleed attacks through a web browser.
  • Banking.com wishes to host web servers to be used by people like Andy in a secure fashion free from Heartbleed attack.

Q: How does Heartbleed work?

A: In order to understand Heartbleed, it is required to understand how heartbeat extensions work. There is a heartbeat request-response exchange done between sender and receiver that allows the usage of “keep-alive” without performing a renegotiation. The message format contains Heartbeat message type, Payload, Payload length and Padding. Payload can be any value which needs to be shared with the other participant (say a server). The server copies the payload , creates a response message around it and replies back to the sender. Payload length field is 2 byte long and decides the length of the payload. This implies payload can be anything up to 65536 bytes. As per RFC 6520, if the payload length is bigger than the supported value, then the message should be discarded silently. In this scenario, server should not process the message and send a response. This is not the case with OpenSSL’s implementation which lead to the Heartbleed vulnerability. As a result server sends extra bytes of information which was requested by the attacker. This is the data present in the server’s memory which can be sensitive information.

Q: How does NetScaler help?

A: NetScaler comes to the rescue! NetScaler was never affected by the issue found in OpenSSL implementation. NetScaler can block Heartbleed attacks as the affected versions of OpenSSL (1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1) are not used by NetScaler. NetScaler operating system uses modified SSL stack which is fine tuned for security, performance and other use cases and is not impacted by this vulnerability. On management pane, OpenSSL is used, however the affected versions are not used and thus not affected by Heartbleed vulnerability.

To know more information on the list of Citrix products that requires updates to evade Heartbleed vulnerability please read the support article : http://support.citrix.com/article/CTX140605.

Related:

Sophos XG Firewall: Security Heartbeat registration problems

When registering for Security Heartbeat on the XG to Sophos Central, you may find that it does not appear to get configured and the page shows as it was before trying to register.

This is due to a timeout received when registering, either due to internet issues or high load on the XG at the time.

This article describes the steps to resolve the issue….

The following sections are covered:

Applies to the following Sophos products and versions

Sophos Firewall XG Software

Double check to see the status of the half configured Security Heartbeat on the XG by running command from the Advance Console:

central-register --status

You should receive an output similar to below with a few extra lines but the top line is the important one we are after:

This SFOS instance is currently registered with Sophos Central

If you receive the above status message AND its not showing registered on the web UI, then you have a half registered Security Heartbeat module. To fix this problem, you will need to run the command below:

central-register --unregister

This will remove the registration in the configuration database of the XG.

You can now register Security Heartbeat again and it should be successful.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable to us to ensure that we continually strive to give our customers the best information possible.

Related:

Failed to Connect XenServer on the XenCenter ERROR XenAdmin.Network.Heartbeat

2018-03-06 15:45:55,866 ERROR XenAdmin.Network.Heartbeat [Heartbeat for 172.50.10.24] – System.Net.WebException: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. —> System.IO.IOException: The decryption operation failed, see inner exception. —> System.ComponentModel.Win32Exception: — End of inner exception stack trace —

at System.Net.Security._SslStream.ProcessReadErrorCode(SecurityStatus errorCode, Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest, Byte[] extraBuffer)

at System.Net.Security._SslStream.ProcessFrameBody(Int32 readBytes, Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security._SslStream.StartFrameBody(Int32 readBytes, Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security._SslStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security._SslStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security._SslStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.TlsStream.Read(Byte[] buffer, Int32 offset, Int32 size)

at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)

at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)

— End of inner exception stack trace —

at System.Net.HttpWebRequest.GetResponse()

at CookComputing.XmlRpc.XmlRpcClientProtocol.GetWebResponse(WebRequest request)

at CookComputing.XmlRpc.XmlRpcClientProtocol.Invoke(Object clientObj, MethodInfo mi, Object[] parameters)

at CookComputing.XmlRpc.XmlRpcClientProtocol.Invoke(MethodInfo mi, Object[] Parameters)

at XmlRpcProxyb31fe5d4-3d70-45d4-be5a-e7985b6baf54.host_get_servertime(String session, String _host)

at XenAPI.Host.get_servertime(Session session, String _host)

at XenAdmin.Network.Heartbeat.GetServerTime()

at XenAdmin.Network.Heartbeat.DoHeartbeat()

Related:

  • No Related Posts

Help with a Rule

Hi!

I need help with a rule. I have a Server running different applications, one of which sends a heartbeat message every 15 minutes. We expect 4 messages of those each hour. If we don’t get them, an offense or message, or email should be generated.

Therefore, I created a rule that monitors this specific event. Below are my tests.

100352 when the event(s) were detected by one or more of >LinuxServer @ x.x.x.x –> true
—————————————
100352 when the event QID is one of the following >(44251372) “Heartbeat Message” –> true
—————————————
100352 NOT when at least >4 events are seen with the same >Event Name in >65 >minutes –> true

I tested and it does not work. The last test goes “true”, even though the events keep arriving… maybe I do not understand the “NOT” there. Is there any other better way to design a rule that matches upon absence of a specific event?

Thank you!

Regards,

Bruno

Related:

Re: How do you stop/remove the Heartbeat alert event on OneFS 8.0.0.4?

In OneFS 8.0 and later versions, cluster would generate heartbeat event every day.

The Heartbeat event belongs to Software events category. When configure Alert that uses SMTP channel for Software Events, the SMTP recipients would receive daily email notification for heartbeat event.

Use below step to stop receiving daily heartbeat events:

1. From WebUI, modify Alerts that utilize SMTP channel, and uncheck “Software Events”.

2. Add all software event IDs except for heartbeat manually in CLI

# isi event alerts modify <alertname> –add-eventgroup= “100010043,400020001,400020002,400030001,400030002,400040002,400040005,400040008,400040009,400040010,400040011,400040012,400040013,400040014,400040015,400040016,400040017,400040018,400040019,400040020,400050001,400050002,400050003,400060001,400060002,400060003,400060004,400070004,400070005,400080001,400100001,400100002,400100003,400100004,400100005,400100011,400110001,400120001,400130001,400130002,400140001,400140002,400150001,400150002,400150003,400150004,400150005,400160001,400210001,400210002,499940001,499960001”

3. Send out a test heartbeat event to verify no more email alerts are generated.

# /usr/bin/isi_celog/celog_send_events.py 400050004

KB 490436

How to stop receiving email notification for HeartBeat event

Related:

Liberty collective member does not rejoin after missing heartbeats

We have had several of our servers in our production 16.0.0.4 Liberty environment get “removed” from the collective after missing 3 heartbeats. We see a CWWKX9078I: “server xyz missed 3 heartbeats, attempting deregistration”; this is followed by a CWWKX9077I: “server xyz disconnected from the collective controller”; and finally a CWWKX9076I: “server xyz connected to the collective controller”. After three of these cycles (as far as I can tell) the server in question seems to be removed from dynamicRouting and never rejoins the collective, even if it gets healthy. It stops serving user requests, however we can hit the server directly, bypassing IHS and it will respond. We have not changed the default collective-member XML configuration element, it is using the default heartbeat interval and connection timeouts. I am hoping that I can get some better insight into the heartbeat mechanism of a collective and what rules govern the joining and ejection of members that are perceived as being unhealthy. Thank you in advance.

Related:

IP-based AUTD has detected that the registry value for the minimum heartbeat interval is set to a value that is too low. As a result, we will proceed with the default minimum heartbeat interval of [] seconds and the default maximum heartbeat interval of [] seconds. To avoid seeing this message in the future, please correct this registry value, or omit it entirely in order to use the default.

Details
Product: Exchange
Event ID: 3018
Source: Server ActiveSync
Version: 6.5.7638.0
Component: Microsoft Exchange ActiveSync
Message: IP-based AUTD has detected that the registry value for the minimum heartbeat interval is set to a value that is too low. As a result, we will proceed with the default minimum heartbeat interval of [<number>] seconds and the default maximum heartbeat interval of [<number>] seconds. To avoid seeing this message in the future, please correct this registry value, or omit it entirely in order to use the default.
   
Explanation

Exchange ActiveSync detected that the registry value for the up-to-date notifications minimum heartbeat interval is set too low. This configuration is not valid. The minimum heartbeat interval must be set to a value lower than for the maximum heartbeat interval. Exchange ActiveSync reverted back to the default values for minimum heartbeat interval and maximum heartbeat interval until a valid configuration is set. The default minimum heartbeat interval is 60 seconds. The default maximum heartbeat interval is 2,700 seconds (45 minutes).

   
User Action

Important  This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the “Restore the Registry” Help topic in Regedit.exe or Regedt32.exe.

To edit the registry to resolve this error:

  1. On the computer running Exchange Server, start Regedit.exe.
  2. Open the following registry key:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MasSync\Parameters

    The registry value name for the minimum heartbeat interval is MinHeartbeatInterval.

  3. Do one of the following:

    • To return to the default configuration of 60 seconds, delete the parameter MinHeartbeatInterval.
    • To change the minimum heartbeat interval value, right-click MinHeartbeatInterval, and then click Modify. In Edit DWORD Value, in Value data, type a value between 1 and the value configured for maximum heartbeat interval.
  4. Close Registry Editor.
  5. Restart Internet Information Services (IIS).

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, “Description of the Microsoft Windows Registry” (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

Related:

IP-based AUTD has detected that the registry value for the maximum heartbeat interval is set to a value greater than the maximum allowable value of [] seconds. As a result, we will proceed with the default maximum heartbeat interval of [] seconds and the default minimum heartbeat interval value of [] seconds. To avoid seeing this message in the future, please correct this registry value, or omit it entirely in order to use the default.

Details
Product: Exchange
Event ID: 3017
Source: Server ActiveSync
Version: 6.5.7638.0
Component: Microsoft Exchange ActiveSync
Message: IP-based AUTD has detected that the registry value for the maximum heartbeat interval is set to a value greater than the maximum allowable value of [<number>] seconds. As a result, we will proceed with the default maximum heartbeat interval of [<number>] seconds and the default minimum heartbeat interval value of [<number>] seconds. To avoid seeing this message in the future, please correct this registry value, or omit it entirely in order to use the default.
   
Explanation

Exchange ActiveSync detected that the registry value for the up-to-date notifications maximum heartbeat interval is set to a value higher than the maximum allowable value of 3540 seconds. This configuration is not valid. Exchange ActiveSync reverted back to the default values for maximum heartbeat interval until a valid value is set. The default maximum heartbeat interval is 2,700 seconds (45 minutes).

   
User Action

Important  This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the “Restore the Registry” Help topic in Regedit.exe or Regedt32.exe.

To edit the registry to resolve this error:

  1. On the computer running Exchange Server, start Regedit.exe.
  2. Open the following registry key:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MasSync\Parameters

    The registry value name for the maximum heartbeat interval is MaxHeartbeatInterval.

  3. Do one of the following:

    • To return to the default configuration of 2,700 seconds (45 minutes), delete the parameter MaxHeartbeatInterval.
    • To change the maximum heartbeat interval value, right-click MaxHeartbeatInterval, and then click Modify. In Edit DWORD Value, in Value data, type a value larger than the value specified for minimum heartbeat interval and less than 3541.
    • To add the registry key parameter and specify a value for maximum heartbeat interval, right-click Parameters, point to New, and then click DWORD Value. For the new value name, type MaxHeartbeatInterval. Double-click MaxHeartbeatInterval. In Value data, type an appropriate value for maximum heartbeat interval in seconds. Type a value larger than the value configured for minimum heartbeat interval and less than 3541. The default value for maximum heartbeat interval is 2,700 seconds (45 minutes). Click OK.
  4. Close Registry Editor.
  5. Restart Internet Information Services (IIS).

Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, “Description of the Microsoft Windows Registry” (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).

Related: