• Support
  • Forums
  • Blogs

OTX no information. no longer subscribed

paul_psmithpaul_psmith

Space invader
+14
Not all my OTX alarms, but most of them. 
How do i get rid of this?
OTX just seems useless to me. It is always alerting on stuff that just seems old, or wrong.
I have some alerts that show up that when I follow them back to the OTX website, it says I am not subscribed to that person or alarm. 

Tagged:

Share post:

Best Answer

  • Answer ✓
    Hello @paul_smith, @liudas.alisauskas, @bbanks

       Engineering is currently working on resolving this with 5.5.0. For the time-being, you can attempt to clear the #redis database of the OTX tables, to see if this corrects your issue :: 


    # cd /var/lib/redis/; rm -rf appendonly-otx.aof dump-otx.rdb ; ossim-reconfig; ossim-update --feed

       
       Regards,

    - kratos
    liudas.alisauskas

Answers

  • hi,

    i have the same issue. 
    you have to choose very carefully which otx alarms / user you are subscribe or follow.
    some of them are choosing to much "gray" stuff like dyndns
    i would start step by step like alienvault feeds

    and about your issue 

    i would try to reinstall the otx stuff..it´s help us



  • It's now even worse. I've disabled my OTX subscription, but I am still getting the No Longer subscribed alarms in my Ossim.

    So it seems there is something stuck in the database.

    But no one from Alienvault reads these forums so I guess I'll just have to keep deleting these.
  • @BBanks
    The reinstall of OTX unfortunately is not relevant to me since I am already on 5.4.2, and the article says this was for 5.3.5 and was fixed in 5.4.

    I am still getting the Alerts even though I have disconnected from the OTX subscription.

  • Bumping this again.

    Probably 50-60% of my alerts are this. Very annoying.

    OTX Pulse: No information available. You are no longer subscribed to this pulse.
  • OSSIM 5.5.0 still same error.
  • Agree with liudas. I just updated Friday and still getting all these errors.

    I've tried disabling OTX and I still get these errors. So there is something stuck in the DB it seems to me. I found another post in the forums about cleaning up the DB, but that also did not help me.

    Any help would be appreciated.
  • Looks like I need to do this on all the sensors and the server?
    kratos
  • I've run the above commands per @kratos and I am still getting these Alarms.
  • Hello

    Still getting these as alerts. No updates from Alienvault?
  • Hello. Anyone? Trying to keep this floating to the top of the list.
  • Thank you @kratos for advise!

    1. Removed OTX redis databases in all sensors and reconfigured them:
    # cd /var/lib/redis/; rm -rf appendonly-otx.aof dump-otx.rdb ; ossim-reconfig; ossim-update --feed

    2. Removed faulty pulses from my OTX subscriptions in OTX web page.

    3. Removed key in OSSIM OTX management page and reconnected OTX account again.

    4. Rebooted all sensors.

    Sensors doesn't generate "no-longer-subscribed" security events so far. Sever was already ok (steps 2-3 applied earlier). Not all sensors are updated with OTX feeds yet, but result looks promising.
    kratos
  • Update:

    It looks that on sensors "/var/lib/redis/appendonly-otx.aof" file is not being updated. It could be the answer why IOC's from unsubscribed pulses are not removed from on sensors. Updates does't reach sensors as well.

    Server correctly updates it's appendonly-otx.aof file.

    I don't know OTX update process on sensor side is applied. For now I have just copied "/var/lib/redis/appendonly-otx.aof" file form server to sensors and restarted alienvault-redis-server-otx service on sensors:

    "/etc/init.d/alienvault-redis-server-otx start"
  • I don't have a "/var/lib/redis/appendonly-otx.aof" . Just a "/var/lib/redis/appendonly-otx.aof.backup"

    Odd thing about the backup file is it has a current timestamp. so something is updating it.

    I also don't know that the faulty pulses are in the OTX webpage, since the pulse is not identified in the Ossim events. I did unsubscribe from a lot of pulses, especially ones not from Alienvault. It seemed the pulses can be seriously out of date. I mean, do I really need to get a pulse about an IP address that was malicious two years ago? Unless the IP is still malicious, which seems absurd to me.
  • Also don't have any appendonly-otx.aof file on most of the sensors. One does, but it is 0 bytes and last updated in October.
  • I get these on the redis-server-otx.log file on the sensors.

    2311:S 06 Feb 08:29:12.299 * Connecting to MASTER 10.x.x.x:6380
    2311:S 06 Feb 08:29:12.299 * MASTER <-> SLAVE sync started
    2311:S 06 Feb 08:29:12.299 * Non blocking connect for SYNC fired the event.
    2311:S 06 Feb 08:29:12.300 # Error condition on socket for SYNC: Connection reset by peer
    2311:S 06 Feb 08:29:13.302 * Connecting to MASTER 10.x.x.x:6380
    2311:S 06 Feb 08:29:13.305 * MASTER <-> SLAVE sync started
    2311:S 06 Feb 08:29:13.305 * Non blocking connect for SYNC fired the event.
    2311:S 06 Feb 08:29:13.305 # Error reply to PING from master: '-DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect'

  • So I found that running /etc/init.d/alienvault-redis-server-otx stop stopped one instance of redis-server, but left two others running. One was running on localhost.

    I killed the other two processes and monit restarted redis so I had three instances of redis-server again.

    This created a new appendonly-otx.aof file and it was 0 bytes.

    I ran an ossim-reconfig and this did nothing.
    I then ran ossim-update --feed and then deleted the OTX key from the Web Console.

    Then I went to the OTX website, generated a new key and loaded that onto Ossim and the append-only-otx.aof file started to grow. I also saw subscribed pulses in the console.

    I will try to copy the file out to the sensors and see if that helps them. So far I have not had a No Info/Not Subscribed alarm, but it's only been about 30 minutes.

    Again, no idea why the file is not getting replicated to the sensors.


    kratos
  • Well, I've gotten what looks like updated OTX info, and it seems like the "No longer subscribed" events have stopped. None for the last 3 hours.

    At this point, I have no idea if I am getting OTX anymore. I guess I won't be able to tell unless I get an actual event that matches a pulse?

    I have had some other alarms so I know I'm matching directives.

    Any way to tell if I have current OTX info?
  • @paul_psmith, You could check file integrity with command: 'md5sum /var/lib/redis/appendonly-otx.aof' on server and sensors. Status of file could be checked with command: 'stat /var/lib/redis/appendonly-otx.aof'

    assumption: server's /var/lib/redis/appendonly-otx.aof is updated, if OTX updates reach sensors hashes sould match. In my case, only server's /var/lib/redis/appendonly-otx.aof file is
    updated every 15 minutes. OTX updates doesn't reach sensors. I'm going
    to script automatic deployment of OTX updates from server's DB to
    sensors DB's.

    Multiple instances of redis servise is ok. Only one is responsible for OTX IOC's.
  • edited February 7
    @paul_smith,

       "Well, I've gotten what looks like updated OTX info, and it seems like the "No longer subscribed" events have stopped. None for the last 3 hours.
    At this point, I have no idea if I am getting OTX anymore. I guess I won't be able to tell unless I get an actual event that matches a pulse?
    I have had some other alarms so I know I'm matching directives.
    Any way to tell if I have current OTX info?"

       The easiest way to tell OTX (and Suricata {NIDS}) are running correctly, you can go to any URL found on a pulse you are subscribed to on a desktop that is being monitored. Meaning, if your SPAN port is successfully configured to SPAN that data to the OSSIM//USM, the OSSIM//USM should see it, and trigger an event. Alternatively,  you  can #ssh to the appliance, you can gain command-line access and #jailbreak the system. From there, use #curl or #wget, or what have you. 

       I would then validate that the logs are making it to the '/etc/suricata/eve.json' file. If you do not see that request in that file, that could indicate some misconfiguration with the SPAN, or even some hung process on the OSSIM//USM. 

      Additionally, you would run a #tcpdump on the OSSIM//USM to validate that it is seeing the traffic. 

       Best regards,

    - kratos

Sign In or Register to comment.