Threat Intelligence Feed Sync Failure Fix

You're running a MISP instance or pulling feeds from AlienVault OTX, and suddenly the sync stops. Maybe you see "Connection timed out" or "401 Unauthorized" in the logs. This usually happens after an update, a certificate change, or when you switch networks. I've seen this with MISP 2.4.154 and OTX API v2. The feed just sits there, hours old, and your IDS or SIEM stops getting fresh indicators.

Root Cause

The most common reason is that the API key expired or the SSL certificate chain broke. But here's what people miss: some threat feeds use different URLs for staging vs production. If you copied a feed URL from a blog post, it might point to a test server that doesn't exist anymore. Other times, proxy settings in your threat intel platform get corrupted after an OS patch.

Another hidden cause: the feed server's TLS version changed. Many platforms now require TLS 1.2 or higher. If your system is stuck on TLS 1.0 (like some old CentOS 7 installs), the handshake fails silently.

Step-by-Step Fix

Step 1: Check the API Key

Log in to your threat feed provider. For AlienVault OTX, go to Settings > API.
Copy the full API key. It should be 40 characters long. If it has spaces or line breaks, you copied it wrong.
In your MISP interface, go to Sync Actions > List Feeds.
Click the edit icon on the failing feed.
Paste the API key again. Hit Save.
Expected: You'll see "Feed updated" in green. Wait 5 minutes and check if the feed fetches data.

Step 2: Test the Feed URL Manually

Open a terminal on the MISP server.

Run this command, replacing the URL with your feed's address:

curl -v --connect-timeout 10 "https://otx.alienvault.com/api/v1/indicators/export"

Look at the output. You want to see HTTP/2 200 or HTTP/1.1 200 OK.
If you get curl: (35) SSL connection error, the server doesn't like your TLS version. Add --tlsv1.2 to the curl command and try again.
```
curl -v --tlsv1.2 "https://otx.alienvault.com/api/v1/indicators/export"
```
Expected: A JSON response with indicator data. If you see HTML, the URL is wrong.

Step 3: Clear the Proxy Settings (If You Have One)

On your MISP server, check the environment variables:
```
echo $HTTP_PROXY
echo $HTTPS_PROXY
```
If either is set, you must make sure the proxy is running and allows traffic to the feed domain.
To temporarily bypass the proxy for testing:
```
unset HTTP_PROXY
unset HTTPS_PROXY
```
Then restart the MISP worker:
```
sudo systemctl restart misp-workers
```
Expected: The next sync attempt should happen within the configured interval (usually 5-15 minutes). Check the log at /var/www/MISP/app/tmp/logs/feed-sync.log.

Step 4: Reset the Feed State

In MISP, go to Sync Actions > List Feeds.
Click Fetch all feeds on the top right.
Wait 2 minutes. If you see "No changes" but the feed still shows old data, the feed's cache is stuck.
SSH into the server and run:
```
sudo -u www-data /var/www/MISP/app/Console/cake feed fetch [feed_id]
```
Replace [feed_id] with the actual feed ID from the URL in your browser (e.g., feed_id=12).
Expected: A full sync log. If you get a PHP memory error, increase memory_limit in /etc/php/7.4/apache2/php.ini to 512MB, then restart Apache.

Step 5: Update the Feed Pull Script (For Custom Feeds)

If you wrote a custom script to pull STIX feeds, check the file permissions:
```
ls -la /var/www/MISP/app/files/feed-metadata
```

Make sure the www-data user owns the files. If not, run:

sudo chown -R www-data:www-data /var/www/MISP/app/files/feed-metadata

Also check the script's Python version. I've seen scripts break after a Python 3.6 to 3.8 upgrade because urllib changed.

What to Check If It Still Fails

Sometimes the problem is on the provider's side. Check their status page. For AlienVault OTX, go to otx.alienvault.com/status. For public MISP feeds, check the CIRCL feed status.

If the server is fine but sync still fails, look at the firewall logs on your MISP server. Some threat feeds use non-standard ports (like 8443 for TAXII). Run a port scan from your server:

nc -zv feed-provider.com 8443

Replace the port with whatever the feed uses.

Last thing: check the system clock. If your server's time is off by more than 5 minutes, TLS certificates will fail validation. Run timedatectl status. If it shows wrong time, install NTP:

sudo apt install ntp
sudo systemctl enable ntp
sudo systemctl restart ntp

After all that, if the feed still won't sync, open a ticket with your provider. But 9 times out of 10, it's a bad API key or a mismatched TLS version.