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.

2. 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?

3. 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.

4. 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!

On Sep 28, 12:46=A0pm, like2learn <gpsabo...@yahoo.com> wrote:

> 1. Is VPN the best solution for data security about this type of
> applications? My application will require about typically 10 sensors,

As with anything else, you need to evaluate how attractive a target
you present to an attacker (i.e. how much time/effort is it worth
their while to spend on hacking) vs the cost of a successful attack,
and the cost consequences of the technology measures required to avoid
such an attack. Also some thoughts about the mode of attack are
useful. For instance, simply rate on a scale of 1-4 ("no issue/slight
annoyance/costs money/kills people") the consequence of various grades
of attack:

a) Someone wiretaps and decodes the sensor readings, thereby learning
a secret.
b) Someone intercepts sensor readings, thereby preventing your home
base from getting up-to-date info.
c) Someone sends fake sensor readings to your home base, thereby
polluting your records.
d) Someone pretends to be a sensor, connects to your home base, and
exploits some unpatched vulnerability in the server software, thereby
bringing it down or stealing a customer database, or installing a
virus that makes every computer in the office visit Venezuelan porn
sites every hour on the hour.

Next look at the capabilities of the node in its current form. What
unused resources does it have? Will selecting a specific security
technology require a hardware upgrade, or is the additional overhead
"lost in the noise" of the node's current functionality?

What is your strategy for recovering from a node that "goes
rogue" (i.e. its authentication credentials are cloned and used by an
attacker)? Is your recovery strategy from such an attack to revoke the
credentials of that one sensor, or to require a firmware update be
applied to every sensor in the universe?

Are there export/other regulatory restrictions that constrain the
types of encryption you are permitted to use?

These are the absolute bare minimum questions you need to answer
before being able to ask the truly intelligent questions about what
encryption technology to employ.

> 3. 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.

In a nutshell, no.

> 4. Does email can be used as a cheap replacement of VPN solutions?

You need to answer the questions above. Email is not realtime, it is
not guaranteed delivery (who knows how many MTAs are between the node
and the destination?), and even if encrypted and/or signed it is
vulnerable to traffic analysis (due to unencrypted header
information), which might or might not be an issue in your
application. As a random example, some customer might not be
comfortable with the idea that his ISP - and everyone on his local LAN
segment - can plug in Wireshark and immediately know that he just
bought an Internet-connected sex toy that is sending personal
preference info back to your home base every ten minutes.

On Sep 28, 8:06=A0pm, larwe <zwsdot...@gmail.com> wrote:
> ...
> ..Email is not realtime, it is
> not guaranteed delivery (who knows how many MTAs are between the node
> and the destination?),
> ...

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

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

On Sep 28, 11:06=A0am, larwe <zwsdot...@gmail.com> wrote:
> On Sep 28, 12:46=A0pm, like2learn <gpsabo...@yahoo.com> wrote:
>
> > 1. Is VPN the best solution for data security about this type of
> > applications? My application will require about typically 10 sensors,
>
> As with anything else, you need to evaluate how attractive a target
> you present to an attacker (i.e. how much time/effort is it worth
> their while to spend on hacking) vs the cost of a successful attack,
> and the cost consequences of the technology measures required to avoid
> such an attack. Also some thoughts about the mode of attack are
> useful. For instance, simply rate on a scale of 1-4 ("no issue/slight
> annoyance/costs money/kills people") the consequence of various grades
> of attack:
>
> a) Someone wiretaps and decodes the sensor readings, thereby learning
> a secret.
> b) Someone intercepts sensor readings, thereby preventing your home
> base from getting up-to-date info.
> c) Someone sends fake sensor readings to your home base, thereby
> polluting your records.
> d) Someone pretends to be a sensor, connects to your home base, and
> exploits some unpatched vulnerability in the server software, thereby
> bringing it down or stealing a customer database, or installing a
> virus that makes every computer in the office visit Venezuelan porn
> sites every hour on the hour.
>
> Next look at the capabilities of the node in its current form. What
> unused resources does it have? Will selecting a specific security
> technology require a hardware upgrade, or is the additional overhead
> "lost in the noise" of the node's current functionality?
>
> What is your strategy for recovering from a node that "goes
> rogue" (i.e. its authentication credentials are cloned and used by an
> attacker)? Is your recovery strategy from such an attack to revoke the
> credentials of that one sensor, or to require a firmware update be
> applied to every sensor in the universe?
>
> Are there export/other regulatory restrictions that constrain the
> types of encryption you are permitted to use?
>
> These are the absolute bare minimum questions you need to answer
> before being able to ask the truly intelligent questions about what
> encryption technology to employ.
>
> > 3. 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.
>
> In a nutshell, no.
>
> > 4. Does email can be used as a cheap replacement of VPN solutions?
>
> You need to answer the questions above. Email is not realtime, it is
> not guaranteed delivery (who knows how many MTAs are between the node
> and the destination?), and even if encrypted and/or signed it is
> vulnerable to traffic analysis (due to unencrypted header
> information), which might or might not be an issue in your
> application. As a random example, some customer might not be
> comfortable with the idea that his ISP - and everyone on his local LAN
> segment - can plug in Wireshark and immediately know that he just
> bought an Internet-connected sex toy that is sending personal
> preference info back to your home base every ten minutes.

Good thought! Thank you for the help.

On Sep 28, 11:26=A0am, Didi <d...@tgi-sci.com> wrote:
> On Sep 28, 8:06=A0pm, larwe <zwsdot...@gmail.com> wrote:
>
> > ...
> > ..Email is not realtime, it is
> > not guaranteed delivery (who knows how many MTAs are between the node
> > and the destination?),
> > ...
>
> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Transgalactic Instruments
>
> http://www.tgi-sci.com
> ------------------------------------------------------http://www.flickr.c=
om/photos/didi_tgi/sets/72157600228621276/

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!

On Sep 28, 9:13=A0pm, like2learn <gpsabo...@yahoo.com> wrote:
> On Sep 28, 11:26=A0am, Didi <d...@tgi-sci.com> wrote:
>
>
>
> > On Sep 28, 8:06=A0pm, larwe <zwsdot...@gmail.com> wrote:
>
> > > ...
> > > ..Email is not realtime, it is
> > > not guaranteed delivery (who knows how many MTAs are between the node
> > > and the destination?),
> > > ...
>
> > 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.
> ....
> 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!

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

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

On Sep 28, 11:46=A0am, like2learn <gpsabo...@yahoo.com> wrote:
> 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.
>
> 2. 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?
>
> 3. 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.


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.


> 4. 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?


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.

On Sep 28, 1:13=A0pm, "robertwess...@yahoo.com"
<robertwess...@yahoo.com> wrote:
> On Sep 28, 11:46=A0am, like2learn <gpsabo...@yahoo.com> wrote:
>
>
>
>
>
> > 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.
>
> > 2. 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?
>
> > 3. 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.
>
> VPNs don't place any restrictions on the traffic flowing over them,
> although the devices terminating them (often firewalls) frequently
> apply restrictions. =A0But you're mixing different things - HTTP and
> TELNET are application protocols that run on top of TCP. =A0Sockets 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. =A0Why not just an SSL
> connection? =A0And 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.
>
> > 4. 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?
>
> It can be, assuming you encrypt and sign the mail properly. =A0The
> biggest issues you will have are reliable and timely delivery. =A0If you
> can live with some lost and delayed messages, it can certainly be made
> to work. =A0And you can somewhat minimize those by using your own mail
> server.- Hide quoted text -
>
> - Show quoted text -

Great! Thanks for sharing.

On 28/09/2010 18:46, like2learn wrote:
> 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.
>
> 2. 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?
>
> 3. 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.
>
> 4. 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!
>

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.

On Sep 28, 1:53=A0pm, David Brown
<david.br...@hesbynett.removethisbit.no> wrote:
> On 28/09/2010 18:46, like2learn wrote:
>
>
>
>
>
> > 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.
>
> > 2. 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?
>
> > 3. 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.
>
> > 4. 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!
>
> 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. =A0For
> 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. =A0It also makes it easy t=
o
> 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). =A0You can also use ssh as a simple way to tunnel another protocol
> over a secure connection. =A0If you only have a port or two to tunnel, an=
d
> it's all tcp/ip, then this is a "lighter" method.
>
> If you choose to go for a VPN then I strongly recommend OpenVPN. =A0It 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.- Hide quoted text -
>
> - Show quoted text -

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