Products > Embedded Computing

Running a web server on an embedded system - risky?

<< < (6/7) > >>

dunkemhigh:

--- Quote ---It's an embedded Linux board based on TL-W703 exposed to the internet
--- End quote ---

Frankly, I wouldn't expose anything to the internet except a firewall at the router. One of the block lists my router subscribes to shows 78,143 connection attempts since midnight. Another, that is created from failed POP3 and SMTP logins here, shows 13,935 attempts.

Nominal Animal:
DiTBho's and dunkemhigh's observations are the exact reason why I've been considering an insta-banner due to a connection attempt on specific ports on my intertubes-facing embedded devices.  It's simple, fast, extremely lightweight (runtime footprint just kilobytes!) and catches all automated attempts.  The idea is that a connection attempt to any of the specified standard ports causes the IP address to be blackholed for a specific duration, duration depending on the port.  (For example, an SSH, SMTP, POP3, or IMAP access attempt is critical and I'd ban that IP for 24 hours at least, but a HTTP access is semi-understandable, so maybe blackholing for just 15 minutes might suffice.)

The problem I'm trying to find a non-kernel-based solution is to avoid replying with a TCP ACK, and instead of treat the TCP SYN packet (to a standard port) as sufficient for the IP blackholing.  I can do that if I install a firewall rule to log such TCP SYN (and/or UDP packets), but I'd like something more robust; that if the userspace part keels over, it just stops adding new blocks and removing old ones, instead of rendering the entire system unstable/nonworking.

(Blackholing the source IP address based on a TCP SYN means the attacker gains zero information from the server: it never receives any kind of responses to its TCP connection attempts.  Blackholing or dropping UDP packets does the same for UDP connection attempts.)

In general, reverse proxying is a good option for when one can secure the physical network, and have a firewall (and reverse proxy) at the connection point to external untrusted networks.  Then, the internal traffic is unencrypted, but external access only when using an encrypted connection.  For HTTP protocol, a simple HTTPS reverse proxy works very well; for pure TCP/IP and UDP/IP based protocols, set up a VPN.

dunkemhigh:
From my logs, what often happens is some IP attempts access and seconds later, often not quite a second, another IP from somewhere else in the world tries the same with a slightly different username. It's quite common for mail servers to blackhole addresses after n login attempts, so I presume this is a way of getting around that. It's just a distributed botnet.

There are legitimate reasons for strange systems connecting to me - I run a local mail server and DNS, for instance, so the failed logins let me block those IPs across all port on the basis that that IP is a rum one. Generally, I block the entire CIDR allocation just to be sure since some, no names mentioned OVH, seems to be legit servers at a data center rather than random end user systems. Mind, just blocking an entire country seems to do wonders sometimes :)

peter-h:
But... how do you implement all that in an embedded system?

If you are running something big then the invisible google recaptcha is very good at blocking bots, but still they get in.

I think anybody running an embedded server (some product with a small CPU, not much RAM, etc) on an open port needs to have a firewall in front of it. Not publishing a DNS for it will help, a bit...

The earlier suggestion of limiting the permitted source IP to some IP and subnet, or an IP range, is feasible. And if the IP was obtained via DHCP then AIUI the box will also get the mask, which then gives it the entire "local LAN" IP range.

dunkemhigh:

--- Quote ---an embedded server (some product with a small CPU, not much RAM, etc) on an open port needs to have a firewall in front of it
--- End quote ---

Yes, which would normally be a router. Just having only a specific port contactable would do a lot, but after that you're essentially going to be reliant on user authentication - a firewall is going to let stuff through at some point which you'd've preferred it not to.


--- Quote ---limiting the permitted source IP to some IP and subnet
--- End quote ---

That would be good if it's just local access. You don't need DHCP for that - the device will need to know the netmask however it's configured. If you need remote access, perhaps a VPN would be a better bet than letting off-LAN access direct to the device.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version