[Solved] E-mail WAN IP when changed, with 'mailsend'?

I am searching for the simpler and lighter way to set my Netgear DGN3500 LEDE modem/router send me an e-mail, when my Internet Provider (or a LEDE reboot) changes my WAN (external) IP.
I have never used mailsend before and I have no idea how to write scripts and make them run... Is it possible to set mailsend (or anything simpler and lighter) to read the WAN IP and send me an e-mail when the IP is different than it was before?
It would be nice if the subject could be set to a name that lets us recognize the modem/router, so we can control more than one modem/routers. This name could be also included in the email's content.
Even better if the time of the IP change is in the content, so we know how precise is the service.
If easier, all the information could be only at the e-mail subject.
Thanks to anyone helps!

Lots of possibilities...

https://www.google.com/search?q=monitor+wan+ip+and+email+change&ie=utf-8&oe=utf-8&client=firefox-b-1-ab

1 Like

Dynamic DNS (DDNS) might be what your after.
https://wiki.openwrt.org/doc/howto/ddns.client

1 Like

I'd think twice about any script that requires you to save your username and password, especially on a public-facing device. Mail, unless you run your own servers, is problematic in that way.

Dynamic DNS is one good solution.

I use MQTT to "post" my current lease information where I can get access to it. For the use cases I have, I don't need proactive notification. If the address changes, I can't connect in from the outside at the old address.

I run dhcpcd so my script won't be directly applicable, but it's a straightforward task to hook DHCP lease renewals, or run it periodically.

For MQTT, you might want to look at the Mosquitto library.

1 Like

What is your intention behind this?
Why do you need IP changes to be mailed to you?

1 Like

Much easier, and more secure than setting up your router with an email account.

If your IP changes, this information in the email will be inaccurate and depends on many factors out of your control (e.g. the upstream router equipment). You would see multiple timestamps in the email that don't clearly articulate your "precise" reconnect time (i.e. recipient server timestamp, time in body, time on mailsend log, etc.). The most precise time would probably be when the new lease appears in the log.

1 Like

Thank you all, the information you give me make me think again about using DDNS, which I wanted to bypass as a third party service. Also the space for luci-app-ddns + ddns-scripts is almost equal to mailsend, so no reason to invent methods.
My intention is to install luci-ssl-openssl and add .torrents to transmission while I am away, maintain a WLAN Web server (if I ever manage to build it), Wake On Lan devices, see a USB camera(s) on a router etc, while I am away.
I saw https://forum.openwrt.org/viewtopic.php?id=56113, but I am going to have to study, so I probably stay with GUI and LuCI.
I think MQTT would also be an adventure for me.

Have a nice merge!

I agree, that ddns approach is more simple, but I don't think it's more secure - dns can be hijacked on router side or client side and most people use --no-check-certificate in wget or --insecure in curl, because maintaining certificate pool makes it not that simple :slight_smile:

Easy (insecure) example, run "cronab -e" and put:

*/11 * * * * wget -T 5 --no-check-certificate -q -O - 'https://www.duckdns.org/update?domains=mydomain&token=whatevergeneratedthatmaybe&ip='

It updates your dynamic ip every 11 minutes. You need libmbedtls to work with https. Then you have your lede reachable on mydomain.duckdns.org

1 Like

You reach a point of diminishing returns on this quickly. Yes, you should keep your certificates up to date, check CRLs, and have a valid clock on your device. Yes, you should either purchase a certificate with a trusted root or obtain one from a source such as Let's Encrypt when authenticating to servers or clients that are not under your control. Yes, many third-party services also permit the use of self-generated "ssh keys" to authenticate to their services.

Could someone "hijack" your personal domain if you haven't configured the DDNS service to require authentication. Yes. Would someone do that? Open question. Can you avoid the vast majority of that risk through setting up authentication that is unrelated to your personal email credentials or other "sensitive" credentials, yes.

It's relatively straightforward to get CA certificates on your machine; ca-bundle or ca-certificates, for example, show 20170717 as a "version".

1 Like

In reality I think dynamic dns is the way to go. As @jeff says it's easy to get a CA certificate package that mostly eliminates the chance of man-in-the-middle attack, and there are providers of dynamic DNS which use things like OAuth tokens which you can embed in your script, one for each machine that needs a dynamic DNS entry, so that if one machine is compromised you don't give away the castle.

By far, email is easier to spoof, and less reliable and less functional.

1 Like

Hey there.

Actually I didn't fully understand the intention behind all this. Who's accessing the web server, who's looking at the pictures taken from the cameras?

If I'm correct, you don't want to expose anything through HTTPs to the public but only SSH into your network and hop further from there. Maybe make use of SSH port forwarding, so everything connecting to your network needs to go through SSH.

In that case you don't need to rely on any public certificate.

  • If you connect to your home for the first time, yo get asked if you trust the servers fingerprint. Make sure it's really your server you're connecting to by comparing the fingerprint by hand and hit "yes".
  • If you reconnect at a later time, your client still knows your servers fingerprint and just establishes the connection.
  • If someone highjacks DDNS and points your domain name to some other SSH server, your client will notice the SSH keys fingerprint has changed, complain about it and refuse to connect unless you clean up the ~/.ssh/known_hosts file on your client.

If you don't use SSH but e.g. some VPN connection, you surely have certificates on both ends and the connection will refuse to be established if someone makes your DDNS name point to a different IP then your home network.

I'd skip the whole idea of mailing the IP address when it changes and hop over to using DDNS instead.

Security in a private environment isn't done by determining who controls DNS but by trusting the known host on the other side of the wire. That trust isn't granted by knowing names or addresses but by knowing certificates.

That kind of trust, btw. is even used in a public environment. If you e.g. have an app installed on your smart phone provided by your bank, chances are this very app does connect through regular HTTPS to the banks servers but it knows the certificate being used by the response server. So even if you get your smart phone to point the domain name of your bank to an attackers server, your app will refuse connecting since it's not a known certificate. That's called "certificate pinning".
Of course that's way out of scope for what you're trying to do. But it proves having a list of accepted certificates known to the client and just not trusting others no matter if they appear to be valid in terms public trust is a thing in general.

Regards
Stephan.

3 Likes

Yes, the "public certificate authorities" are a major issue. I certainly don't trust them farther than I can throw them, So in fact having ca-certificates from all those public authorities does really nothing much for your actual personal confidence in the security.

On the other hand, as you say, having ssh public/private keys really is something you personally can check. So is certificates issued by you for a VPN.

However, it seems really that the original intent is beyond just accessing one feature. The IP address will need to be known, and so some form of dynamic dns is probably the way to go. The next thing after that is probably best to set up a VPN, either OpenVPN the old standard, or wireguard which is newish but seems quite nice. Then you can connect to your router and have full access to your LAN as if you were at home. The trust and security comes from the VPN, and the information needed to connect comes from DNS where it's normal to expect it to be.

1 Like

Personally, I directly manage the DNS records through my provider's website access. I have an MQTT cron job that posts the current lease to an "outside" server with DNS to handle the potential case of my outside IP changing when I'm not on the inside network. I'd then either use the IP posted with MQTT directly, or edit the DNS by hand. So far, in many years, I haven't had occasion to use it, even with Comcast :wink:

1 Like

It is actually very interesting, that wget (ustream) must now come pre-shipped with some certificates, because it works even witout insecure option, but where are the certificates stored I don't know. I use curl, which I update from certificate pool at https://curl.haxx.se/docs/caextract.html but for some routers curl is too big to flash.

1 Like

After my last post the conversation became too technically advanced for me. These posts confuse me,

given that I have never used certificates and I don' t know how emails sent to me could be stolen (of course I would use a different email account to auto-send the emails).

People connected to LEDE's WiFi, visiting a Web page hosted in the LEDE machine (e.g. restaurant's menu, local information), besides surfing.

I look at the camera(s), from the WAN side.

It's me who connects to the LEDE machine, checking it's setup, but GUI would be easier for me than SSH.
Many thanks for clearing up the structure of the security options, VPN also.

At start I thought that using luci-ssl-openssl and just logging-in would be fine.

If I am not understanding wrong, you have a static IP from your ISP.

Seems that I have road to go before actually implement any of the above, and many tests (including firstboots).

I won't try to tackle all of those, but leaving a username and password on a box that is "doubly exposed" (as it sounds like your wireless will be "public") is unwise. DDNS, properly set up, is likely the easiest to configure and use and provides reasonable security, relative to the risks. I would look through the recent posts of the two authors and make your own decisions about their credibility, especially in relationship to security matters.

My IP address, regrettably, has been at the whim of Comcast for the last several years. It is supplied through DHCP and DHCPv6. I am happy that it has only changed when I changed hardware, which means that I've still got access to the boxes involved. As I have my own domain names, I have control over the DNS server's responses for my domain and can manually manage it through my DNS provider's web interface.

OpenWRT/LEDE is designed to be a router, with some level of protection in its firewall. The "convenience services" that it provides, such as a web server, are intended for private consumption on a relatively benign network, typically in a home or small office environment. Especially as it sounds like you are in a business setting with both "sides" of the router exposed to the general public, running services on the router itself is not a good idea. That you are considering exposing video on the public side of the router, that I am guessing may include images of individuals without their direct consent, is a risk in any location. In the EU, starting on May 25th, you could be liable for 10% of your gross annual income for a violation of the GDPR relative to both the informed consent and protection of personal data clauses.

A wiser approach would be to use the router for its intended task, and run a small server with production-grade software on it, such as nginx. Even something as simple as a Raspberry Pi would likely be sufficient.

You would still need to determine a secure, authenticated, and encrypted method for accessing the video. Without knowing the streaming protocols used by your camera and those supported by your viewing device, it's difficult to make a recommendation. Note that securing the video does not fulfill all the requirements you may be subject to under the GDPR.

2 Likes

I don't know why I have been misunderstood... Besides that nothing will be doubly exposed, I never said that:

Where is the guess that I want to expose images of people without their consent coming from? I just want to watch a place that belongs to me, using the same device that offers features, information and some limited surfing to visitors. I don't know whom you are comparing me with, but I fell offended, because I don't believe I gave the impression of thinking of something immoral. In any case thanks for the help about the technical staff.

My apologies, no offense intended to you. It was a reminder that open forums are just that, open to anyone to register and comment, and that there may be credibility differences among posters who have expressed differing opinions to your questions.

It sounds like I misunderstood

People connected to LEDE’s WiFi, visiting a Web page hosted in the LEDE machine (e.g. restaurant’s menu, local information), besides surfing.

which I suggested to me that you were planning on using the router and access point in a commercial establishment, perhaps a restaurant or guest house. As an individual, you have a little more latitude as far as the regulations about personal information go. Again, nothing personal in the mention of the GDPR; it's a regulation that even some of the largest European companies fail to comprehend, yet virtually all businesses in the EU, large and small, are about to be subject to. It dramatically changes the requirements around gathering consent from people before collecting personal information from them, storing it, or processing it. Video would seem to definitely fall into "the monitoring of their behaviour as far as their behaviour takes place within the Union."

1 Like

Apology is welcome, at the same time I realize that if I don' t describe exactly what I am willing to do, it is easy to give the wrong impression, having myself some responsibility for this.
To be completely clear, I am planing to use the above set-up in a small commercial establishment, but providing self-service, informing customers that the space is video-monitored for their own security, it would be insecure for them entering alone in a public indoors space. At least where I live this method is used at many professional areas. Saying "a place that belongs to me" I should make clear that I mean "not a public place out of the commercial indoors space".
I would like not to tell what exactly is the business about before I do it. If someone thinks about the idea before me and does it in my city, OK. But it is not a restaurant of course :smile:
I promise to mention this if and when it is implemented, it will also be advertising!

Regards

The main technical concern is that the web server software running on a LEDE router is not intended to be publicly accessible, security is inadequate compared to say Apache or nginx or the like.

A good alternative is a VPN, or a server on the LAN running a more robust system, and port forwarding or ipv6 forwarding.

2 Likes