Dear all, I had installed opnsense quite long time ago but recently my LAN cannot browse internet. Most probably my ISP has hacked my router. (Dont' argue this).
Im looking method to harden my OPNSense router. Please suggest. Thanks.
Harden OPNSense Methods:
1. Disable SSH services
2. Disable root user in web gui option
3. WiFI based on MAC Address only
4. Installed Suricata IPS
5. Disable boot into single user mode to prevent hacker change password
6. How to enable sudo?
Quote from: peterwkc on November 27, 2024, 09:23:29 AM
Most probably my ISP has hacked my router. (Dont' argue this).
Ridiculous assumption but you do you.
Quote from: peterwkc on November 27, 2024, 09:23:29 AM
1. Disable SSH services
Disabled by default.
Quote from: peterwkc on November 27, 2024, 09:23:29 AM
2. Disable root user in web gui option
You need at least one user with full administrative access. As long as you have that, of course you can disable the root login.
Quote from: peterwkc on November 27, 2024, 09:23:29 AM
3. WiFI based on MAC Address only
Must be implemented at your access point and I fail to see how this would protect against threats from the outside like your ISP.
Quote from: peterwkc on November 27, 2024, 09:23:29 AM
4. Installed Suricata IPS
No idea, I do not believe in IPS.
Quote from: peterwkc on November 27, 2024, 09:23:29 AM
5. Disable boot into single user mode to prevent hacker change password
Needs physcial access to the box. If that is the case the "hacker" can always boot from an external boot medium.
Best encrypt your hard disk - I told you how to do that in your other thread.
Downside: OPNsense won't boot after an update or a power failure unless you enter the GELI password at the console.
Quote from: peterwkc on November 27, 2024, 09:23:29 AM
6. How to enable sudo?
System > Settings > Administration > Authentication > Sudo
HTH,
Patrick
Basically, IFF that happened, then it was one of these problems, in descending order of likelihood:
1. You exposed SSH and/or the web UI to WAN and your password was easily guessable. If you must do this at all, you should enable 2FA to prevent it or protect access by a VPN.
2. One of your SSH keys could be accessed by the ISP, e.g. because you also stored it on a hosted server there or in an unencrypted backup.
3. OpnSense has a vulnerability in the web UI that can be used to bypass the usual authentication.
I am not arguing that your box was not hacked, but either way:
a. I would doubt that it was your ISP that did it.
b. Your proposed measures would do little to nothing to prevent that from happening in the future.
P.S.: Point b. from above includes full-broadsided attacks on an unknown enemy like this (https://forum.opnsense.org/index.php?topic=44122.0). Once your OpnSense runs, it must be fully decoded, so disk encryption won't help, either.
You should first try to gather intelligence about if, how, who and what was attacked to find effective measures against it. Excuse me for using this german proverb, but do not fall for: "Operative Hektik ersetzt geistige Windstille".
First, if you think some device of yours has been penetrated by an attacker, reinstall it cleanly.
Quote from: meyergru on November 27, 2024, 10:33:09 AM
,,,: "Operative Hektik ersetzt geistige Windstille".
Operative Hektik verdeckt geistige Windstille. ;-)
Quote from: peterwkc on November 27, 2024, 09:23:29 AM
4. Installed Suricata IPS
Quote
No idea, I do not believe in IPS.
Expand on this please...
Not because I want to debate, but I think you're brilliant, and I've been going back & forth on the decision to implement this in our network.
I found article to hardened OPNsense box.
https://www.zenarmor.com/docs/network-security-tutorials/opnsense-security-and-hardening-best-practice-guide#:~:text=Hardening%20the%20firewall%20entails%20putting,are%20all%20part%20of%20this.
Quote from: peterwkc on November 28, 2024, 12:08:18 AM
I found article to hardened OPNsense box.
Most of these are just a matter of course or won't help with your suspected case.
For example SSH is disabled in a default installation of OPNsense.
To repeat myself: even if you grossly neglect password best practices and do not change the root password for the UI, a newly installed OPNsense cannot be "hacked" over the Internet.
There is no attack surface! None! No services reachable on WAN, all ports blocked. Period.
If your OPNsense was hacked then because you knowingly and intentionally configured *something* that opened it up. And most so called "hacks" are just password guesses.
So did you open your Firewall to the Internet or did you not? That's the question that needs to be answered. Not to blame you but to decide what to change in the future.
Unless you do an assessment of what exactly happend, all the measures you are swapping around in various threads will not help. Reminds me of the user "someone" who claimed he needed to reinstall their OPNsense every couple of days because the moment he hooked it up to the Internet it got "hacked". Ridiculous, really.
Quote from: fakebizprez on November 27, 2024, 04:40:57 PM
Quote from: peterwkc on November 27, 2024, 09:23:29 AM
4. Installed Suricata IPS
Quote
No idea, I do not believe in IPS.
Expand on this please...
Not because I want to debate, but I think you're brilliant, and I've been going back & forth on the decision to implement this in our network.
This is well worth discussing, but maybe in a different thread. I, btw, also don't believe in most of the things IPS is supposed to do.
Quote from: fakebizprez on November 27, 2024, 04:40:57 PM
Quote from: Patrick M. Hausen on November 27, 2024, 09:49:04 AM
No idea, I do not believe in IPS.
Expand on this please...
Not because I want to debate, but I think you're brilliant, and I've been going back & forth on the decision to implement this in our network.
1. Trying to exaustively "enumerate badness" is bound to fail.
The rulesets of current IDS/IPS systems are ridiculously large and generate a ton of false positives. They place a high administrative burden on the operator in the form of tailoring the rules.
As system that is always "flashing red" but operators "know what can be ignored" is useless. Any monitoring system must be "green" in the normal operational state and any "red flag" must be an event that demands action - and can be acted upon in the first place! That means there is a documented way to turn the system back to the "green" state.
Anything else is security theatre and leads to more confusion than it helps.
2. It's never a one-stop solution.
People tend to think that all they need to do is "enable intrusion prevention" and then someone else will prevent intrusions for them. This is not the case for the reasons listed under 1.
From the same reasoning probably we see people trying to activate Suricata and Zenarmor on the same device (because two IPS are better than one, right?) and face technical problems like in this thread - here's a nice comment by Ad about architectural issues:
https://forum.opnsense.org/index.php?topic=9741.msg64178#msg64178
The way IDS/IPS works it is highly unlikely it will ever be able to inspect a PPPoE data stream for example. Also both products have a different focus. So why would you run both (at all) and if it does make sense for you, why both on WAN (doesn't work!)?
So if you still decide to run them at all, separate your publicly reachable servers from your client systems that are merely "facetubing". Use Suricata for the servers (on the server/DMZ interface) and Zenarmor for the clients (on the LAN interface).
3. Traffic is encrypted nowadays.
Most interesting Traffic is encrypted in some form of TLS/SSL. And generations of cryptographers and protocol specialists have been working hard to make TLS secure against man-in-the-middle attacks.
A TLS encrypted session is an authenticated secure private channel between e.g. your browser and the web site of your bank.
If you insist on messing with that so the holy IDS can perform its "magic", you will actually
- weaken the security of these connections
- force all devices to trust your private CA leading to a very interesting attack vector against your entire infrastructure
- make all applications that use certificate pinning fail, so you need to curate extensive white lists
TLS is
designed not to be inspected. What's so hard to understand about that? Just don't.
4. But but but ... I must do $something to improve "security".
So:
- separate systems of different trust.
- implement firewall policies with least privielege principle - give the system access to only what they absolutely need.
- implement a log file and/or reputation based system like fail2ban, Crowdsec, ...
- implement AdGuard Home or some other DNS based block & report mechanism.
- do monitor what is happening around your network, use an NMS like Observium, NtopNG, some Elastic based solution like pfELK - "The number of times an uninteresting thing occurs is an interesting thing." (Marcus Ranum, IIRC, on firewall-wizards).
- but don't worry about trash arriving at your front door (WAN) that is blocked by the firewall, anyway - blocked is blocked, an IPS does not block better or more effectively or anything than the default "deny all" rule.
Kind regards,
Patrick
EDIT: here's a paper worth reading that discusses the pros and cons of TLS interception:
https://jhalderm.com/pub/papers/interception-ndss17.pdf
Yepp, IPS is not "fire and forget" but I like to get a feeling for what is going on the various levels-of-trust LANs. Warnings/blockings by Suricata give a feeling if some client tries e.g. to resolve fishy domains or contact known malware IPs.
Problems normally originate from the LAN side and IPS should be active on LAN, not WAN, correct.
I think the most common misconceptions about IPS systems are about TLS and the "Plug & Play". A lot of time we can see people just complain that is not "just working" or speculate about TLS inspection...
@Patrick
Quote- do monitor what is happening around your network, use an NMS like Observium, NtopNG, some Elastic based solution like pfELK - "The number of times an uninteresting thing occurs is an interesting thing." (Marcus Ranum, IIRC, on firewall-wizards).
Which from these you use may you/care you share some experience or insights?
Regards,
S.
Quote from: Seimus on November 28, 2024, 01:12:52 PM
Quote- do monitor what is happening around your network, use an NMS like Observium, NtopNG, some Elastic based solution like pfELK - "The number of times an uninteresting thing occurs is an interesting thing." (Marcus Ranum, IIRC, on firewall-wizards).
Which from these you use may you/care you share some experience or insights?
I run Observium, I did a weekend long deep dive into pfELK but could not get it to work on FreeBSD. Seems rather mature on Linux. Currently investigating NtopNG off-firewall, i.e. I don't want to run it on OPNsense but send netflow data to a dedicated NtopNG jail instead.
I have also been running (and still do) Crowdsec which I like a lot. If only they had a hobbyist license tier for e.g. 100€ per year. Now it's free edition with quite some limitations or something around 90€ per month - prohibitive, unfortunately.
Quote from: chemlud on November 28, 2024, 12:56:42 PM
Yepp, IPS is not "fire and forget" but I like to get a feeling for what is going on the various levels-of-trust LANs. Warnings/blockings by Suricata give a feeling if some client tries e.g. to resolve fishy domains or contact known malware IPs.
Problems normally originate from the LAN side and IPS should be active on LAN, not WAN, correct.
You can get that by dynamic IP blocklists (firehol, crowdsec) and DNS blocking.
The assertion that opnsense was hacked caught my attention. :o
I should add to the previous suggestions to test before deploying, meaning at least connect it to you lan and run nmap to check for open ports, make sure no default and/or weak passwords are in use, and use key authentication instead of passwords.
There is a lot that can be done, but the default installation is pretty safe, provided that the default passwords are changed/updated during the setup.
Good luck with your new setup, check the forums or ask for more specific questions if you get stuck on something.
Quote from: Patrick M. Hausen on November 28, 2024, 01:23:34 PM
Quote from: Seimus on November 28, 2024, 01:12:52 PM
Quote- do monitor what is happening around your network, use an NMS like Observium, NtopNG, some Elastic based solution like pfELK - "The number of times an uninteresting thing occurs is an interesting thing." (Marcus Ranum, IIRC, on firewall-wizards).
Which from these you use may you/care you share some experience or insights?
I run Observium, I did a weekend long deep dive into pfELK but could not get it to work on FreeBSD. Seems rather mature on Linux. Currently investigating NtopNG off-firewall, i.e. I don't want to run it on OPNsense but send netflow data to a dedicated NtopNG jail instead.
I have also been running (and still do) Crowdsec which I like a lot. If only they had a hobbyist license tier for e.g. 100€ per year. Now it's free edition with quite some limitations or something around 90€ per month - prohibitive, unfortunately.
Being new to crowdsec, would there be any recommended settings to change outside the box of installing the plugin and "enabling" it or are defaults safe/legit for home user with basic setup? I went to the config site with all the options and being I know nothing of it, I would have 0 idea of what to change or add or modify.
Quote from: fbeye on November 28, 2024, 07:32:30 PM
Being new to crowdsec, would there be any recommended settings to change outside the box of installing the plugin and "enabling" it or are defaults safe/legit for home user with basic setup? I went to the config site with all the options and being I know nothing of it, I would have 0 idea of what to change or add or modify.
cscli is your friend. You probably want to whitelist all RFC 1918 networks. To do that:
cscli parsers install crowdsecurity/whitelistsIf you want to not only parse OPNsense pf logs and UI login attempts (if your UI is reachable from WAN at all) but e.g. Caddy access logfiles you can add the matching collection:
cscli collections install crowdsecurity/caddyThen add a file named "/usr/local/etc/crowdsec/acquis.d/caddy.yaml":
filenames:
- /var/log/caddy/access/*.log
force_inotify: true
poll_without_inotify: true
labels:
type: caddy
You get the idea. There are lots of collections for different scenarios depending on what you use for inbound service - NginX, HAproxy, Caddy, ...
You can find them at https://app.crowdsec.net/hub/collections
In the Crowdsec web console you can subscribe to up to three free blocklists in addition to your own locally generated "decisions" as they call it. I use:
- Firehol cruzit.com list
- Firehol greensnow.co list
- Firehol cybercrime tracker list
HTH,
Patrick
Thank you. Wow there is a lot there! [good] overwhelming but very interesting.
Hello
Registered with crowdsec and so on, verified my device. You mentioned 3 free decisions.. when I go to the decisions tab on the www it has 0 currently loaded with 0 to choose from, only button is subscribe premium.which I have no problem with, just didn't wanna miss something.
The only one of these I really use would be email server for incoming and I also run NGINX NPM on a VM on my lan, I wonder would the NGINX collection download be beneficial to the particular instance of me running NGINX, or is it only for onboard [opnsense] NGINX?
3 free blocklists ...
Ahh yes I see that now.
Final question I guess for now is, as far as let's say NGINX and postfix and Dovecot, all stuff I am running on VM's, will the collections refer/monitor those services deeper down the lan or is it only for the opnsense itself hosting these? Where is it scanning from, the ports in relevance to the services as WAN level?
Crowdsec uses a three-tier architecture. You have collectors that, well, collect events. They send the events to a security engine, which records events and makes decisions based on scenarios that are organized in collections. Finally the engine instructs a bouncer to block certain traffic based on a decision.
So what you would need in your case is a distributed setup. You need on each of your machines a collector with the right collection for your service (NginX, Dovecot, ...) that sends the events to the engine running on OPNsense. OPNsense will then use the single bouncer on the firewall to block the attacker with pf.
Distributed setup is well documented by Crowdsec but a bit tricky - I stopped using it after consolidating all my ingress on the OPNsense itself.
If you want to go that route we can talk a little bit more details but not right now.
The "tricky" part is that the cscli commands to add another collector will happily overwrite the authentication info for all collectors that already exist including the local host if you are not extra careful. That's a bit unfortunate.
Think about running all your ingress through e.g. HAproxy on OPNsense - then you can just feed the HAproxy logs to Crowdsec.
Kind regards,
Patrick
Oh wow. Yeah I'll have to look into this and see if it is something I am capable of doing.
OPNsense is 172.16.2.1 but my Dovecot/Postfix is 192.168.1.180 and my NGINX is 192.168.2.181. I'll have to see all about what I am gonna do here. Lots of information, ty
Now that I think about it, not even sure how I would even incorporate my email server through HA. For now seems I will hold off.
The ISP hacked OPNsense?
I have another assumption. Lately I read on Telegram, that some kind of Aliens escaped Area 51. Those took over the control everywhere. I guess this is more likely.
- They Live -
(https://upload.wikimedia.org/wikipedia/en/3/3d/1988They_Live_poster300.jpg)
Thanks, Patrick. The white list maintenance had me on the fence to begin with. I didn't know that ZenArmor is also included in the same category. I had planned on putting it on the LAN and using something like Crowdsec, but now I'm not so sure. My main concern is configuring the best monitoring, alerts, and logging setup. I underestimated the amount of time that would need to be dedicated to that initiative.
Thanks Patrik to lead the discussion the discussion.
My OPNSense box was not reachable to the internet even i did not change anything on the OPNSens machine. I guess this is sign of hacked because my machine was old version (I can't remember the version). Do you really recommend always update to latest version because i saw from forum.opnsense there is many problem and i not dare to update it to avoid technical problem.
Quote from: peterwkc on December 06, 2024, 09:23:18 AM
My OPNSense box was not reachable to the internet even i did not change anything on the OPNSens machine. I guess this is sign of hacked because my machine was old version (I can't remember the version). Do you really recommend always update to latest version because i saw from forum.opnsense there is many problem and i not dare to update it to avoid technical problem.
I am team "always run supported software". Everywhere. Just wait a day or two after a new release, check the forums, make a ZFS snapshot before updating, so you can roll back. Just keep your systems up to date.
Quote from: Patrick M. Hausen on December 06, 2024, 09:41:34 AMQuote from: peterwkc on December 06, 2024, 09:23:18 AMMy OPNSense box was not reachable to the internet even i did not change anything on the OPNSens machine. I guess this is sign of hacked because my machine was old version (I can't remember the version). Do you really recommend always update to latest version because i saw from forum.opnsense there is many problem and i not dare to update it to avoid technical problem.
I am team "always run supported software". Everywhere. Just wait a day or two after a new release, check the forums, make a ZFS snapshot before updating, so you can roll back. Just keep your systems up to date.
Yesterday my opnsense box was hacked. Example my android TV box was mess up. My windows pc was some software uninstalled like tinywall
Now I resetup the opnsense with syncopkies enable n firewall optimization aggressive. What else can I do??
I can show the screenshot of my firewall block log if you need it.
I cannot attach screenshot due to size restriction but i want tell you all that i have 100% block packet in overview.
Quote from: Patrick M. Hausen on November 28, 2024, 08:10:23 PMQuote from: fbeye on November 28, 2024, 07:32:30 PMBeing new to crowdsec, would there be any recommended settings to change outside the box of installing the plugin and "enabling" it or are defaults safe/legit for home user with basic setup? I went to the config site with all the options and being I know nothing of it, I would have 0 idea of what to change or add or modify.
cscli is your friend. You probably want to whitelist all RFC 1918 networks. To do that:
cscli parsers install crowdsecurity/whitelists
If you want to not only parse OPNsense pf logs and UI login attempts (if your UI is reachable from WAN at all) but e.g. Caddy access logfiles you can add the matching collection:
cscli collections install crowdsecurity/caddy
Then add a file named "/usr/local/etc/crowdsec/acquis.d/caddy.yaml":
filenames:
- /var/log/caddy/access/*.log
force_inotify: true
poll_without_inotify: true
labels:
type: caddy
You get the idea. There are lots of collections for different scenarios depending on what you use for inbound service - NginX, HAproxy, Caddy, ...
You can find them at https://app.crowdsec.net/hub/collections
In the Crowdsec web console you can subscribe to up to three free blocklists in addition to your own locally generated "decisions" as they call it. I use:
- Firehol cruzit.com list
- Firehol greensnow.co list
- Firehol cybercrime tracker list
HTH,
Patrick
Greensnow is good, cruzit was last updated in 2023 on Firehol. Thx for the cli-fu in crowdsec, wasnt aware of :)
Quote from: peterwkc on December 17, 2024, 07:15:18 AMI cannot attach screenshot due to size restriction but i want tell you all that i have 100% block packet in overview.
Of course you have. WAN by default blocks everything in. If something messed with your PC or your TV you possibly caught some malware. A firewall does not protect you from that. A firewall is a network security device. One does not need to "hack your OPNsense" for your PC to get compromised.
I would start investigating what really happened to your devices.
Quote from: Patrick M. Hausen on December 17, 2024, 07:38:56 AMQuote from: peterwkc on December 17, 2024, 07:15:18 AMI cannot attach screenshot due to size restriction but i want tell you all that i have 100% block packet in overview.
Of course you have. WAN by default blocks everything in. If something messed with your PC or your TV you possibly caught some malware. A firewall does not protect you from that. A firewall is a network security device. One does not need to "hack your OPNsense" for your PC to get compromised.
I would start investigating what really happened to your devices.
I don't have idea how to protect it. By the way, What is the log tell me?
LAN 2024-12-17T15:58:23 192.168.1.102:49770 165.154.1.118:10001 tcp Default deny / state violation rule
Quote from: peterwkc on December 17, 2024, 09:00:38 AMI don't have idea how to protect it. By the way, What is the log tell me?
LAN 2024-12-17T15:58:23 192.168.1.102:49770 165.154.1.118:10001 tcp Default deny / state violation rule
The internal system with IP address 192.168.1.102 sent a TCP packet to the Internet system with IP address 165.154.1.118 (somewhere in Hong Kong, probably) that did not belong to an established connection so the firewall dropped it.
What are the crowdsec block lists you guys talking in this thread??
For the time being, I move my android TV box to opt1 n block the opt1 to lan net
What r the rules need to create for this purpose?
As promised, here is the screenshot.
Quote from: peterwkc on November 27, 2024, 09:23:29 AMMost probably my ISP has hacked my router. (Dont' argue this).
🤦
I used to know someone who'd make the same sort of absurd claims. He had to reinstall frequently because he kept getting hacked and he was absolutely sure it was *his ISP* doing it. "Don't tell me I'm wrong", he'd exclaim. It turned out he was freaking out and blocking inbound related/established packets, blocking himself from a working internet connection.
Acting without understanding why can be dangerous.
Recently my OPNSense reboot randomly. Possible of KVM over IP hack? Is it a hardware based remote access.
How to block/disable this?
Random reboots are in almost all cases a hardware problem. Check power supply first. Connect a serial console and look what happens when it reboots. Stuff like that.
Quote from: meyergru on November 27, 2024, 10:33:09 AMExcuse me for using this german proverb, but do not fall for: "Operative Hektik ersetzt geistige Windstille".
Great proverb, I gotta remember than one :)
I discover an article which is Tinypilot where it is a hardware based remote access system which use KVM over IP.
My LAN got mess up where i could not access the gateway anymore. Ping shows drop packet loss. Then, I go reset my opnsense box. After reset my opnsense box, it reboot after 30 minutes. I believe the hacker has put some backdoor in it n reboot the machine.
https://homenetworkguy.com/review/remote-system-administration-with-tinypilot-voyager/
If Tinypilot or PiKVM were being used to access your router then I would suggest you walk up to your router and pull out the HDMI and USB cables connecting the physical KVM box which you would see sitting there. Even if it existed, it would need separate access to your network to reach the KVM. It is not magic.
Quote from: passeri on December 30, 2024, 09:19:34 AMIf Tinypilot or PiKVM were being used to access your router then I would suggest you walk up to your router and pull out the HDMI and USB cables connecting the physical KVM box which you would see sitting there. Even if it existed, it would need separate access to your network to reach the KVM. It is not magic.
I understand what you mentioned this technology is not magic. Can you explain how this technology works in term of connectivity?
Sure. PikVM, Tinypilot, are small boxes which physically connect to a target machine using a cable for keyboard (USB) and for the display (usually HDMI). That is, it is physically adjacent and connected to the target machine (your router if it applied to you). It also has a network connection, usually ethernet, to an existing network to which the user already has access using HTTP/HTTPS.
The user of the KVM can be remote, if they have remote network access, but the physical box must be on the site of the target machine.
I use a PiKVM to install 'nix machines, including Opnsense on random hardware, and sometimes to use Linux from my normal Mac desktop or a portable without encumbrance of additional keyboard, mouse or screen.
Quote from: passeri on December 30, 2024, 10:56:10 AMSure. PikVM, Tinypilot, are small boxes which physically connect to a target machine using a cable for keyboard (USB) and for the display (usually HDMI). That is, it is physically adjacent and connected to the target machine (your router if it applied to you). It also has a network connection, usually ethernet, to an existing network to which the user already has access using HTTP/HTTPS.
The user of the KVM can be remote, if they have remote network access, but the physical box must be on the site of the target machine.
I use a PiKVM to install 'nix machines, including Opnsense on random hardware, and sometimes to use Linux from my normal Mac desktop or a portable without encumbrance of additional keyboard, mouse or screen.
Thanks for your clear explanation. AFAIK, It will need tinypilot on my end in order for my ISP to remote access my machine.
That is right. It is what I meant by my "It's not magic" comment, that if you see no physical box attached, then nothing is happening by that means.
Quote from: peterwkc on November 27, 2024, 09:23:29 AMMost probably my ISP has hacked my router. (Dont' argue this).
LOL, no, just no, your isp didnt hack nothing.
And then to say we cant argue that, are you kidding me? If nothing is opened to wan side, not even your ISP can hack the opnsense box.
Quote from: thecrankygamer on December 30, 2024, 02:00:20 PMQuote from: peterwkc on November 27, 2024, 09:23:29 AMMost probably my ISP has hacked my router. (Dont' argue this).
LOL, no, just no, your isp didnt hack nothing.
And then to say we cant argue that, are you kidding me? If nothing is opened to wan side, not even your ISP can hack the opnsense box.
I think you didn't see my screenshot that i shared. It's full of block packet in the firewall log.
So? Your firewall is connected to the Internet. So bad actors will scan it 24x7. And the OPNsense firewall will by default block all of these attempts. The log showing all of these blocked packets is proof that the firewall is working. Not the other way round.
Quote from: Patrick M. Hausen on December 31, 2024, 01:30:49 AMSo? Your firewall is connected to the Internet. So bad actors will scan it 24x7. And the OPNsense firewall will by default block all of these attempts. The log showing all of these blocked packets is proof that the firewall is working. Not the other way round.
Yes, My firewall connected to Internet. Today, the firewall reboot twice times by itself. I don't know whether my firewall was hacked. Moreover, on the day before yesterday, My PC cannot ping the default gateway ip address. So, I suspected LAN PC was hacked. My others PC which did not connect to Internet able to ping. So, this is strange to me.
Sporadic reboots are caused mostly due to crashes, not hacks. Your PC not pinging the GW or not having network access are examples of issues on your network or the GW usually. Or the host itself had an issue if it was isolated to just one device. This doesn't exclude that you can have an infected device via a Virus, but that's not hacking that's a virus.
Once again, if you didn't open ports towards internet, didn't allowed SSH & HTTP/s GUI management, there is no way you could be hacked from internet.
Your mindset is totally wrong on this.
Regards,
S.
Quote from: peterwkc on January 02, 2025, 08:53:59 AMQuote from: Patrick M. Hausen on December 31, 2024, 01:30:49 AMSo? Your firewall is connected to the Internet. So bad actors will scan it 24x7. And the OPNsense firewall will by default block all of these attempts. The log showing all of these blocked packets is proof that the firewall is working. Not the other way round.
Yes, My firewall connected to Internet. Today, the firewall reboot twice times by itself. I don't know whether my firewall was hacked. Moreover, on the day before yesterday, My PC cannot ping the default gateway ip address. So, I suspected LAN PC was hacked. My others PC which did not connect to Internet able to ping. So, this is strange to me.
if i was haxor id want your pc and router to stay ONLINE. not reboot, as id lose access to trying to steal all of your porn collection
this entire thread is nonsense
Quote from: DEC670airp414user on January 02, 2025, 11:19:37 AMQuote from: peterwkc on January 02, 2025, 08:53:59 AMQuote from: Patrick M. Hausen on December 31, 2024, 01:30:49 AMSo? Your firewall is connected to the Internet. So bad actors will scan it 24x7. And the OPNsense firewall will by default block all of these attempts. The log showing all of these blocked packets is proof that the firewall is working. Not the other way round.
Yes, My firewall connected to Internet. Today, the firewall reboot twice times by itself. I don't know whether my firewall was hacked. Moreover, on the day before yesterday, My PC cannot ping the default gateway ip address. So, I suspected LAN PC was hacked. My others PC which did not connect to Internet able to ping. So, this is strange to me.
if i was haxor id want your pc and router to stay ONLINE. not reboot, as id lose access to trying to steal all of your porn collection
this entire thread is nonsense
I can share video about my block packet to you to proof that the hacker had tried to connect to WAN. I got enemy that why my ISP want to spoil me. By the way, thanks for your effort to reply this thread.
Blocked packets are proof that your firewall is working. Every system connected to the Internet is scanned by automatic bots 24x7. There's nothing one can do about that but use a firewall that blocks these attempts as OPNsense does by default.
Blocked == not hacked == good.
@peterwkc, please advise straight answers to the following:
- Are your firewall rules all in the default state?
- If not, please provide any and all NAT or port forwarding (or other) rules you have created, edited, or removed.
As noted early in this thread, we can not exclude an infection on your internal machines, arriving through phishing or downloading dodgy software. We can tell you what, if any, exposures you may have on your firewall.
As noted more than once by Patrick, the logs you have provided show normal and effective operation of the firewall. You have also not yet described any "hacker" behaviour which would be logical for a real external intruder. If your ISP did not like you, they could more simply randomly drop your connection. It is again hugely improbable.
We may be able to help with clear answers about configuration. Remember, your fears about TinyPilot proved unfounded once you had looked into and understood it better.
Quote from: peterwkc on January 03, 2025, 08:05:13 AMI can share video about my block packet to you to proof that the hacker had tried to connect to WAN. I got enemy that why my ISP want to spoil me. By the way, thanks for your effort to reply this thread.
NO, just NO, this is normal.
Everybody sees this or had in a point of time seen it. Doesn't matter what FW/Router you use, Open source, Off the shelf or Enterprise. If you use a device on the edge > Internet, this is what is in today's manners expected to be seen.
Quote from: Patrick M. Hausen on January 03, 2025, 08:17:53 AMBlocked packets are proof that your firewall is working. Every system connected to the Internet is scanned by automatic bots 24x7. There's nothing one can do about that but use a firewall that blocks these attempts as OPNsense does by default.
Blocked == not hacked == good.
Exactly, couldn't say it myself better.
OP, the only proof you state or post, is so far proofing that all is well working and blocked Ingress towards your WAN.
Regards,
S.
Some of the blocked sources were on crowdsec's radar. It means that these sources are known as being owned by bad actors on a global scale...
You're not the only target. EVERYBODY is. If you have a public IPv4, you will see unsolicited requests.
It's the sad reality of today's internet. That's why you have a firewall at the edge of your network.
There have been plenty of reports of compromised consumer routers (e.g. TP-link) but you're using a commercial grade router...
With OPN set to reject all incoming traffic on WAN, I'd be more worried about malware or compromised poorly maintained devices.
Quote from: passeri on January 03, 2025, 09:34:29 AM@peterwkc, please advise straight answers to the following:
- Are your firewall rules all in the default state?
- If not, please provide any and all NAT or port forwarding (or other) rules you have created, edited, or removed.
As noted early in this thread, we can not exclude an infection on your internal machines, arriving through phishing or downloading dodgy software. We can tell you what, if any, exposures you may have on your firewall.
As noted more than once by Patrick, the logs you have provided show normal and effective operation of the firewall. You have also not yet described any "hacker" behaviour which would be logical for a real external intruder. If your ISP did not like you, they could more simply randomly drop your connection. It is again hugely improbable.
We may be able to help with clear answers about configuration. Remember, your fears about TinyPilot proved unfounded once you had looked into and understood it better.
I have added one rule block in wan and have several firewall aliases like crowdsec. Opt1 block to lan. No sshd no open port. Opt1 WiFi provide based on mac address.
I worried they use malware to get access to my system.
My firewall reboot this morning again. I don't know whether this is crash or have backdoor script
> My firewall reboot this morning again. I don't know whether this is crash or have backdoor script
I'll repeat again. WAN will block everything not solicited from the inside by default. You can of course add blocking aliases but they are mostly unnecessary if they initiate from the outside. If the connection is a response to a request from say a compromised lan device ie. you download some dodgy application infected with malware, then the firewall alias block will be of little use.
Another reboot? Most likely a hardware problem. Look in the logs of the system. The message buffer is wiped on reboot but the previous log will be saved to /var/log/ . Look for the dmesg files.
Quote from: peterwkc on November 27, 2024, 09:23:29 AMDear all, I had installed opnsense quite long time ago but recently my LAN cannot browse internet. Most probably my ISP has hacked my router. (Dont' argue this).
Im looking method to harden my OPNSense router. Please suggest. Thanks.
Harden OPNSense Methods:
1. Disable SSH services
2. Disable root user in web gui option
3. WiFI based on MAC Address only
4. Installed Suricata IPS
5. Disable boot into single user mode to prevent hacker change password
6. How to enable sudo?
Hire a professional, you are not making much sense and show a lack of objectivity without providing sensible evidence.
Quote from: Patrick M. Hausen on November 28, 2024, 01:23:34 PMQuote from: Seimus on November 28, 2024, 01:12:52 PMQuoteI have also been running (and still do) Crowdsec which I like a lot. If only they had a hobbyist license tier for e.g. 100€ per year. Now it's free edition with quite some limitations or something around 90€ per month - prohibitive, unfortunately.
Thanks for the kind words.
Just to be clear, the IDS, IPS, WAF, and all rulesets and scenarios have absolutely no limitations.
The only limited features are in the SaaS and the ones for corporations (auto-enrolment, alert context, AI-driven list, etc.) and the ones that are costly for us (like storing 1Y of incident history).
You even get a large and frequently updated blocklist in the free tier.
Premium, AI and Platinum blocklists are our paid products indeed.
My LAN Windows PC was affected where the pc change background and word document mess up.
Quote from: peterwkc on January 08, 2025, 08:41:39 AMMy LAN Windows PC was affected where the pc change background and word document mess up.
So far, so bad. You will need to investigate how that happened. But it does in no way imply that
- your OPNsense was compromised
- your ISP did it
Both things are highly unlikely
even in the case of a breached Windows PC.
Let me monitor few days and see.
Hackers might use your hardware as part of a botnet or for mining, discretely.
Or they might encrypt all your data for ransom. Or just steal it if it's valuable to them.
Announcing their presence with something as visible as a background change and messing with one file doesn't quite fit.
I have several cron job to periodic reset wan interface and now it is not working anymore. It doesn't renew my wan ip address anymore.
Quote from: peterwkc on January 10, 2025, 08:16:04 AMI have several cron job to periodic reset wan interface
Why?
Perhaps your ISP's system is slow to reconnect a system you have made appear flaky with resets.
Quote from: peterwkc on January 10, 2025, 08:16:04 AMI have several cron job to periodic reset wan interface and now it is not working anymore. It doesn't renew my wan ip address anymore.
Quote from: peterwkc on December 28, 2024, 04:02:53 AMRecently my OPNSense reboot randomly. Possible of KVM over IP hack? Is it a hardware based remote access.
How to block/disable this?
Why do we keep returning to this thread, it's like a car crash thing. Guess the histerics of title and posts.
Anyways OP, check dmesg for hints. There's a good chance you have hardware problems, as told before. Nothing malign, just simple bad hardware. By the way, what is your hardware including NIC make, model? If reaktek, which driver are you using, the OPN default or another, which?
Check if your reboots are not related to kernel panic's, there have been several threads on this topic recently.
Quote from: borys.ohnsorge on January 10, 2025, 07:44:41 PMCheck if your reboots are not related to kernel panic's, there have been several threads on this topic recently.
I do have crash issue in the /var/log/dmesg. I using latest version.
Then why don't you post the "crash issue" here? None of us owns a crystal ball. The cause for your crashes is in that text!
@peterwkc You should have something similar to this:
<45>1 2025-01-10T02:33:17+01:00 opnsense2 syslog-ng 28239 - [meta sequenceId="1"] syslog-ng starting up; version='4.8.1'
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="2"] Fatal trap 12: page fault while in kernel mode
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="3"] cpuid = 3; apic id = 03
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="4"] fault virtual address = 0x0
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="5"] fault code = supervisor write data, page not present
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="6"] instruction pointer = 0x20:0xffffffff80f3c00f
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="7"] stack pointer = 0x28:0xfffffe000edf1d10
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="8"] frame pointer = 0x28:0xfffffe000edf1d50
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="9"] code segment = base 0x0, limit 0xfffff, type 0x1b
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="10"] = DPL 0, pres 1, long 1, def32 0, gran 1
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="11"] processor eflags = interrupt enabled, resume, IOPL = 0
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="12"] current process = 0 (thread taskq)
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="13"] rdi: fffffe008ea60400 rsi: 0000000000000000 rdx: 000000000000002e
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="14"] rcx: 0000000000000000 r8: 0000000000000000 r9: fffff80005c2f480
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="15"] rax: 0000000000000000 rbx: 0000000000000000 rbp: fffffe000edf1d50
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="16"] r10: fffff80005c2f480 r11: 00000000802e6e20 r12: fffff801c6694fe0
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="17"] r13: fffffe008ea60400 r14: fffff801c6694318 r15: fffff80005c2f540
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="18"] trap number = 12
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="19"] panic: page fault
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="20"] cpuid = 3
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="21"] time = 1736472729
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="22"] KDB: stack backtrace:
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="23"] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe000edf1a00
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="24"] vpanic() at vpanic+0x131/frame 0xfffffe000edf1b30
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="25"] panic() at panic+0x43/frame 0xfffffe000edf1b90
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="26"] trap_fatal() at trap_fatal+0x40b/frame 0xfffffe000edf1bf0
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="27"] trap_pfault() at trap_pfault+0x46/frame 0xfffffe000edf1c40
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="28"] calltrap() at calltrap+0x8/frame 0xfffffe000edf1c40
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="29"] --- trap 0xc, rip = 0xffffffff80f3c00f, rsp = 0xfffffe000edf1d10, rbp = 0xfffffe000edf1d50 ---
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="30"] zone_release() at zone_release+0x1df/frame 0xfffffe000edf1d50
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="31"] bucket_drain() at bucket_drain+0xb9/frame 0xfffffe000edf1d80
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="32"] bucket_cache_reclaim_domain() at bucket_cache_reclaim_domain+0x2ff/frame 0xfffffe000edf1de0
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="33"] zone_timeout() at zone_timeout+0x2eb/frame 0xfffffe000edf1e20
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="34"] uma_timeout() at uma_timeout+0x58/frame 0xfffffe000edf1e40
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="35"] taskqueue_run_locked() at taskqueue_run_locked+0x182/frame 0xfffffe000edf1ec0
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="36"] taskqueue_thread_loop() at taskqueue_thread_loop+0xc2/frame 0xfffffe000edf1ef0
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="37"] fork_exit() at fork_exit+0x7f/frame 0xfffffe000edf1f30
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="38"] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe000edf1f30
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="39"] --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="40"] KDB: enter: panic
<13>1 2025-01-10T02:33:17+01:00 opnsense2 kernel - - [meta sequenceId="41"] ---<<BOOT>>---
Copy it with to lines before "Fatal trap 12:..." and paste it here as a "code".
Quote from: Patrick M. Hausen on January 11, 2025, 11:58:53 AMThen why don't you post the "crash issue" here? None of us owns a crystal ball. The cause for your crashes is in that text!
Here it is the dmesg text.
1.: Disable Suricata on PPPoE interface
2.: run Memtest86+ to check for faulty ram modules. (Download the iso here: https://www.memtest.org/)
3.: replace Harddisk and reinstall OPNsense
Quote from: seed on January 13, 2025, 05:15:29 PM1.: Disable Suricata on PPPoE interface
2.: run Memtest86+ to check for faulty ram modules. (Download the iso here: https://www.memtest.org/)
3.: replace Harddisk and reinstall OPNsense
I have Suricata IDS on PPPOE interface only.
IPS is not supported for PPPoE, only IDS.
Quote from: Patrick M. Hausen on January 14, 2025, 09:29:38 AMIPS is not supported for PPPoE, only IDS.
Suricata can function as an IPS with PPPoE without any problems, you just need to make a few modifications:
- Configure the WAN interface as none (IPv4 Configuration Type none)
- Add a new OPT interface with the PPPoE configuration just like it was a WAN PPPoE.
- Configure Suricata as IPS on WAN.
https://forum.opnsense.org/index.php?topic=9741.15
Thanks! I won't but that possibly will help the OP.
I know IPS is not function in PPPOE.
Quote from: peterwkc on January 15, 2025, 04:37:23 AMI know IPS is not function in PPPOE.
You won't get it right, in my case I have set it up several times and it has always worked first time.