On 30 Jul 2003, Aleksander Demko wrote: > Paranoid? I guess, but we didn't see a need to make outbound connections > so we blocked them off. If the machine is haxxored this way, it can't be Well, now there is a need, right, for at least one more port...:-) > used as a jump point to other machines (either to DoS or just to > mislead). In case it's not obvious, the machine itself does not do the > blocking, but the router in front of it. Also, I don't control the > networking here, just the Linux boxes, and that's the way the law was > laid down :) > > You should see the iptables I have on my home box. And the chroot > jails... I can't wait until linux-uml makes it back into RH kernels. Ya, but remember, security measures are ALWAYS a cost-benefit tradeoff. When they start to cost more energy than (probability of a successful exploit)*(time/energy required to restore system in the event of a successful exploit) then you may be safe, but you aren't optimal (noting that this is oversimplified and assumes that the systems in question contain no trade secrets, personal records, or other data with a nonlinear cost penalty associated with a successful crack, but with a webserver this is likely to be the case). However, as you say you may not control the routing or networking. Still, blocking all OUTGOING traffic is fairly uncommon for a firewall -- usually one wants to hide the inside from the outside, but not make it insanely difficult for those inside (who presumably own the domain and want to use the internet) to access outside resources. What about e.g. ssl, imap, ntp, named, popX, https, etc? There are all sorts of services somebody inside might want to use outside, actually. Even if one wants to enable them on a case by case basis on general principles, it should be fairly easy to have a hole drilled anywhere you need it, once it becomes obvious that having the port blocked costs more energy than the marginal security that blocking it provides. > > Given a system myhost from which rsync to the repository you wish to > > mirror works (according to the test Seth mentioned earlier) rsynchost, > > connect to the insanely paranoid server myserver that regulates > > outgoing port connections (which could only be made, deliberately, by > > its systems staff): > > > > ssh -l root 873:rsynchost:873 myserver > > Yeah, I figured I could do a hardwired -R trick. But it becomes tedious > now as it's host by host. Good to know though. > > I've used hardwired tricks to access (internal) flexlm based licenses > servers from a (DMZed) cluster. I didn't like it, and it's not very > scalable. Some programs get confused with the changing of IPs too. All agreed. A total pain (but lifesaving trick:-). But until reliable host authentication comes along so that spoofing no longer works, or ssh-vpn comes along (so one can set up ONE hole with ssh and run a custom vpn through it) it is sometimes the only way. > Hack the source? Run as root? These sound like options of desperation :) Especially compared to just punching an outgoing hole for it to work through at the router level. [How do you guys keep time synchronized? Does nobody in your organization read mail on a server outside the organization?] > I think the most general solution is to have an internal FTP proxy, and > -R over to that, using passive wget/-mirror. Until then, I'll just use > my little python script :) Actually, I think your script is conceptually lovely and a valuable addition to the yum suite anyway. Yum itself ALMOST functions that way already -- it does download all the headers and caches all the packages. I've used yum and an NFS shared cache to de facto create a shadow repository to avoid hammering my home DSL link (updating 8 hosts through it without sharing means transferring and storing 8x the number of update images). A script could actually convert the cache structure itself into a (restricted) "mirror", but your script will do it better and more naturally and will encourage the creation of "clone" yum-suck repositories. > Yeah, but I don't control the firewall and would have a tough time > selling any plan that requires punching holes in the firewall. Sigh. Punching holes from the inside out? I fail to see how this protects you in any way that compensates, value-wise, for the incredible PITA of punching holes in it anyway with tools like ssh. But you have to live with what you have to live with... rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
