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 
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
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.
1 Like
@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...
3 Likes
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".
2 Likes
@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.
1 Like
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?
1 Like
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.
1 Like
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.
1 Like
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.
2 Likes
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.
2 Likes
This topic was automatically closed after 2 days. New replies are no longer allowed.