Question about Data Safety and VPN

I would like to develop a smart sensor, which is an embedded device running linux. The sensors collect the data from the field, then pass the data to the server at the office. To avoid hack and protect data safety, I am thinking about implementing VPN at both the sensor side and server side. Now I have a few questions?

  1. Is VPN the best solution for data security about this type of applications? My application will require about typically 10 sensors, (ax. 100), to be connected to one server, and the data volume is moderate (possibly 10MB data from a sensor per day.

  1. There are quite several VPN technologies available for Linux, say IPSec VPNs (Openswan, KAME), SSL-Based VPNs (OpenVPN), PPTP-Based VPNs (PoPToP), etc. Which seems the best solution for my application in terms of the development cost and maintaince cost?

  2. Does VPN cast any restriction on the Internet protocols used for data communication? For example, HTTP, TELNET, SOCKET, etc. I don't think so, but I want to confirm.

  1. Does email can be used as a cheap replacement of VPN solutions? This way we possibly can take advantage of the security measure of commercial email system, and it is free. What are the pros and cons?

Thank you!

Reply to
like2learn
Loading thread data ...

Somewhat pedantic from me to pick on that, but it can be sort of realtime without too much effort. The sender has just to ensure that the recipient of the smtp transaction is the intended target. Obviously the recipient will have to run an smtp server and its IP address must be somehow known to the sender, whether implied or being listed as the (only) MX record for its own domain etc.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Reply to
Didi

I got little bit confused. Do you think the sender has to know the IP address of the recipient? Can the recipient just provide the email address to the sender? Thanks!

Reply to
like2learn

If you want it to be "real time", only the email address is insufficient. As larwe explained the message can travel through many relaying stations, timing out possibly after days (so the sender won't know whether the message was delivered or failed for days). The only way to for the sender to know the recipient has received its message is to talk directly to it - only in this case it will get instant feedback from the recipient.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Reply to
Didi

VPNs don't place any restrictions on the traffic flowing over them, although the devices terminating them (often firewalls) frequently apply restrictions. But you're mixing different things - HTTP and TELNET are application protocols that run on top of TCP. Sockets is an API for accessing various TCP/IP protocols, like UDP and TCP.

But a real VPN sounds like overkill for this application, not to mention a considerable administrative burden. Why not just an SSL connection? And if you apply a minimal amount of HTTP/HTML formatting around the messages, you could probably adapt any web server to the job of collecting the data.

It can be, assuming you encrypt and sign the mail properly. The biggest issues you will have are reliable and timely delivery. If you can live with some lost and delayed messages, it can certainly be made to work. And you can somewhat minimize those by using your own mail server.

Reply to
robertwessel2

Great! Thanks for sharing.

Reply to
like2learn

A VPN makes sense if you want to make many different connections over the link, or if the connection you want to make has lots of ports. For example, a VPN is useful if the sensor is looking for DNS information from the server as well as passing sensor data back and forth, or if it has to use awkward protocols like NFS or CIFS. It also makes it easy to contact the sensor via telnet or ssh since it is effectively attached to the server's local network.

If you only need a single connection, using an SSL-based protocol is probably the easiest solution (either a custom protocol or a standard one). You can also use ssh as a simple way to tunnel another protocol over a secure connection. If you only have a port or two to tunnel, and it's all tcp/ip, then this is a "lighter" method.

If you choose to go for a VPN then I strongly recommend OpenVPN. It is easy to configure, the client (and server) can run on practically any system, and it has no problem passing through NAT or other routers that can be a challenge with IPSEC VPNs.

Reply to
David Brown

o
d

Isn't it great? Thank you very much for sharing your knowledge!

Reply to
like2learn

That way is rather a theory-only possibility these days, though.

No ISP without a serious death-wish allows private end-users to send SMTP to anyone but the ISP's own servers any more. Zombie botnets used as spam dispensers took care of making that a practical impossibility.

Reply to
Hans-Bernhard Bröker

I know this is how most ISPs work, mine used to be this way until recently as well. They will probably restrict it again (they had a corporate reshuffle recently and some accompanying chaos, probably this is part of it). So it is indeed a method I would not recommend in todays world, it takes unrestricted internet access in order to work - which is unfortunately far from widely available. We have really no way to verify email delivery within less than a week or so in most cases, which can be a pretty major inconvenience.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Reply to
Didi

I've dealt with several (home/residential/personal) ISPs that have allowed ordinary outbound SMTP (port 25) on request. It's very frequently a setting on the router they put in your house, or sometime at their end, and their tech support can usually turn it on. Obviously not a guarantee, but I've done it several times. I=92ve also seen some cases where the normal authenticated SMTP/POP ports (from memory, 587/487??) are open by default. And even if they weren=92t, changing those on your mail server is generally easy enough. And you probably don=92t want to open port 25 for a special purpose like this (unless you=92re using your existing mail server).

But business class internet access never has such a restriction.

Reply to
robertwessel2

Even that doesn't work.

Some mail servers will accept+discard mail to unknown addresses. [That way you can use the SMTP server as a way to test for valid usernames or email addreses.]

The message might also be discarded as spam, lost because a parition or quota is full, or just plain dropped down the drain by the user's MUA.

The only way you know an e-mail was received is when you get a _reply_ from the person to whom you sent it.

--
Grant
Reply to
Grant Edwards

I said "delivered", not received. Once the smtp transaction is complete with no error, the sender knows it has delivered the message.

What the recipient will do with the message it has accepted is another matter, it may delete it instantly or carve it in stone, someone may then read the stone or use it to bang someones head with it.

For the not quite sane application under discussion (delivering some kind of control messages over email, which is pretty much nonsense nowadays), some knowledge of both sides will be anyway needed and how the incoming message is dealt with will be part of the system design job. Then if the purpose of using email is just to have the messages archived on some readily available system (which might even be a sane choice), setting that particular machine up correctly won't be such a huge issue.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Reply to
Didi

Haven't you noticed the amount of spam that is flooding the internet? Almost all ISP's /do/ allow end-users to send SMTP to anyone.

The unfortunate reality is that there a vast numbers of misconfigured Exchange servers out there that are sending SMTP directly to receiving mail servers rather than via their ISP's mail relay servers, and the Exchange server administrators don't have proper routing, mx records, reverse DNS, etc., set up.

(I blame Exchange explicitly here, since it is almost always Exchange servers that are incorrectly configured and/or are missing DNS information. People who install Linux (or other *nix) mail servers typically know much more about what they are doing. The problem is with companies that are big enough to have their own servers, but too small to employ or hire in competent administrators.)

This means there is a great deal of legitimate SMTP traffic around which ISP's have very little control over. There is no way to check it for legitimacy based on the sender addresses and domains.

Add to that the perfectly legitimate use of SMTP from client applications to non-local servers (for example, connecting from a laptop to the company server).

So if an ISP blocks arbitrary SMTP communication, email collapses for their customers. It /could/ be done much better - if server administrators were required to set their dns records appropriately (easy to do, and easy to check), and all servers required user names and passwords (and preferably SSL) for all non-local client connections, then the world could be free of spam and email viruses.

Reply to
David Brown

That is only true if you know 100% that the receiving machine is only ONE actual machine, that does not forward to yet another machine as a cluster/forest/etc..

Also that the machine is not the general machine used for other things as well (even that locations mailstore).

..

Deleivered, only means accepted by the front facing part of the email server, and may not be really delivered and still can be bounced.

Fully delivered means accepted and barring special filtering rules (spam/blocked sender) is guaranteed to be stored at that MTA.

For many years Exchange (and a few others) have the nasty habit of accepting message and depending where the final mailstore of the server is do "Oh shit drop this email into the bit bucket". Most notably for the situations of

Disk drive full Mailbox over quota.

If you are lucky you might get a bounce message, more often than not it drops into a bit bucket. Basically because the actual storing of the message is a secondary phase, after the smtp transaction has closed.

This is quite common, and I have rarely come across good Exchange setups, as management sees "anything on Windows can be setup using wizards".

After actual delivery, anything can happen.

But often archives get forgotten and when someone goes to look at it then finds, we have not had any new messages for 'n' months to find out the disk/mailstore is full or mailbox over quota.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul

y

he

Well yes, knowledge of both sides was implied, perhaps not clearly enough, in my original post.

This can occur, but since knowledge of both sides is necessary anyway it should not be a problem. Then - to completely madden things up - the sender can be made to receive emails (again as a direct server to avoid days' delays) and thus see the bouncing messages... (how far can we push that nonsense I am guilty of originating is yet to be seen :-) )

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Reply to
Didi

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.