Mature TCP/IP Stack for STM32

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??)

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.

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". :-/

I can confirm that you need to consider this. Our PowerNet stack (not free, not in C)

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

It is a Modbus TCP/IP to Modbus RTU (RS485) gateway. It is transparent to incoming traffic

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

Yes, that is certainly an important issue.

It only needs to support the gateway, so we guestimate that a Cortex M3 would do the trick

Cheers

Klaus

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

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

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

Shodan is your friend (or nemesis! :> )

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)

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!

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 ;-)

Exactly, that was the tool :-)

Good point

I have noted your valuable comments, thanks :-)

Regards

Klaus

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!)

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