Tag Archives: InfoSec

Installing DFIR-IRIS on FreeBSD using Jails

This is a live blogging of the installation process of DFIR-IRIS on FreeBSD 14.0-RELEASE using Jails and Jailer.

The main requirements are:

  • Nginx
  • PostgreSQL
  • Python
  • Some random dependencies we saw in the Dockerfile

I assume you already have nginx up and running, we will just be setting up a vhost under the domain name dfir.cert.am. Don’t worry, this is INSIDE our infrastructure, you will not be able to connect to it 🙂

Initial Setup

First we create a jail named iris0, using Jailer:

jailer create iris0

Next we install the required software inside of the jail. Looks like everything is available in FreeBSD packages:

jailer console iris0
pkg install \ nginx \ python39 \ py39-pip \ gnupg \ 7-zip \ rsync \ postgresql12-client \ git-tiny \ libxslt \ rust \ acme.sh

Installing DFIR-IRIS

Since we’re using FreeBSD, we’ll be doing things the right way instead of the Docker way, so we will be running IRIS as a user, not as root.

pw user add iris -m

Next we setup some directories and checkout the repo

root@iris0:~ # pw user add iris -m
root@iris0:~ # su - iris iris@iris0:~ $ git clone --branch v2.4.7 https://github.com/dfir-iris/iris-web.git iris-web

Finally, we install some python dependencies using pip.

iris@iris0:~ $ cd iris-web/source
iris@iris0:~/iris-web/source $ pip install -r requirements.txt

Now we have to configure the .env file based on our needs, I will post my version of it, I hope it helps

export POSTGRES_USER=postgres
export POSTGRES_PASSWORD=postgres
export POSTGRES_DB=iris_db
export POSTGRES_ADMIN_PASSWORD=longpassword

export POSTGRES_SERVER=localhost
export POSTGRES_PORT=5432

# -- IRIS
export IRIS_SECRET_KEY=verylongsecret
export IRIS_UPSTREAM_SERVER=app # these are for docker, you can ignore

export CELERY_BROKER=amqp://localhost
# Set to your rabbitmq instance

# Change these as you need them.
# -- AUTH
## optional
# requests the just-in-time creation of users with ldap authentification (see https://github.com/dfir-iris/iris-web/issues/203)
# the group to which newly created users are initially added, default value is Analysts


Configuring HTTPS

We can use acme.sh to issue a TLS certificate from Lets Encrypt.

root@iris0:~ # acme.sh --set-default-ca --server letsencrypt
root@iris0:~ # acme.sh --issue -d dfir.cert.am --standalone
root@iris0:~ # acme.sh -i -d dfir.cert.am --fullchain-file /usr/local/etc/ssl/dfir.cert.am/fullchain.pem --key-file /usr/local/etc/ssl/dfir.cert.am/key.pem --reloadcmd 'service nginx reload'

Setup nginx

DFIR-IRIS provides a nginx configuration template at nginx.conf, we will be using that, with a little bit of modifications.

The final nginx.conf will look like this:

#user  nobody;
worker_processes  1;

# This default error log path is compiled-in to make sure configuration parsing
# errors are logged somewhere, especially during unattended boot when stderr
# isn't normally logged anywhere. This path will be touched on every nginx
# start regardless of error log location configured here. See
# https://trac.nginx.org/nginx/ticket/147 for more info. 
#error_log  /var/log/nginx/error.log;

#pid        logs/nginx.pid;

events {
    worker_connections  1024;

http {
    include       mime.types;
    default_type  application/octet-stream;

    # Things needed/recommended by DFIR-IRIS
    map $request_uri $csp_header {
        default "default-src 'self' https://analytics.dfir-iris.org; script-src 'self' 'unsafe-inline' https://analytics.dfir-iris.org; style-src 'self' 'unsafe-inline';";

    server_tokens off;
    sendfile    on;
    tcp_nopush  on;
    tcp_nodelay on;

    types_hash_max_size             2048;
    types_hash_bucket_size          128;
    proxy_headers_hash_max_size     2048;
    proxy_headers_hash_bucket_size  128;
    proxy_buffering                 on;
    proxy_buffers                   8 16k;
    proxy_buffer_size               4k;

    client_header_buffer_size   2k;
    large_client_header_buffers 8 64k;
    client_body_buffer_size     64k;
    client_max_body_size        100M;

    reset_timedout_connection   on;
    keepalive_timeout           90s;
    client_body_timeout         90s;
    send_timeout                90s;
    client_header_timeout       90s;
    fastcgi_read_timeout        90s;
    proxy_read_timeout          90s;
    uwsgi_read_timeout          90s;

    gzip off;
    gzip_disable "MSIE [1-6]\.";

    proxy_set_header    HOST                $http_host;
    proxy_set_header    X-Forwarded-Proto   $scheme;
    proxy_set_header    X-Real-IP           $remote_addr;
    proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;

    add_header          Last-Modified $date_gmt;
    add_header          'Cache-Control' 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
    if_modified_since   off;
    expires             off;
    etag                off;
    proxy_no_cache      1;
    proxy_cache_bypass  1;

    ssl_protocols               TLSv1.2 TLSv1.3;

    ssl_prefer_server_ciphers   on;
    ssl_certificate             /usr/local/etc/ssl/dfir.cert.am/fullchain.pem;
    ssl_certificate_key         /usr/local/etc/ssl/dfir.cert.am/key.pem;
    ssl_ecdh_curve              secp521r1:secp384r1:prime256v1;
    ssl_buffer_size             4k;

    ssl_session_tickets         off;
    ssl_session_cache           none;
    server {
        listen          443 ssl
        server_name     dfir.cert.am;
        root            /www/data;
        index           index.html;
        error_page      500 502 503 504  /50x.html;

        add_header Content-Security-Policy $csp_header;
        add_header X-XSS-Protection             "1; mode=block";
        add_header X-Frame-Options              DENY;
        add_header X-Content-Type-Options       nosniff;
        # max-age = 31536000s = 1 year
        add_header Strict-Transport-Security    "max-age=31536000: includeSubDomains" always;
        add_header Front-End-Https              on;

        location / {
            proxy_pass  http://localhost:8000;

            location ~ ^/(manage/templates/add|manage/cases/upload_files) {
                keepalive_timeout           10m;
                client_body_timeout         10m;
                send_timeout                10m;
                proxy_read_timeout          10m;
                client_max_body_size        0M;
                proxy_request_buffering off;
                proxy_pass  http://localhost:8000;

            location ~ ^/(datastore/file/add|datastore/file/add-interactive) {
                keepalive_timeout           10m;
                client_body_timeout         10m;
                send_timeout                10m;
                proxy_read_timeout          10m;
                client_max_body_size        0M;
                proxy_request_buffering off;
                proxy_pass  http://localhost:8000;
        location /socket.io {
            proxy_set_header Host $http_host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_http_version 1.1;
            proxy_buffering off;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";
            proxy_pass http://localhost:8000/socket.io;

Setup PostgreSQL

I assume you know how to do this 🙂 You don’t need to configure a separate user, by the looks of it, IRIS likes to do that itself. Thanks to Jails I was able to run a separate PostgreSQL instance in the iris0 jail.

P.S. If you are running PostgreSQL inside a jail, make sure that the following variables are set in your jail configuration

  sysvshm         = new;
  sysvmsg         = new;


Now that everything is up and running, we just need to run DFIR-IRIS and it will create the database, needed users, an administration account, etc.

su - iris
cd ~/iris-web/source
. ../.env
~/.local/bin/gunicorn app:app --worker-class eventlet --bind --timeout 180 --worker-connections 1000 --log-level=debug

Assuming everything is fine, now we can setup a rc.d service script to make sure it runs at boot.

For that I wrote two files, the service itself and a helper start.sh script

rc.d script at /usr/local/etc/rc.d/iris


# PROVIDE: iris

. /etc/rc.subr

load_rc_config ${name}

: ${iris_enable:=no}
: ${iris_path:="/usr/local/iris"}
: ${iris_gunicorn:="/usr/local/bin/gunicorn"}
: ${iris_env="iris_gunicorn=${iris_gunicorn}"}



command_args="-P ${pidfile} -T ${name} -o ${logfile} ${iris_command}"

run_rc_command "$1"

and the helper script at /home/iris/iris-web/start.sh


export HOME=$(getent passwd `whoami` | cut -d : -f 6)

. ../.env

${iris_gunicorn} app:app --worker-class eventlet --bind --timeout 180 --worker-connections 128

now we set some variables in rc.conf using sysrc and we can start the service.

sysrc iris_enable="YES"
sysrc iris_path="/home/iris/iris-web"
sysrc iris_gunicorn="/home/iris/.local/bin/gunicorn"

Finally, we can start DFIR-IRIS as a service.

service iris start

Aaaaand we’re done 🙂

Thank you for reading!

There are some issues that I’d like to tackle, for example, service iris stop doesn’t work, and it would be nice if we ported all of the dependencies into Ports, but for now, this seems to be working fine.

Special thanks to the DFIR-IRIS team for creating this cool platform!

That’s all folks…

Reply via email.

Reply from National Vulnerability Database Team regarding Legacy Data Feeds

Couple of days ago when I was assisting a customer, I recommended that they follow the National Institute of Standards and Technology’s (a.k.a. NIST) Information Technology Laboratory’s Computer Security Division’s National Vulnerability Database’s (a.k.a. NVD a.k.a. that place that publishes the CVEs) data feeds. (Apologies for the bad intro)

So, these are RSS feeds that “contains the most recent CVE cyber vulnerabilities published within the NVD”

Unfortunately, I saw a notice at the top of the page, which got me really worried. It says

In September 2023, the NVD plans to retire all legacy data feeds while guiding any remaining data feed users to updated application-programming interfaces (APIs).

Usually, I’d panic and start ranting on my blog, but this is the NVD we’re talking about. They are a US government project that has been doing a lot of good and they are sponsored by the CISA, an agency that does many good things not just for US citizens, but citizens of our planet.

I started digging to understand what exactly is going to be retired and most importantly, why?

The NVD has made an amazing change timeline that has the following

The NVD plans to retire the RSS data feeds. The NVD plans to enable reCAPTCHA across all webpages and to retire webpages intended to support web scraping (e.g., Full Listings) before its APIs existed.

Okay, NOW I’m worried.

I’ll break this into two parts.

Why we need RSS feeds

You see, the internet relies on RSS, and I’m not just saying that because most of my audience uses RSS daily. The reason is much deeper than that.

As Dave Winer blogged a month ago

RSS is a thing like roadways and paths of rivers, they change very slowly. Think about qwerty keyboards. That’s what we’re talking about here. Agreements between products to interop. RSS is just like the gauge of rails, or always driving on one side of the street. A convention that makes progress possible. #

Scripting.com, Saturday, January 28, 2023

There are three products/protocols that I use daily, it’s Slack (for work), XMPP (for friends and family) and Telegram (for Armenian tech communities).

There are specific things that I should deliver for all these and that is messages, alerts, notices.

For my work, I should be able to get news if there’s a security issue on FreeBSD, because we use that. For friends and family I should deliver notices if there are any issues or upcoming maintenance to our servers. For my telegram communities I should update them if we’re having any new meetups, events, podcasts.

But, instead of writing a software that fetches, parses, analyzes and does something-something to these messages, I use RSS! FreeBSD has an RSS feed for Security Advisories. All I do in Slack is /feed subscribe https://www.freebsd.org/security/feed.xml and now, every time there an SA for FreeBSD, I get notified in Slack.

For friends and family? I have Huginn agent that parses RSS and send an XMPP message. For Armenian tech communities? I read a website’s RSS and a bot posts it in a group.

You get the idea.

RSS is all about “things working together”, there is no need to write a specific piece of for that specific thing.

And for years, I’ve relied on NVD’s RSS data feed to notify customers, tell them what to upgrade, if they need to upgrade and why to upgrade.

These RSS feeds are part of my professional life, a way for me, and people like me to know if we should be in panic mode or not.


Okay, now what?

I believe in communication. I was very sure that my questions will be answered by the NVD, so I sent a message!

Greetings dear NVD team, NIST team and Computer Security Division,

While browsing your website, I have noticed the following change:

> In September 2023, the NVD plans to retire all legacy data feeds and the 1.0 APIs.

This became very disturbing, as many companies (including mine) rely on the data feed provided by NIST’s NVD.

I have two questions:
1) Is there *any* chance to keep the RSS feeds?
2) Is it okay if others (i.e. I) generate an RSS feed from your new API, if your final decision for q#1 is no?

[ . . . ]

If I may, that being said, I’m sure there’s a good reason, so my other question is:
What are/were the technical issues with RSS? Could it be bypassed or hacked around?

Thank you for all the work that you do, and thank in advance.

Kind regards,

I was right! They did answer all of my questions! I got a reply yesterday, here it is.

1) Is there *any* chance to keep the RSS feeds?

We have no plans to continue providing the RSS feeds located at

Additionally, it is important to point out that per our announcement at https://nvd.nist.gov/general/news/change-timeline, the RSS feeds will be retired in March, not September. If you were not aware of these announcements we highly advice joining the NVD Google Group to stay better informed (https://groups.google.com/a/list.nist.gov/g/nvd-news).

2) Is it okay if others (i.e. I) generate an RSS feed from your new API, if your final decision for q#1 is no?

All NIST publications are available in the public domain. Organizations seeking to automate the retrieval of NVD data should use the NVD’s Application Programing Interfaces (APIs).
Services which utilize or access the NVD are asked to display the following notice prominently within the application: “This product uses data from the NVD API but is not endorsed or certified by the NVD.” You may use the NVD name to identify the source of the data. You may not use the NVD name, to imply endorsement of any product, service, or entity, not-for-profit, commercial or otherwise. For information on how to the cite the NVD, including the database’s Digital Object Identifier (DOI), please consult NIST’s Public Data Repository.

3) What are/were the technical issues with RSS? Could it be bypassed or hacked around?

The RSS feeds were considered to be overly simplistic and underutilized, they were determined in scope of retirement for these reasons as part of a larger effort to consolidate our output formats as we move towards the APIs. If you would like to submit a user story explaining the benefits and needs that the APIs currently do not meet we would pass that along to the development team for consideration in the future.

Okay. I agree! RSS is very simplistic, but that’s the point! it’s supposed to be simple. I mean, it’s simple enough that podcasts are RSS feeds.

And to be clear, I DID check the NVD’s new Vulnerabilities API, it’s awesome, it’s nice, it’s documented very well, kudos to the team, they did an amazing work, I’m sure it wasn’t easy. It has, for sure, more features than RSS could provide.

What to do about it?

I understand that the NVD is pushing the REST API, and I also understand why. But I really don’t want to write a “wrapper” for every service and technology that I use.

Here are my two questions.

  1. Will systems break because of this? Are you using these feeds? Do you rely on them for yourself or your organization?
  2. Will there be an interest by the InfoSec community to write a wrapper that generates a new RSS feed from NVDs new API?

Personally, if there’s an interest or not, I will be stopping everything I’m working on to create this NVD-to-RSS generator, as I very much rely on it. It will be open-source, obviously. What I should build is a drop-in replacement, where you change the feed URL, and everything works like before. (Well, I have to finish my other open-source commitments first, then I should work on this 😀 hopefully it wont take long.)

I would like to thank the NVD for keeping these feeds for all these years and congratulate them for their new APIs, I’m sure many good things will come out of these APIs.

And thank you for reading 🙂

That’s all folks…

Reply via email.