Harald Schioeberg wrote: > >> >> There would also have to be an ACL (Access Control List) such >> that I could regulate who gets access to these boards. >> I could use some suggestions on iptables rules for this >> (embedded) DMZ. I have spoken to several folks in the past that >> have tried this, and maintaining security is always a challenge. >> So a limited ACL in the beginning until the security mechanisms >> mature, is a prudent step. > > > Hi, > > here comes my experience with a similar configuration (not developers > but students with root-privileges, even worse :)) > > a stepping-stone host with ssh-logins for outside devs. this is the only > system, that accepts connections from outside, the firewall blocks any > attempt to connect to any embedded system directly. we even have our > devices in a network with private ip-addresses, with no routing at all > to or from the internet, the steppingstone has 2 nics, one with a public > IP for ssh-login, and one with the private ip. it does NOT do any > routing or NAT. the private IP-config will probably not work for you, > because: > > the dev systems probably need outgoing http/ftp/rsync if not more. block > smtp at all costs. if you need mail for debugging the embedded systems, > configure your stepping-stone so that it accepts mails for your > dns-zone, and delivers it locally, but do not forward any mail from the > dev-dmz. if you only want to support one system (say gentoo) you might > get along with a local gentoo-mirror, but development is really > cumbersome if people don't have http/ftp access do download some patches > or whatever. people will start to build ssh-portforwards if you are too > restrictive and that kills any firewall. > > you need ip-switchable powersupply for all dev-systems, these things > will crash and the users need a way to reboot them remotly. > (afair ~300 Euro per 8 devices) > see that you get some with snmp support, then you can write a small tool > that checks against the acl before it reboots the device. > > you need a serial connection to each dev-system. we use terminal-servers > for that purpose. make sure you can break a serial login, users will > forget to log out and block the serial port forever. again, see for snmp > support for that purpose. > (terminal-servers are really expensive, about 150 Euro per port, but you > can use a pc with lots of ports, and use a serial-to-network daemon) > > if multiple devs should be able to share a device, you need some kind of > a reservation system. We started with a wiki, where everyone entered the > devices that he wants to book in a table. that worked amazingly well. > now we have switched to a sql-db, with allows us to restrict the logins > on the devices to that devices, that the user has actually reserved. the > most important thing is that never 2 independant users access the device > at the same time if they want to do things like system configuration > things... > > we provide our users with a tftp-server, that has a writeable directory > for each stepping-stone-user. it is planned to allow the users to > specify a config-snippet for the dhcpd (again, only for such system that > the user has reserved in the db), when this is done there will be > everything a user needs to boot any arbitary system on the device (if > the device is netboot-enabled) > > hope that gives you some ideas, > harald
Hello Harald, This is a wonderful architecture, although I suspect it will take me some time to get things together. I should like to start off with a custom firewall. Currently we only have a single static IP, so I'll have to stick to the four nic (2 DMZs) for now until we add some more static/routable IPs. Give me a little time to get organized. sincerely, James -- [email protected] mailing list
