I spent much time setting a no-ip.com account, installing luci-app-ddns and finaly found out that 192.168.1.1/cgi-bin/luci/admin/services/ddns/detail/myddns_ipv4 has not a default option for no-ip.com...
There is a no-ip.pl option, I visited the site, but does not seem relative with no-ip.com, so I did not used it to configure DDNS in LEDE.
I selected --custom-- at DDNS Service provider [IPv4], but now a Custom update-script appeared... So I went to the Documentation of no-ip.com, to find that it is hudge and -in parts- inaccurate! See FAQ/Hostname.
Excuse my ignorance, but I prefer not to try DDNS providers now on LEDE.
If someone can answer to the title of the thread, I will be very glad, including directions for the cron part. Thanks everyone, I took much information.
ddns-scripts_no-ip_com, which would have been mentioned in the wiki.
@vasilis74...I think you're missing the point of some of the posters who offered concerns for your legal safety and those of your patrons. Some, you passed off as too technical. Allow me to provide a layman's demonstration of the concern - by showing you a link to poorly configured cam access methods:
The configurations exposing your cameras without things like a VPN or SSH, will expose them. Your streams are likely to appear on sites like this...for anyone on Earth (and above it) to see.
It's sad...you even see some police street cams, nanny cams, bedroom cams...all online...around the globe...
Instructions exist and it's clear that additional package "ddns-scripts_no-ip_com" should be installed, apart from standards "ddns-scripts" and "luci-app-ddns".
@jkoukos You are right, I did not pay much attention as I should. The documentation of no-ip.com made me just try to set-up ddns my self to get it work. Still doesn't, tested with Firefox on Android and data connection. But I wouldn't start a thread to put people teach me how to achieve something that is already documented well.
For me are too technical, but I read the posts more than once. It's another think if I cannot do much before studying a lot. And thanks for the insecam example.
The majority of the opinions point that a WLAN web server on a LEDE device won't be good for publicly accessible use, so orientating to a "real" web server (may be with a WPA2 WLAN PCI card) accessed publicly by WiFi and supervised by professionals (not me) seems one way.
Even for personal use I cannot adopt the script posted at:
as it is, because of:
Notice no space between "-ssmtp.server.com" and mail subject "-f"New_WAN_IP"
cat /mnt/sda1/scripts/email.txt | /usr/sbin/sendmail -ssmtp.server.com -f"New_WAN_IP" my.email@domain.com
I see a space there, how am I sure there are not more mistakes? I don't do scripts, just copy-paste and getting the general image by experience, so I judge simply what I see.
I have seen before commands or scripts posted at forums or guides having a mistake(s), my impression is that this is one of them, maybe I miss something.
One final question, close to the title:
refers to un/pw of the LEDE remote luci-ssl-openssl log-in, or to the sender email account's un/pw in the mailsend script?
I mean, if applys that
luci-ssl-openssl + mailsend (with an extra sender email account) and VPN
is more vulnerable than
(luci-ssl-openssl +) ddns and VPN ?
If not, I am still interested in knowing "how to auto mailsend" my WAN IP for personal experience and use, I hope that space above is the only mistake.
I was referring to
and, or course, any insecure credentials are dangerous. That includes credentials that are stored "encrypted" but with the decryption key there somewhere as well. Passwords, for example, aren't stored on modern systems. What is stored is the result of mixing the password with "salt" and then running it through a "hash" -- you can confirm that someone knows the password, without ever seeing the password itself.
with mailsend you will get an email telling you the ip to connect to. But email is such that ANYONE can send you an email with an ip address in it. How will you know that it did in fact come from your router? You will have to look carefully at the mail headers... and even then how do you know?
Then you go and connect to this ip address, it can easily be a man-in-the-middle... well if you use a VPN or a proper certificate on a proper HTTPS server, then that will help you know that there is no man in the middle. But in general, just remember that ANYONE can send you an email saying anything they like.
On the other hand, usually for dynamic dns the entity trying to change the entry has to have some kind of authentication information. Sure it may be that if someone breaks into your security they could get ahold of that information, but when it comes to sending an email... that is way less of a hurdle, basically no hurdle. If you told me an email address I could easily send you an email with a given content.
At the very least it's harder to do denial of service or fake entry for an authenticated Dynamic DNS entry than it is for "sending an email" or blocking the sending of an email.
EDIT: For example, if I know how your system works and want to screw with it, I could send you thousands of emails each with a different IP address in it. How do you figure out which one to pay attention to?
It's not just you that might be the recipient of hundreds of thousands of messages. Imagine what happens when your router is compromised and they find mailsend or ssmtp or the like in a script with your credentials. "JACKPOT!" -- you become the source of hundreds of thousands of spam messages, and all the undeliverable ones bounce back to your account.
Although that's true about if they get your email credentials, to send yourself an email shouldn't actually require any credentials at all. I send myself emails from monit on my servers all the time, and it's just something like
"echo Message | mail -s 'here's my message' my@email.address"
If you want to send it as yourself through your ISP's email server, then yes you'd need to leave your credentials exposed... very bad idea.
Comcast and probably many other providers block port 25, so any server on "inside" can't sent outbound mail without having an "outside" relay that is on a different port. They're all pretty firm on it. People in my situation need to authenticate or otherwise authorize access to a mail server outside somehow.
Yes, that all may be true. I have certainly used message submission port 587 for sending to get around that kind of thing... it all depends on your ISP. Most of the sending I do from automated sources (servers etc) is from VPS or servers on site at an organization with a commercial internet provider.
Terrifying scenarios!
Obviously besides using a 2nd email account for sending (that would help me know that the emails come from my router), if the router becomes compromised the possible damage is bigger than if I had used DDNS. The damage expands from the hijacked router to the email accounts.
I conclude that for personal use DDNS is much better and for commercial DDNS or static WAN IP by the ISP.
Thank you all for the very detailed explanations.
This topic was automatically closed after 2 days. New replies are no longer allowed.