Ethernet library v raw Internet: Is it suitable?

As the title suggests, I'm wondering whether the Arduino Ethernet library (v2) is actually capable of being placed into an Internet facing situation, long term? What I mean by this is installing it so that all and sundry can access it from the lawless Internet. I don't mean fronting it with a proper web server, but having the Ethernet shield directly exposed via port forwarding through a router.

My concern is abuse, or just over eager bots of all sorts. Things like:-

  • 20 accesses in 1 second
  • GoogleBot sucking it's life out
  • No method requests
  • Malformed URLs
  • 300 character long requests
  • Unexpected POSTs
  • Other evil deeds seen in access log files

I've tried to find one online somewhere, but every time I think I'm onto something I can never connect. They never seem to be up exactly when I go looking. This doesn't fill me with confidence. Is the Ethernet library only suitable for nicey nicey intranet use? Does anyone have experience of a long running Internet facing Arduino server?

As a server, or a client?

Oh, as a server of course :)

The Ethernet library provides the tools. It is up to you to use them to prevent the kinds of abuse you listed.

While there isn’t much you can do about bots queuing up so all the sockets are used, you can serve up a page quickly, so that the bot moves on.

I don’t know how you would EXPECT a POST or GET, so every one is unexpected. You can deal with them.

You know how much data is a reasonable amount. If a request contains 300 characters or more when 10 is reasonable, don’t save the last 290 characters, and serve up an appropriately reply (rudely).

PaulS, not what I meant.

I was referring to the library itself rather than my code. Is it robust? If a 300 character request /packet comes along, it's ingested anyway isn't it as part of the TCP/IP stack. Is the library susceptible to buffer overflows? Do too many concurrent connections cause it to fall over or are they rejected gracefully? SYN flood -> crash? Malformed packets? Has anyone abused Ethernet library and reported back?

The v2 library is v1.04 (strangely) which seems immature. There's only one execution bug listed on Git. The conclusion must be that the code's almost perfect. I see that Tx/Rx buffers are set to 2048 bytes each, but not sure how that fits into the 2K that's available on an Arduino Uno (ref. Ethernet2/src/utility/w5500.h). What other issues might there be?

My only experience is with WebLogic and Tomcat which I can't get to run on an Uno. I don't expect my kit to do lots and lots, but I do expect it to do whatever little, extremely well. Do you (anyone) have any links to online (and working) Arduinos web servers ::)

As for expectations, you'd always expect GETs on a page that hasn't got a FORM element or funky Ajax. How could you POST without being nasty?

Well, my board has been up for three days now continuously. It's dealt with the typical hack attacks like:-

********** new client ************** POST //%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1 Host: -c Content-Type: application/x-www-form-urlencoded Content-Length: 152

client disconnected

which is a bash at php. It seems to handle long POSTs quite well so there doesn't seem to be buffer issue. So far.

It's at if anyone wants a go. It's just a test page with an analogue port reading and millis(). For the science :smiling_imp:

You should never treat any incoming connection as "expected", or in proper terms: "trusted". Every bit of incoming data must be verified, and everything that does not pass verification discarded. That includes the length of incoming requests, which indeed could cause buffer overflows. That's how you prevent most of the attacks.

DOS attacks are much harder to defend against.