You'll want to secure the device with something like the CIS Hardening Guide for whatever comes close to your distro (My Pi runs Raspian, so I used the CIS Debian guide, but there are Redhat or Ubuntu distros for the Pi as well). #Raspberry pi tn5250 passwordMore on the above, no Linux distro is secure out of the gate, least of all the Pi which comes out of the box with default or no credentials (or no password more like).If they've got linux chops, this'll plug right into their ansible/puppet/chef or whatever infrastructure. If the client doesn't have Linux skills in-house, keeping things patched and properly maintained can be a challenge. Disable the Pi's wireless if you're not using it as one of the NICs.It's not the fastest solution - the Pi only supports 100mbps ethernet, and the ethernet NICs are USB based so you won't ever see it reach 100, but for telnet that's fine.A Pi is not the most reliable solution - they boot off of SD cards, and those do fail.In most cases I do this for, all we're shooting for is an SSH gateway solution - backups and other services go out via another path. You can expand this with NAT and port forwarding to expose other services in either direction, depending on your "appetite for complexity". When the user logs in, their session immediately telnets to the back-end device. The linux account that the user will use gets a ".profile" file, which lookslike this:Įxit (which logs out the SSH session when the telnet session ends) Physically, it looks like this - often we'll just velcro the Pi to the host it's protecting, the "Unencrypted DMZ" ends up being a 1 ft ethernet cable: The Pi runs "real" linux, so you can secure it. A Raspberry Pi does a decent job here for less than $100 per node. In some cases, I've front-ended the problem child gear with a cheap SSH gateway. Even finding where all the vulnerable gear is (physically, not on the network) can be a challenge In ICS systems in particular, gear like this is often on the same 5,7 or 10 year depreciation cycle as might be seen on an industrial press or other manufacturing equipment, so upgrades are really a long-term thing, there are no quick fixes. We see this in legacy systems, but in Industrial Control Systems (ICS) that control factories, water or hydro utilities we see this all the time in production - and the answer there is "the gear doesn't support ssh, and in some cases doesn't support credentials". #Raspberry pi tn5250 updateIn the case of the AS400 above, they'd need to do an OS update, which would require an application update to an app they had retired, on a system that isn't production anymore. We've found a telnet service that should be migrated to SSH, but the affected device either doesn't support SSH, or the client for one reason or another can't put resources into enabling encrypted services. Which doesn't really address risk around their client's information on that host. So it was only used occassionally when they needed transaction history from before their migration to the current system. The client's response was that this host was up for history purposes only, it was not longer production system. I recently had a security assessment / internal pentest project, and one of the findings was "I found an AS/400 running telnet services" (actually unencrypted tn5250, but it comes to the same thing)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |