Re: Advice on using intrusion detection
On 2020-11-20 17:15, Erik Lauritsen wrote: > Is it recommended to run some kind of intrusion detection on an > OpenBSD router/firewall? > What do you mean by "some kind of intrusion detection" (IDS). At the risk of sounding patronizing I would start by clarifying terminology. I got confused by Nick's answer as he started talking about Intrusion Prevention Systems when you asked about Intrusion Detection Systems. In layman's terms Intrusion Prevention Systems are trying to keep the bad buys out before they get into your system. Intrusion Detection Systems are postmortem tools. They are useful for detecting that your system is compromised. Both IPS and IDS can be further roughly divided into host (file) based systems or network based systems. Some tools are easier to classify than other. For example it would seems logical to me to classify OpenBSD packet filter (PF) as an example of a network intrusion prevention system. On the another hand, log file monitoring could be useful both for preventing but also for detecting intrusion so the above classification is really blurry. OpenBSD is all about prevention and exploit mitigation. Code simplicity, correctness, and code audit are all examples of intrusion prevention methods. They don't sound very sexy :-) If you are super new to OpenBSD Peter just gave a really nice virtual talk which can be found on the net https://home.nuug.no/~peter/openbsd_and_you/#12 Now going to your original question. What about Intrusion Detection Systems? While as an OpenBSD user would like to think that I am a bit ahead of guys using more complicated OSs, I am not delusional to assume that my systems can't be compromised. There is a saying that the OS is as secure as the person who configured it. In spite of using OpenBSD for almost 15 years now including at work I frequently get amazed by my own incompetence so I am 100% sure my systems are not super secure. Therefore (and due to other contractual obligations) I do use Intrusion Detection Systems. The concept of IDS can be divided into two classes. These are Host IDS (HIDS) and Network (NIDS). IDS / \ HIDS NIDS Host IDS Network IDS Inspecting Host Inspecting Network Host based intrusion detection HIDS for short. An example would be Tripwire (not available on OpenBSD) or a free alternative security/aide. Even better. OpenBSD comes with mtree(8) utility. It is dead easy to turn on HIDS on your OpenBSD firewall. You can also check hack 58 (Use mtree as a Built-in Tripwire). https://www.oreilly.com/library/view/bsd-hacks/0596006799/ I would put Nick's rsync hack into this category. > I suspect that any kind of system like Snort or Suricata will give a > lot of false positives?o These two fall into the category of Network Based Intrusion Detection Systems. I would add to that group zeek (formerly known as Bro). I do run Suricata and I do run Zeek on OpenBSD. While turning them on is trivial getting them to do anything useful (in particularly Zeek which more of an infrastructure for building NIDS) is not for the faint of heart. I also run OSSEC on OpenBSD which is oftenly misclassified as HIDS only. Configured properly it is actually useful in monitoring all sorts of log files including network logs so it is kind both HIPS and NIPS. An for the record I do recommend running centralized login server. Intrusion Prevention and Intrusion Detection are active research areas and I am not talking about superficial level. It is actual real research on the cusp of computer science, mathematics, statistics, and few other things people commonly refer these days as artificial intelligence, machine learning, and statistical data mining. https://www-users.cs.umn.edu/~lazar027/intrusion_detection.htm As my expertise is in applied dynamical systems (math-physics) I should wrap up this email before too much garbage comes out of my mouth . I have seen people giving a low level Network System monitoring, Intrusion detection presentations at various BSD conferences. https://papers.freebsd.org/2017/vbsdcon/shirk-the_state_of_network_security_tools_on_bsd/ https://www.bsdcan.org/2004/papers/sguil.pdf https://www.ibm.com/developerworks/library/se-intrusion/index.html I did read a few low level books on the topic but I neither have professional nor research interest in the topics. Here are two of those: The Practice of Network Security Monitoring: Understanding Incident Detection and Response https://www.amazon.com/Practice-Network-Security-Monitoring-Understanding/dp/1593275099 Tao of Network Security Monitoring, The: Beyond Intrusion Detection https://www.amazon.com/Tao-Network-Security-Monitoring-Intrusion/dp/0321246772 Cheers, Predrag
Re: A new race condition in OpenVPN and Unbound services
Thanks to everyone replaying to this thread. I carefully re-reading as kindly pointed out by Stefan. I ended up implementing this paragraph Using an /etc/hostname.* file without persist-tun - OpenVPN normally re-creates the tun/tap interface at startup. This has been reported to cause problems with some PF configurations (especially with queueing), if you run into problems with this then OpenVPN should be started from the hostname.* file, e.g.: # cat << EOF > /etc/hostname.tun0 up !LD_LIBRARY_PATH=/usr/local/lib:/usr/lib /usr/local/sbin/openvpn \ --daemon --config /etc/openvpn/server.conf EOF In a hindsight I should have done that before making a noise. I have had at least two OpenVPN/OpenBSD servers servers (30-40 road warriors) for the past eight years. I got spoiled by the painless upgrade process and squeaked on the first sign that something worked tiny bit different than previous release. Best, Predrag
Re: limit UDP connection rate with PF pass rule
On 2020-11-18, mabi wrote: >> The DNS RRL techniques typically still reply to a proportion of queries >> (either directly with the answer, or with a "retry over TCP" response >> code) reducing impact if the source IP is also used by real queries as >> well as the attack traffic. > > I've been looking into that in the past and as I am using PowerDNS 4.0.3 the > only valid config parameters I could find and which I already have in place > are the following: > > overload-queue-length=1 > max-tcp-connections=5 > > There is as far as I know no such parameter as "max-udp-connections". > > >From what I can tell PowerDNS authoritative server doesn't handle this directly but you can implement it by front-ending with dnsdist. That isn't OpenBSD-specific so you are better asking on their mailing lists if you need help with this.
Re: A new race condition in OpenVPN and Unbound services
On 2020-11-21, Kasak wrote: > > >> 21 нояб. 2020 г., в 07:24, Predrag Punosevac >> написал(а): >> >> >> Hi Misc, >> >> Has anybody else noticed a new race condition causing Unbound to fail >> due to the fact that OpenVPN interface is not available. >> >> Since a few releases ago I have this in my rc.conf.local to start >> openvpn server and unbound >> >> openvpn_flags=--config /etc/openvpn/server.conf >> pkg_scripts=sshguard collectd smartd openvpn >> sensorsd_flags= >> snmpd_flags= >> syslogd_flags="-h" >> unbound_flags= >> >> Previously I was starting OpenVPN server via >> /etc/hostname.tun0 >> >> file >> >> up link0 >> !/usr/local/sbin/openvpn --daemon --config /etc/openvpn/server.conf >> >> I noticed this morning after upgrading 2 of my OpenVPN servers that >> unbound is failing to start because tun0 is not available on time. If I >> go back to start OpenVPN server from /etc/hostname.tun0 file everything >> works as expected. >> >> Cheers, >> Predrag >> > I can advice you not to bind unbound on tun(tap) interface. You can bind it > to phisycal nic or virtual nic, and just allow recursion for vpn network. Of > cource you should turn on net.inet.ip.forwarding on sysctl > > Or use the "any" address/es and interface-automatic; interface-automatic: yes interface: 0.0.0.0 interface: :: (obviously with access-control set as appropriate).
Re: Advice on using intrusion detection
On 2020-11-20 17:15, Erik Lauritsen wrote: > Is it recommended to run some kind of intrusion detection on an > OpenBSD router/firewall? > > I suspect that any kind of system like Snort or Suricata will give a > lot of false positives? MY philosophy is it is much easier to keep 'em out than to find 'em once they are in. And the odds of an intruder popping you firewall's security is relatively low. Be far more suspect of things BEHIND your firewall. So...my answer to your question is, "no, I wouldn't recommend any kind of add-on intrusion detection to an OpenBSD Firewall". The simpler your firewall, the better. The only package I put on my firewalls is rsync for backup purposes. Application server? Now that's another story, perhaps. One thing I have been doing for a while is rsync --link-dest backups of systems, both in-house and at various workplaces. FANTASTIC tool, giving incredibly "useful" backups, with relatively low impact and resource requirements. My I use a -v on rsync to get verbose backups, and log it to a file. Just recently, I realized these logs are basically a "changed file" report, which is a starting point for a file alteration reporting tool. Combine that with a carefully crafted "ignore" file (you can do that with a grep -vf ignorefile logfile), and you have an interesting file monitoring system. The painful part with any such system is crafting the list of what to ignore vs. what to panic over. Everyone wants to tick the checkbox that says "We have an intrusion detection system", and everyone wants one of two results: "No problem" and "intruder detected". So far, I don't think any tool does that. An IDS without careful human monitoring is just for show (and it's a potential security risk of its own), and more likely to be the cause of a problem than a solution. Careful monitoring takes time and resources. One nifty thing I have found in "rolling my own" is that I found a lot of little oddities, no security problems, but things that needed fixing. I'd call that a win. Nick.
Re: A new race condition in OpenVPN and Unbound services
> 21 нояб. 2020 г., в 07:24, Predrag Punosevac > написал(а): > > > Hi Misc, > > Has anybody else noticed a new race condition causing Unbound to fail > due to the fact that OpenVPN interface is not available. > > Since a few releases ago I have this in my rc.conf.local to start > openvpn server and unbound > > openvpn_flags=--config /etc/openvpn/server.conf > pkg_scripts=sshguard collectd smartd openvpn > sensorsd_flags= > snmpd_flags= > syslogd_flags="-h" > unbound_flags= > > Previously I was starting OpenVPN server via > /etc/hostname.tun0 > > file > > up link0 > !/usr/local/sbin/openvpn --daemon --config /etc/openvpn/server.conf > > I noticed this morning after upgrading 2 of my OpenVPN servers that > unbound is failing to start because tun0 is not available on time. If I > go back to start OpenVPN server from /etc/hostname.tun0 file everything > works as expected. > > Cheers, > Predrag > I can advice you not to bind unbound on tun(tap) interface. You can bind it to phisycal nic or virtual nic, and just allow recursion for vpn network. Of cource you should turn on net.inet.ip.forwarding on sysctl
Re: A new race condition in OpenVPN and Unbound services
On Fri, Nov 20, 2020 at 11:21:00PM -0500, Predrag Punosevac wrote: > > Hi Misc, > > Has anybody else noticed a new race condition causing Unbound to fail > due to the fact that OpenVPN interface is not available. > > Since a few releases ago I have this in my rc.conf.local to start > openvpn server and unbound > > openvpn_flags=--config /etc/openvpn/server.conf > pkg_scripts=sshguard collectd smartd openvpn > sensorsd_flags= > snmpd_flags= > syslogd_flags="-h" > unbound_flags= > > Previously I was starting OpenVPN server via > /etc/hostname.tun0 > > file > > up link0 > !/usr/local/sbin/openvpn --daemon --config /etc/openvpn/server.conf You don't need 'link0' anymore these days. > I noticed this morning after upgrading 2 of my OpenVPN servers that > unbound is failing to start because tun0 is not available on time. If I > go back to start OpenVPN server from /etc/hostname.tun0 file everything > works as expected. Leaving the creation of the tun0 interface up to OpenVPN is never going to work 100% of the time if other programs also depend on tun0 being present. Have you considered following "Using an /etc/hostname.* file with persist-tun" in /usr/local/share/doc/pkg-readmes/openvpn? And with that you could probably also apply the config tweaks under "Running OpenVPN in chroot".
