Enter iptables…
Iptables is your firewall, its baked into CentOS, and its extremely powerful. I don’t know the complete depth of iptables but for this tutorial you’ll need to just get a few ports opened up and that’s it.
# iptables -F
# iptables -A INPUT -p udp -m udp –dport domain -j ACCEPT
# iptables -A INPUT -p tcp –dport 22 -j ACCEPT
# iptables -A INPUT -p tcp –dport 10000 -j ACCEPT
# iptables -A INPUT -p tcp –dport 25 -j ACCEPT
# iptables -A INPUT -p tcp –dport 8080 -j ACCEPT
# iptables -A INPUT -p tcp –dport 80 -j ACCEPT
# iptables -A INPUT -p tcp -m tcp –dport domain -j ACCEPT
# iptables -A FORWARD -o eth0 -j LOG –log-level 7 –log-prefix BANDWIDTH_OUT:
# iptables -A FORWARD -i eth0 -j LOG –log-level 7 –log-prefix BANDWIDTH_IN:
# iptables -A OUTPUT -o eth0 -j LOG –log-level 7 –log-prefix BANDWIDTH_OUT:
# iptables -A INPUT -i eth0 -j LOG –log-level 7 –log-prefix BANDWIDTH_IN:

make sure you save your iptables configuration so you don’t have to re-edit it when you reboot your server
# /sbin/service iptables save

now just restart your firewall
# /etc/init.d/iptables restart

now you can check your configuration
# iptables -L -v

at this point, for good measure you might want to reboot your server
# reboot

2 cents here:
- transport-specific security in case devices do not have directly http or ip for that matter on board. This can rely on bluetooth/zigbee mecanisms, but then gateways need to know about each device specifically…

- the encryption on embedded devices, sensor nodes have very limited cpu, so i see complex encoding quite heavy to be computed each time, especially when this happens at a the app level.

An option would be to have a second chip that takes care only of computing the encoding…

anyway, I’m not an expert here, so I can’t say what’s best, but it’s just a matter of adding the limited cpu in the security vs. algo complexity tradeoff.

oh there is this though…

http://research.microsoft.com/en-us/um/people/zhao/pubs/secureTWS_IPSN09.pdf

voilà

At application level, you can have a front authentication module that rely on local user directory (a file, a SQL table, an LDAP directory roughly depending on the volume of users and requests). On a Tomcat (or a J2EE App Server) that’s a filter you had in the configuration, on a PHP server, that is a check to include at the begginning of all pages requiring authentication.

At transport level, you use SSL client authentication to encapsulate your HTTP flow and yay! that becomes HTTPS, you can then benefit from a encrypted connection to enable confidentiality over your data.

I see one problem here but maybe that’s only becauseI tend to be a security freak: anyone can spoof the MAC address of your sensor and contact the WebServices API to upload false information.

I would say that you really need to include some security at the very beginning of the design. Maybe a simple shared secret between a sensor and the WS API (a simple authentication for instance)

Again, I’m a security freak these days ;o) See ya!

cheers
(