Bug #7255
openCannot run suricata-update on a FIPS compliant server
Description
Due to using md5, you cannot run `suricata-update` on a FIPS enabled server.
I saw this ticket about this: https://redmine.openinfosecfoundation.org/issues/4479
But that is for CentOS and I am having this isssue on RHEL 8/9 and Ubuntu.
That ticket is from 3 years ago.
The potential workaround does not work.
I attempted to use my own hack as we cannot use md5, so I replaced it with sha256.
```
sudo sed -i 's/hashlib.md5/hashlib.sha256/' /usr/lib/suricata/python/suricata/update/main.py
```
This seems to work for me but I am unsure if this causes other issues.
I also had to add trust for fapolicyd:
```
sudo fapolicyd-cli --file add /usr/bin/suricata --trust-file suricata
sudo fapolicyd-cli --file add /usr/libexec/suricata --trust-file suricata
sudo fapolicyd-cli --file add /var/log/suricata --trust-file suricata
sudo systemctl restart fapolicyd
```
And fix the log permissions:
```
sudo chown -R suricata:suricata /var/log/suricata
```
Now `sudo suricata-update` works as expected.
These were the other updates I made to the system:
```
NIC=$(ip route show default | awk '/default/ {print $5}')
sudo sed i 's/community-id: false/community-id: true/' /etc/suricata/suricata.yaml rule-reload: true" | sudo tee -a /etc/suricata/suricata.yaml
sudo sed -i "s/interface: .*/interface: $NIC/" /etc/suricata/suricata.yaml
sudo sed -i 's/#force-hash: .*/force-hash: [sha256]/' /etc/suricata/suricata.yaml
echo -e "\ndetect-engine:\n
```
Updated by Jeremy Simkins 6 months ago
Due to using md5, you cannot run `suricata-update` on a FIPS enabled server.
I saw this ticket about this: https://redmine.openinfosecfoundation.org/issues/4479
But that is for CentOS and I am having this isssue on RHEL 8/9 and Ubuntu.
That ticket is from 3 years ago.
The potential workaround does not work.
I attempted to use my own hack as we cannot use md5, so I replaced it with sha256.
sudo sed -i 's/hashlib.md5/hashlib.sha256/' /usr/lib/suricata/python/suricata/update/main.py
This seems to work for me but I am unsure if this causes other issues.
I also had to add trust for fapolicyd:
sudo fapolicyd-cli --file add /usr/bin/suricata --trust-file suricata
sudo fapolicyd-cli --file add /usr/libexec/suricata --trust-file suricata
sudo fapolicyd-cli --file add /var/log/suricata --trust-file suricata
sudo systemctl restart fapolicyd
And fix the log permissions:
sudo chown -R suricata:suricata /var/log/suricata
Now `sudo suricata-update` works as expected.
These were the other updates I made to the system:
NIC=$(ip route show default | awk '/default/ {print $5}')
sudo sed -i 's/community-id: false/community-id: true/' /etc/suricata/suricata.yaml
sudo sed -i "s/interface: .*/interface: $NIC/" /etc/suricata/suricata.yaml
sudo sed -i 's/#force-hash: .*/force-hash: [sha256]/' /etc/suricata/suricata.yaml
echo -e "\ndetect-engine:\n- rule-reload: true" | sudo tee -a /etc/suricata/suricata.yaml
Updated by Jeremy Simkins 8 days ago
This no longer works due to the latest update which was supposed to add better fips support. Now we have to find a new solution as this change will no longer work. Still haven't been able to get this to work at all with fips on Suricata 7.0.9
Updated by Jeremy Simkins 7 days ago ยท Edited
Jason Ish wrote in #note-3:
Can you please show us the error you get when you run default
suricata-update
? Does adding-f
help at all?
To explain the issue I ran into:
We have Python 3.6.8 installed. I attempted to update to 3.12 but when I installed this package, it forced 3.6.8 to be used (re-installed it as a dependency).
The issue appears to be with the version check for the `hashlib.md5` command. Since I am using 3.6.8, it was not getting the `usedforsecurity` flag.
To resolve our issue, I ended up just adding the `usedforsecurity` flag to the first command.
```
sed -i -E 's/(hashlib\.md5\(buf)(\))/\1, usedforsecurity=False\2/' /usr/lib/suricata/python/suricata/update/util.py
```
Now this works as expected.
I did run into another issue with the update doing a test run in the `/tmp` directory which has noexec on it and this causes it to hang indefinitely (in EC2 image builder). Tossing a `--no-test` on that solved that issue.
I am now able to use this as expected.
Ideally, I would have liked to use python 3.12 but for some reason it is forcing us to keep 3.6.8 when installing this.
This is installed using:
```
sudo dnf install --nogpgcheck -y https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/h/hiredis-0.13.3-13.el8.x86_64.rpm
sudo dnf install --nogpgcheck -y https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/h/hyperscan-5.3.0-5.el8.x86_64.rpm
sudo dnf copr enable @oisf/suricata-7.0 -y
sudo dnf install --nogpgcheck suricata -y
```
Hope this explains the issue we had.
Good news, I was able to get this to work still but doing the hack is not ideal. When I get more time I was planning to look into why the python 3.6.8 is being forced as a dependency but I haven't had a chance to dig into that yet.
Updated by Jason Ish 7 days ago
The check was like this as Python 3.6.8 didn't have usedforsecurity
when tested. Nor does stock 3.6.15, but it appears its backported in some distributions? What I'll have to do is wrap it in an exception so we can attempt it regardless of version, which should fix this issue for you. For example, the Redhat UBI8 images don't have this feature in their Python 3.6.15 either.
As for the version of Python, the RPM depends on python3
like the EPEL maintained one, which does appear to be Python 3.6 on EL 8. I don't think deviating from EPEL is something we want to do at this point.