Forums

Mature TCP/IP Stack for STM32

Started by Klaus Kragelund September 13, 2013
Hi

We are working on a TCP/IP Gateway. Ideally we would like to use one of the free TCP/IP stacks that ST has made publicly available, but we are also open to 3rd party stacks

We do however no know the maturity of any of the stacks listed at the ST website:

http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1564/PF221027

(click the "Design Resources" tab)

Or should we be looking elsewhere?

Thanks

Klaus
Hi Klaus,

On 9/13/2013 2:13 AM, Klaus Kragelund wrote:
> We are working on a TCP/IP Gateway.
Is this a "generic" gateway? Or, intended for use in a specific sort of application? What do you expect to encounter on each "side"? (presumably, you're looking at IPv4; TCP & UDP??)
> Ideally we would like to use one of the free TCP/IP stacks that ST > has made publicly available, but we are also open to 3rd party stacks > > We do however no know the maturity of any of the stacks listed at the > ST website: > > http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1564/PF221027 > > (click the "Design Resources" tab) > > Or should we be looking elsewhere?
I think you first have to look at what you are likely to encounter for traffic and threats in your environment. A "mature" stack designed for deployment in a benign environment will perform like *crap* in a hostile one. It will typically "assume" too much that can be easily exploited. OTOH, a stack designed for a more hostile environment may impose other usage constraints on your device/system (as it attempts to close some of the doors that a more naive implementation would leave open). You also need to consider the (run time) resources you have available for this part of your project (presumably, the largest part if your device *is* a gateway!). In a resource constrained deployment, a "mature, though naive" implementation can fail miserably -- potentially taking down the entire product in the process. <frown> Sorry not to be of more help. But, treating a TCP/IP stack as a "check off item" is probably not wise in any scenario other than as a "school project". :-/
On Fri, 13 Sep 2013 03:21:39 -0700, Don Y <this@isnotme.com> wrote:

>I think you first have to look at what you are likely to encounter >for traffic and threats in your environment. > >A "mature" stack designed for deployment in a benign environment >will perform like *crap* in a hostile one. It will typically >"assume" too much that can be easily exploited. > >OTOH, a stack designed for a more hostile environment may impose >other usage constraints on your device/system (as it attempts to >close some of the doors that a more naive implementation would >leave open).
I can confirm that you need to consider this. Our PowerNet stack (not free, not in C) http://www.mpeforth.com/powernet.htm has been deployed on devices connected directly to internet feeds. The devices were attacked by port scan attacks within one minute of first connection. PowerNet runs comfortably on STM32 devices. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
On Friday, September 13, 2013 12:21:39 PM UTC+2, Don Y wrote:
> Hi Klaus, > > > > On 9/13/2013 2:13 AM, Klaus Kragelund wrote: > > > We are working on a TCP/IP Gateway. > > > > Is this a "generic" gateway? Or, intended for use in a specific > > sort of application? What do you expect to encounter on each "side"? > > (presumably, you're looking at IPv4; TCP & UDP??) >
It is a Modbus TCP/IP to Modbus RTU (RS485) gateway. It is transparent to incoming traffic
> > > Ideally we would like to use one of the free TCP/IP stacks that ST > > > has made publicly available, but we are also open to 3rd party stacks > > > > > > We do however no know the maturity of any of the stacks listed at the > > > ST website: > > > > > > http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1564/PF221027 > > > > > > (click the "Design Resources" tab) > > > > > > Or should we be looking elsewhere? > > > > I think you first have to look at what you are likely to encounter > > for traffic and threats in your environment. > > > > A "mature" stack designed for deployment in a benign environment > > will perform like *crap* in a hostile one. It will typically > > "assume" too much that can be easily exploited. > >
I saw a presentation of a guy at the DEFCON conference. He used a tool to scan the net for gateways and he found a lot, even without any password protection
> > OTOH, a stack designed for a more hostile environment may impose > > other usage constraints on your device/system (as it attempts to > > close some of the doors that a more naive implementation would > > leave open). >
Yes, that is certainly an important issue.
> > > You also need to consider the (run time) resources you have available > > for this part of your project (presumably, the largest part if your > > device *is* a gateway!). In a resource constrained deployment, a > > "mature, though naive" implementation can fail miserably -- potentially > > taking down the entire product in the process. > >
It only needs to support the gateway, so we guestimate that a Cortex M3 would do the trick Cheers Klaus
On Friday, September 13, 2013 12:43:25 PM UTC+2, Stephen Pelc wrote:
> On Fri, 13 Sep 2013 03:21:39 -0700, Don Y <this@isnotme.com> wrote: > > > > >I think you first have to look at what you are likely to encounter > > >for traffic and threats in your environment. > > > > > >A "mature" stack designed for deployment in a benign environment > > >will perform like *crap* in a hostile one. It will typically > > >"assume" too much that can be easily exploited. > > > > > >OTOH, a stack designed for a more hostile environment may impose > > >other usage constraints on your device/system (as it attempts to > > >close some of the doors that a more naive implementation would > > >leave open). > > > > I can confirm that you need to consider this. Our PowerNet > > stack (not free, not in C) > > http://www.mpeforth.com/powernet.htm > > has been deployed on devices connected directly to internet > > feeds. The devices were attacked by port scan attacks within > > one minute of first connection. > > > > PowerNet runs comfortably on STM32 devices. > >
Ok, I will add that one to the list. Regarding the attacks, our IT guy at one point connected a Windows XP machine to the internet, with no firewall just as a test,.... it was infected and inoperable within 48 hours. Scary Cheers Klaus
In comp.arch.embedded,
Klaus Kragelund <klauskvik@hotmail.com> wrote:
> > Regarding the attacks, our IT guy at one point connected a Windows XP machine to the internet, with no firewall just as a test,.... it was infected and inoperable within 48 hours. Scary >
He was lucky it lasted that long. I think under an hour is not unusual for such a setup. Reminds me of the re-install I did on an XP machine not so long ago. Not wanting to download a virus scanner on another machine and transfer it via USB stick, I decided to download it directly from the manufacturers' website. So I type the URL and another site showed up and the machine started to behave strangely. I had mistyped the URL and had landed on a purposely set up infected page. Sigh, reformat and re-install again... And this time set up security software from USB stick before ethernet is plugged in. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) "To YOU I'm an atheist; to God, I'm the Loyal Opposition." -- Woody Allen
Hi Klaus,

On 9/13/2013 6:14 AM, Klaus Kragelund wrote:
> On Friday, September 13, 2013 12:21:39 PM UTC+2, Don Y wrote:
>>> We are working on a TCP/IP Gateway. >> >> Is this a "generic" gateway? Or, intended for use in a specific >> sort of application? What do you expect to encounter on each "side"? >> (presumably, you're looking at IPv4; TCP & UDP??) > > It is a Modbus TCP/IP to Modbus RTU (RS485) gateway.
Ah! Then you probably *really* want to be sure your gateway can't be "hacked" as there are actuators/mechanisms/sensors on the EIA485 side that could potentially "break REAL things"! Have you considered adding firewall capabilities to this box? BOTH WAYS??
> It is transparent to incoming traffic > >>> Ideally we would like to use one of the free TCP/IP stacks that ST >>> has made publicly available, but we are also open to 3rd party stacks >> >>> We do however no know the maturity of any of the stacks listed at the >>> ST website: >>> http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1564/PF221027 >>> (click the "Design Resources" tab) >> >>> Or should we be looking elsewhere? >> >> I think you first have to look at what you are likely to encounter >> for traffic and threats in your environment. >> >> A "mature" stack designed for deployment in a benign environment >> will perform like *crap* in a hostile one. It will typically >> "assume" too much that can be easily exploited. > > I saw a presentation of a guy at the DEFCON conference. He used a tool > to scan the net for gateways and he found a lot, even without any > password protection
Shodan is your friend (or nemesis! :> ) <https://en.wikipedia.org/wiki/Shodan_%28website%29>
>> OTOH, a stack designed for a more hostile environment may impose >> other usage constraints on your device/system (as it attempts to >> close some of the doors that a more naive implementation would >> leave open). > > Yes, that is certainly an important issue.
Trust me (or not): you want to sort this out *before* you've deployed a "solution". If you later realize you have a problem (too large of an attack surface), you might find the resources that you have available in the device are insufficient for a *real* solution! (i.e., redesign the hardware *and* software instead of just the software -- see below)
>> You also need to consider the (run time) resources you have available >> for this part of your project (presumably, the largest part if your >> device *is* a gateway!). In a resource constrained deployment, a >> "mature, though naive" implementation can fail miserably -- potentially >> taking down the entire product in the process. > > It only needs to support the gateway, so we guestimate that a Cortex M3 > would do the trick
In terms of processing power, yes. My concern is the resources you make available (memory) and how quickly/effectively they can be exhausted if attacked. Ask yourself what the consequences TO YOUR CUSTOMER will likely be if the gateway "dies" -- if you lose IP connectivity to/from the system behind the gateway. Indefinitely. Good luck!
On Friday, September 13, 2013 5:04:38 PM UTC+2, Don Y wrote:
> Hi Klaus, > > > > On 9/13/2013 6:14 AM, Klaus Kragelund wrote: > > > On Friday, September 13, 2013 12:21:39 PM UTC+2, Don Y wrote: > > > > >>> We are working on a TCP/IP Gateway. > > >> > > >> Is this a "generic" gateway? Or, intended for use in a specific > > >> sort of application? What do you expect to encounter on each "side"? > > >> (presumably, you're looking at IPv4; TCP & UDP??) > > > > > > It is a Modbus TCP/IP to Modbus RTU (RS485) gateway. > > > > Ah! Then you probably *really* want to be sure your gateway > > can't be "hacked" as there are actuators/mechanisms/sensors > > on the EIA485 side that could potentially "break REAL things"! > > > > Have you considered adding firewall capabilities to this box? > > BOTH WAYS?? >
Well, kind of. I'm just a HW guy, so I will not be the know it all one, but we will have consultants doing the code, and then I really need to understand what they are up to ;-)
> > > > It is transparent to incoming traffic > > > > > >>> Ideally we would like to use one of the free TCP/IP stacks that ST > > >>> has made publicly available, but we are also open to 3rd party stacks > > >> > > >>> We do however no know the maturity of any of the stacks listed at the > > >>> ST website: > > >>> http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1564/PF221027 > > >>> (click the "Design Resources" tab) > > >> > > >>> Or should we be looking elsewhere? > > >> > > >> I think you first have to look at what you are likely to encounter > > >> for traffic and threats in your environment. > > >> > > >> A "mature" stack designed for deployment in a benign environment > > >> will perform like *crap* in a hostile one. It will typically > > >> "assume" too much that can be easily exploited. > > > > > > I saw a presentation of a guy at the DEFCON conference. He used a tool > > > to scan the net for gateways and he found a lot, even without any > > > password protection > > > > Shodan is your friend (or nemesis! :> ) > > > > <https://en.wikipedia.org/wiki/Shodan_%28website%29> > >
Exactly, that was the tool :-)
> > >> OTOH, a stack designed for a more hostile environment may impose > > >> other usage constraints on your device/system (as it attempts to > > >> close some of the doors that a more naive implementation would > > >> leave open). > > > > > > Yes, that is certainly an important issue. > > > > Trust me (or not): you want to sort this out *before* you've deployed > > a "solution". If you later realize you have a problem (too large > > of an attack surface), you might find the resources that you have > > available in the device are insufficient for a *real* solution! > > (i.e., redesign the hardware *and* software instead of just the > > software -- see below) > > >
Good point
> >> You also need to consider the (run time) resources you have available > > >> for this part of your project (presumably, the largest part if your > > >> device *is* a gateway!). In a resource constrained deployment, a > > >> "mature, though naive" implementation can fail miserably -- potentially > > >> taking down the entire product in the process. > > > > > > It only needs to support the gateway, so we guestimate that a Cortex M3 > > > would do the trick > > > > In terms of processing power, yes. My concern is the resources > > you make available (memory) and how quickly/effectively they can be > > exhausted if attacked. > > > > Ask yourself what the consequences TO YOUR CUSTOMER will likely be > > if the gateway "dies" -- if you lose IP connectivity to/from the system > > behind the gateway. Indefinitely. >
I have noted your valuable comments, thanks :-) Regards Klaus
Hi Klaus,

On 9/16/2013 12:28 PM, Klaus Kragelund wrote:
> On Friday, September 13, 2013 5:04:38 PM UTC+2, Don Y wrote: >>> It is a Modbus TCP/IP to Modbus RTU (RS485) gateway. >> >> Ah! Then you probably *really* want to be sure your gateway >> can't be "hacked" as there are actuators/mechanisms/sensors >> on the EIA485 side that could potentially "break REAL things"! >> >> Have you considered adding firewall capabilities to this box? >> BOTH WAYS?? > > Well, kind of. I'm just a HW guy, so I will not be the know it all > one, but we will have consultants doing the code, and then I really > need to understand what they are up to ;-)
Forget the technical issues, for the moment. Think of where your device will be deployed. The sorts of things on each *side* of it. What is the risk you expose yourself (or your customers) to if some "adversary" can breach your device and talk directly to the things on the other side? E.g., if one side is *an* internet (even if it is not *THE* Internet) and the other side is an industrial control system, could someone potentially screw up the operation of that industrial control system from "outside" (i.e., some disgruntled employee sitting in his office cubicle pushing commands THROUGH your gateway maliciously). Further, consider if one or more of these "sides" goes through some *other* gateway to "places beyond" (e.g., The Internet). In effect, potentially exposing your innermost network to some outside hacker. (Don't count on your corporate firewall to protect your internal internet and, thus, your gateway and the industrial control system beyond. An adversary can install a device *inside* your corporate firewall by which he can effectively *be* inside your firewall -- even though physically located OUTSIDE it! I.e., if one of your employees sitting in a cubicle can hack your system, then someone outside the building could, also!)
>> Trust me (or not): you want to sort this out *before* you've deployed >> a "solution". If you later realize you have a problem (too large >> of an attack surface), you might find the resources that you have >> available in the device are insufficient for a *real* solution! >> (i.e., redesign the hardware *and* software instead of just the >> software -- see below) > > Good point
If you are the hardware guy, the software guys may have a lot of leverage by claiming that they're 8 months pregnant and *could* finish IF the hardware was enhanced. Suddenly, *you* are the critical path! :< Good luck! --don