Botnet-filter update not working

[jni]

Hello

We have a couple of customers running the Cisco ASA botnet-filter. However the auto updater hasn't been working for a couple of weeks.

Do any of you know anything about the issue or have the same issue?

Symptoms:
- When ever the dynamic-filter updater client tries to auto update the database, it fails. 
- The log shows the following info in regards to this:

May 09 2016 15:06:40 asa : %ASA-6-725001: Starting SSL handshake with server outside:<asa-public-ip>/62899 for TLS session.
May 09 2016 15:06:40 asa : %ASA-6-725006: Device failed SSL handshake with server outside:<asa-public-ip>/62899
May 09 2016 15:06:40 asa : %ASA-3-338310: Failed to update from dynamic filter updater server https://update-manifests.ironport.com, reason: Failed to connect to updater server

- A show command for the dynamic-filter updater client:

sh dynamic-filter updater-client
Dynamic Filter updater client is enabled
Updater server URL is https://update-manifests.ironport.com
Application name: threatcast, version: 1.0
Encrypted UDI: xxxxx
Last update attempted at 10:53:01 CEDT May 11 2016,
with result: Failed to connect to updater server
Next update is in 00:34:07
No database file

Any help would be grately appreciated :o)

[lkskipper]

We too are having this issue with customers running the Botnet filter. Any luck with a solution? 

Dynamic Filter is using downloaded database version '1461783233'
Fetched at 17:00:18 EDT Apr 27 2016, size: 2097152

sh dynamic-filter updater-client
Dynamic Filter updater client is enabled
Updater server URL is https://update-manifests.ironport.com
Application name: threatcast, version: 1.0
Encrypted UDI: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Last update attempted at 17:46:43 EDT May 24 2016,
with result: Failed to connect to updater server
Next update is in 00:59:55
No database file

FWL# dynamic-filter database fetch
ERROR: Dynamic Filter: update failed

We have attempted to disable the dynamic database, purge it, and then re-enable it. However, it continues to fail each fetch attempt. We can ping update-manifests.ironport.com with no issues from the ASA, and have an explicit rule allowing it. DNS lookup is enabled on all interfaces. 

Any assistance is much appreciated!

[jni]

No update. Still not working and no one with a solution.

[saultcollege]

I'm having the exact same issue (for about the same amount of time).  Suddenly updates stopped.   Everything checks out OK DNS, ping  to ironport etc.   I'll be calling TAC soon

[jni]

I would appreciate it if you would post the TAC reply :o)

[saultcollege]

Opened a case 2 days ago, sent show tech, debugs and packet captures...still waiting to hear back.  From what I can tell from the packet caps during a DB fetch command, my ASA is talking to ironport, Certs are being exchanged but no updates happen, no DB is downloaded.

[jni]

Yes, it appears to be some sort of SSL issue. I receive this in the logs when I try to do a dynamic-filter database fetch:

Device failed SSL handshake with server 

[Thomas Born]

The problem seems to be the DHE (Diffie–Hellman key exchange) in cipher suites.

Using

ssl encryption aes256-sha1 aes128-sha1

and therefore leaving out cipher suites with DHE and other older and less secure cipher suites like 3des-sha worked for me.

The problem is still present in version 9.2(4)18

One can reproduce the problem by using

ssl encryption dhe-aes256-sha1 dhe-aes128-sha1 aes256-sha1 aes128-sha1

With

terminal monitor
debug dynamic-filter updater-client
dynamic-filter database fetch

and

show dynamic-filter updater-client
show dynamic-filter data

one can get a better insight into the problem.

[jni]

@Thomas Born: An upgrade to 9.3+ would be best solution, but this is a good workaround for e.g. ASA-5505.

[jni]

Did you ever receive an answer from TAC?

[saultcollege · Accepted solution]

It is a non-public bug and the advice is to upgrade to a version 9.3 or greater.

In the meantime a use-at-your-own-risk work-around involves removing the Diffie-Hellman variants in your encryption:

Such as:

ssl encryption aes128-sha1 aes256-sha1 3des-sha1

[jni]

Thank you for your reply. I will try to upgrade some of the fw. Unfortunately some of the fw are 5505 which can't be upgraded to 9.3+.

In regards to DH, is it everywhere in the config that DH has to be removed e.g. in the crypto ike groups?

[saultcollege · Accepted solution]

In my case my default 'ssl encryption' was

ssl encryption rc4-sha1 dhe-aes128-sha1 dhe-aes256-sha1 aes128-sha1 aes256-sha1 3des-sha1

Using the work-around solved my problem at least initially until I schedule the upgrade mtc. window.  When comparing configurations before and after this does appear to have an effect on crypto ipsec ike.... statements so I'd use with caution, preferably in a test environment

ssl encryption aes128-sha1 aes256-sha1 3des-sha

[Jeppe Schoubye]

My rather old 5505 cannot be upgraded to 9.3 - it doesn't exist.

I tried to upgrade to the latest 9.2(4) interim 13 but same issue.

I then tried to follow the suggestion from saultcollege and configured:

ssl encryption aes128-sha1 aes256-sha1 3des-sha

This fixed the issue for me - however still only a workaround.

Thanks :-)

[Hassan Chalabi]

did you get an answer from TAC? I have the exact same issue, and I dont want to enable this ssl encryption, does upgrading to 9.3 will solve it? I have 9.1

thank you.