Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - segfault

#1
17.1 Legacy Series / Re: Jails and privilege isolation
December 15, 2016, 12:13:15 AM
Since the web interface can be setup to listen only on localhost and accessible via an SSH tunnel, I find it less worrisome than for other network services that must be open to potential hostile networks, like the Internet.

If ways can't be found to reduce the required privileges of such network exposed services, isolating them with Jails seems like a solution worth exploring.

The firewall is only going to protect us from packets that aren't supposed to get through. Once they're in, we need to rely on other security mechanisms. Running so many of the daemons as root is a sure fire way to get easily hacked sooner rather than later.
#2
17.1 Legacy Series / Re: Jails and privilege isolation
December 14, 2016, 02:41:22 AM
IMO, the complexity added by isolating different daemons in jails is offset by the security benefits it brings.

The reduction of privileges by running processes as non-root is a good first step in that direction. Things are not secure right now running as root. How can I help move this forward?
#3
17.1 Legacy Series / Jails and privilege isolation
December 12, 2016, 04:48:48 PM
Hello everyone,

I'd like to know if the Opnsense community has discussed before the tradeoffs and potential security improvements of running as many of its services and daemons within https://wiki.freebsd.org/Jails.

In relation to this topic, I'd like to ask what's the rationale for running certain daemons as root when they don't need to. Notable examples are:

- lighttpd
- php-cgi
- suricata
- openvpn

Thank you
#4
Some further information and questions. By looking at the igmpproxy opnsense port, it seems we're using the official v0.1 release https://github.com/opnsense/ports/blob/master/net/igmpproxy/distinfo.

Digging through the code I figured that the disabled interface state is completely ignored and that the default state is downstream. This seems to have been fixed after the v0.1 release in this commit: https://github.com/pali/igmpproxy/commit/85e240727305b156097ee7aa0f0c4473a136291f
#5
Hello everybody,

I'm replying here because I have the feeling this is the same issue I'm facing. I'll promptly open a new thread otherwise.

IGMP Proxy has been working flawlessly until today that I setup OpenVPN server. The issue seems to be that the igmpproxy.conf file doesn't explicitly ignore the ovpns1 virtual interface and thus fails on startup with the following:

adding VIF, Ix 0 Fl 0x0 IP 0x0101a8c0 igb0, Threshold: 1, Ratelimit: 0
        Network for [igb0] : 192.168.1/24
        Network for [igb0] : 232/8
adding VIF, Ix 1 Fl 0x0 IP 0x0100000a igb2, Threshold: 1, Ratelimit: 0
        Network for [igb2] : 10.0.0/24
adding VIF, Ix 2 Fl 0x0 IP 0x01000a0a ovpns1, Threshold: 1, Ratelimit: 0
        Network for [ovpns1] : 10.10.0.1/32
There must be at least 2 Vif's where one is upstream.


Disabling the OpenVPN server solves the issue. What's the right way to fix this? What's the right temporary solution without having to disable OpenVPN?

Thank you