SOGo only on green interface

NethServer Version: 7.9.2009 (final)
Module: SOGo

Hi,

I would like to know if it is possible to configure SOGo to be available only on the green interface? Similar to phpMyAdmin …
Unfortunately, this is not possible in the Cockpit because a port must be specified but it is not possible.

Thank you for your help.

1 Like

SOGo is ‘just’ a webclient for a mailserver. If you only want to use local mail, you can set up your mailserver as a local instance. This also means you can only use (send or receive) email on your LAN, or through VPN if you are remote.
You can set every email address as a local address in the admin interface.

@robb
I don’t want to be able to view the SOGo page in a browser or to log in from the red interface. I use a Let’s Encrypt certificate so I need to open TCP ports 80 and 443 on the router firewall and redirect them to the Nethserver. Then SOGo is available on the Internet. I only want to allow VPN access from the outside to the Nethserver, so I want to restrict SOGo access and login.

I was able to configure this for all other services, and even phpMyAdmin as described.

I am looking for a solution to this.

Thank you for your help.

Then what is the use for SOGo? If you don’t want to use the webinterface, what extra is SOGo going to bring you? Then any mailclient (web or application) is good enough…

Add

Require ip 192.168.1

to /etc/httpd/conf.d/zzz_SOGo.conf in the <Location /SOGO> to allow network 192.168.1.0 only:

<Location /SOGo>
    Require ip 192.168.1
    ProxyPass http://127.0.0.1:20000/SOGo retry=0
    ProxyPassReverse http://127.0.0.1:20000/SOGo
    SetEnv proxy-nokeepalive 1
</Location>

Reload httpd to apply changes:

systemctl reload httpd

To make this change permanent you need a custom template.

I think it’s about allowing SOGo webinterface only for the green network.

1 Like

He just stated he didn’t want to use the SOGo webinterface…

I don’t want to be able to view the SOGo page in a browser

First post:

Full sentence:

@robb
Exactly, I really just want to allow access to SOGo from the green interface …

@mrmarkuz
Thank you for your help but do i want to know if this will not be overwritten during an update?

Yes, you’re right, you need a custom template to make the changes permanent and survive updates.

Create the template-custom dir:

mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf.d/zzz_SOGo.conf

Copy the fragment - this could be an issue when you update SOGo so think about to compare the copied custom template fragment with original one after SOGo updates.

cp /etc/e-smith/templates/etc/httpd/conf.d/zzz_SOGo.conf/10base /etc/e-smith/templates-custom/etc/httpd/conf.d/zzz_SOGo.conf/

In /etc/e-smith/templates-custom/etc/httpd/conf.d/zzz_SOGo.conf/10base add Require ip 192.168.1 at line 81, see SOGo only on green interface - #5 by mrmarkuz

Apply the changes:

signal-event nethserver-sogo-update

@mrmarkuz
Many thanks. In the meantime, I was also looking for a solution to permanent change. :slight_smile: I also came to this solution based on the documentation.

I’m wondering how to fix this by just overwriting <Location … but I can’t find a solution. If that works, I don’t have to pay attention to the changes in SOGo httpd …

Do you have an idea?

For other solutions we need to change the code of nethserver-sogo:

  • Split the original 10base template fragment to have more fragments including for example a fragment 40location to overwrite

OR

  • Add a db prop to change the template as wanted

Unfortunately, this solution does not work. I performed the above steps, ran the

signal-event nethserver-sogo-update

command and restarted the httpd service

systemctl restart httpd.

SOGo is still available from the red interface. I studied the documentation but I see that neither solution is real.
If the SOGo is updated, I will probably have to make the changes to the custom template. I think the developers can solve this and then an update will not cause anyone a problem.

Do you think the developers would solve this?

Thanks and Regards

Did you really test from outside? (via mobile without wifi for example) It may not be enough to just use the public IP. It worked in my test but I’m going to recheck…

That’s not what happened …
I wrote the IP address range of the red interface into the config. :frowning:

I improved and then only the SOGo could be accessed from the green interface.
This is also a problem. I extended the Require IP with the VPN IP address range. SOGo is then also available from the green interface and the VPN.

I sometimes find that the server is not pingable, the cockpit is not available and ssh is not working … I don’t know the reason yet. No network or hardware issues.

I still think this will only work until the first update and only the developers can find a solution …

1 Like

No, a custom template survives updates.

Maybe there’s a high server load when connections are not possible?

And if the config changes? Although this is unlikely … But if I do, I’ll just notice that it doesn’t work … :frowning:

And that’s what I’m thinking, but I can’t solve it yet. It should be SNMP, but I don’t think it responds.
The server fans do not spin up at this time.
I don’t understand the reason yet.

I think it’s not a common case to block a mail webinterface and usually we cover common cases and use custom templates for special cases but you’re right: even with a custom template it’s not perfect.

@stephdl should we implement access restriction for sogo or at least split the /etc/e-smith/templates/etc/httpd/conf.d/zzz_SOGo.conf/10base fragment to make custom templating easier? I’d open the PR…

1 Like

@mrmarkuz

Thank you for your help, patience, and understanding of my problem. I would be very happy if you could change the config by the developers. I also thank the developers in advance for their help and work.

Thanks and Regards

For just one admin case the way is the custom template, it will survive to any modification we could do. Moreover the apache configuration is not much modified by us

What is the behavior of other webmail we propose, can we block to internal network. I am not sure.

Anyway @steve you stated on the solution you want to go but not why you searched that solution.

1 Like

@stephdl

First of all, I apologize, English is not my native language, so complicated dialogue is difficult for me.

What do I want to achieve?

I would like all Nethserver features to be available as an option via the red and / or green interface and / or the VPN connection.

This is important because any public access poses a security risk. It should be up to everyone to decide what access they allow and how. It is advisable to give this option to the admin.

In my specific case, I only want to allow access to Nethserver services on the green interface and the VPN connection.
This is important because the Let’s Encrypt certificate requires TCP ports 80 and 443 to be kept open, but SOGo and Nextcloud can also be attacked. Phpmyadmin is also affected, but it can be configured.

It is a bad habit for attackers to break what is open or available. So if they manage to decrypt the SOGo or nextcloud password, they can cause problems because even others will be available due to the password stored in the LDP.

It is possible to defend against this (fail2ban, Suricata, etc.) but this may make the Nethserver inaccessible and inoperable. I also see this in the logs of my router.

I would like help with this because I would like this not to be solved with custom settings that could cause a problem during an update but it would be part of the system.

I hope you understand what I wrote, but that’s when I need my friend Goole … :slight_smile:

Thanks and Regards and Happy Cristnas for all!