Messages

Confirmed on:
OPNsense 26.72os-nginx 1.36_3S

Applied:
opnsense-patch 14710e775

Patch applied successfully and immediately resolved:
Services → Nginx → Configuration = page load failure

No additional configuration changes required.

I had the same issue today. I started by looking for the string, in all files under the / directory. They were found only in the /conf directory.
You might need to delete the upstream and the configured upstream server UUID lines (I did). Be sure to copy the strings in the errors for both, to use later in the terminal.

Stop DHCP, DNS and, Nginx services (might have to disable Nginx temporarily, to stop it's service) in the WebUI. Otherwise they may write back your edits (that you will need to make, below) into the file, on reboot.

SSH into the device...

Try:

sudo grep -E -w -R "5dbfd85e-f1aa-43ca-bfa2-313a684a199c" /conf/

Edit the files listed by the above command:
sudo vi /conf/config.xml
sudo vi /conf/config-e.xml (I had it in here too and a couple of backups - I left the backups alone.)

In vi use / to find the 5dbfd85e-f1aa-43ca-bfa2-313a684a199c line(s) IE: /5dbfd85e-f1aa-43ca-bfa2-313a684a199c [enter] and [n] to go to the next instance. Use [dd] to delete those lines. Delete all the lines that go with those configured UUIDs (Servers) - but be careful to not delete any others.

Save each file with :x (save and exit file in vi) after your edits.

Now go back to the WebUI and Power --> Reboot

You can SSH back in after the reboot to check the files, to make sure the lines are still gone.

You might still have the Upstream and/or Upstream Server listed in the Nginx WebUI - but you should be able to delete them now... forever.

Good Times! Enjoy.

I'm a noob - but I think I can help.
( If not, my possibly wrong answer, will probably annoy someone that's not a noob, enough to fix my reply! )

Since it's been altered on LAN - it's been allowed through the firewall already.
Since you didn't mention any other alerts, it (the remote IP) was probably not hacking it's way through to your LAN. Assuming you have alerts setup for those attempts.
That tells me you, you've invited this connection.

Since this IP that was altered on was connecting to your torrent VM - that seems like a possible match for "Low Reputation" alert. Torrents, torrent traffic and the IPs that use them, tend to have "low" reputations in the security world.

It seem given all the above - that an IP connected to your Transmission app in order to peer a torrent from you. At lease that seems the most likely situation to me. Do you have connection history in that app? Do you see that IP address in that history? Are they connected now?
They could be a sneaky hacker... but I'd think your server/firewall/etc. logs would show more.
Do you have Fail-to-Ban installed?
Is the VM all alone on it's own VLAN, with just that service running - since it's open to the internet directly?

... well that got formatted!  :'(

[This means what exactly?]

This means what exactly?
- I'm new.
- The following clarifications are confusing to me
- I'm at the "Pick the Rule-Sets you want" part of my first setup


Attack Response–This category is for signatures to identify responses indicative of intrusion, results of a successful attack, and scripts (including common obfuscation methods) commonly used in the delivery of malware or other malicious payloads.

  1." identify responses indicative of intrusion"
        What sort of "responses" would that be? Would I alert on, or drop the "responses"?
   2."identify results of a successful attack"
        So alert or drop the results? Both seem like strange options. If it knows an attack was successful, why didn't it block it first, so the attack failed instead?
   3. "identify scripts (including common obfuscation methods) commonly used in the delivery of malware or other malicious payloads"
        - Does this drop scripts?
        - Which scripts? "commonly used" is rather open and would match almost any script, right? Malware and "other" malicious payloads are usually installed/delivered in the same fashion of Legitimateware and "not" malicious payloads.
        - How do these rules differentiate between the two?



Botcc Portgrouped–This category is for signatures like those in the Botcc category but grouped by destination port. Rules grouped by port can offer higher fidelity than those not grouped by port.

      - So this is a list of random ports?
      -  Why not add the ports to Botcc rulesets by default if it offers "higher fidelity"?



Current Events–This category is for signatures with rules developed in response to active and short-lived campaigns and high-profile items that are expected to be temporary. One example is fraud campaigns related to disasters. The rules in this category are ones that are not intended to be kept in in the ruleset for long, or that need to be further tested before they are considered for inclusion. Most often these will be simple sigs for the Storm binary URL of the day, sigs to catch CLSID's of newly found vulnerable apps where we don't have any detail on the exploit, etc.

    "The rules in this category are ones that are not intended to be kept in in the ruleset for long"
        - So do they update themselves and remove the no longer needed rules?
        - Define "for long", how long exactly is that?
        - Am I supposed to delete this ruleset and re-install it every few days?

    "rules developed in response to active and short-lived campaigns and high-profile items that are expected to be temporary."
        - Isn't the ET/Open list 30days old?

    "need to be further tested before they are considered for inclusion"
       - Shouldn't this ruleset be in the "testing" list then?



Deleted–This category is for signatures removed from the rule set. Note that typically rules are retained in a deactivated state within their respective rule files (starting with a #) but some rules that are duplicates, moved from Pro to Open (and thus need a new SID for the Open rule) or are too problematic to retain are moved to the Deleted category.

    - Then delete them? Why have a list of no longer included signatures at all?



Exploit-Kit–This category is for signatures to detect activity related to Exploit Kits, their infrastructure (including TDS domains), and delivery.

    - "related to" how?
    - Which "activity"?
    - Do I just alert on this "activity"?



Games–This category is for signatures that identify of gaming traffic and attacks against those games. These rules cover games such as World of Warcraft, Starcraft, and other popular online games. While these games and their traffic are not malicious, they are often unwanted and prohibited by policy on corporate networks.

    - I like games and I don't want them attacked. So do I drop the Games rules packets?
    - How do the rules differentiate between "gaming traffic" vs "attacks against those games"? I don't want to hamper "gaming traffic" or be attacked!



Hunting–This category is for signatures that provide indicators that when matched with other signatures can be very useful for threat hunting in an environment. These rules can provide false positives on legitimate traffic and inhibit performance. They are only recommended for use when actively researching potential threats in the environment.

    "They are only recommended for use when actively researching potential threats in the environment."
       - Is that not the whole idea of IDS/IPS, to be constantly "researching"/hunting for potential threats?
    "These rules can provide false positives on legitimate traffic and inhibit performance."
       - That doesn't seem very useful...
    "This category is for signatures that provide indicators that when matched with other signatures can be very useful for threat hunting in an environment. "
       - How would the signatures, that when matched with other signatures, be used?
       - This comma --→ , ←-- is begging to be used. That comma has friends ,,,,,,, ←--



ICMP_info–[/b]This category is for signatures related to ICMP protocol specific events, typically associated with normal operations for logging purposes.

     - Why is this here then?



Info–This category is for signatures to help provide audit level events that are useful for correlation and identifying interesting activity which may not be inherently malicious but is often observed in malware and other threats, for example downloading an Executable over HTTP by IP address rather than domain name.

    - How would my IPS use this "Info" as a ruleset? I need info on "Info".



Misc.–This category is for signatures not covered in other categories.

    -  ...
    - Seriously!?
    - What am I supposed to do with that? "Oh no, I'm being attacked by "Misc"!" "Quick do the "Thing"!" "Alert the "Noun"!"



Policy–This category is for signatures that may indicate violations to an organization's policy. This can include protocols prone to abuse, and other application-level transactions which may be of interest.

     - My organization is a home. Does my organization care about the abused protocols?
     - How interesting are the "application-level transactions"?
     - What are the "application-level transactions"?
     - What would my organization do with these violations?
     - Can I drop them, or since they are "application-level transactions", have they already happened?



SCADA_special–This category is for signatures written for Snort Digital Bond based SCADA preprocessor.

     - Super! What do I do with them?
     - What are they?
     - If I had a "Snort Digital Bond based SCADA preprocessor" would I know it?
     - Are Snort Digital Bond based SCADA preprocessors on sale on Black Friday?
     - Do I plug my new Snort Digital Bond based SCADA preprocessor into USB?



Thanks for any help you can offer!