Security updates have made me too secure?
![](https://seccdn.libravatar.org/avatar/8f85b7c91adf7c4ee6f793e555b8977b.jpg?s=120&d=mm&r=g)
Help! I have a x86 SUSE 6.1 system running as a gateway/firewall/DNS. There is no keyboard or monitor physically attached to the system, and logons are disabled on the machine. I access it remotely via openSSH, using a root login. This has worked fine for several months now. Today I installed the following security updates: shlibs-2000.9.5-0.i386.rpm libc-2000.9.5-0.i386.rpm libd-2000.9.5-0.i386.rpm nkitb-2000.7.11-0.i386.rpm The system is as stock a SuSE as you can get. The only things installed on it are official SuSE RPMs, and SuSEConfig is configured to run. I just tried to log into it using openssh (1.2.3-12, yes I know there are problems in that version), and when I typed in the root password got told "Permission denied, please try again"! As there is no keyboard / monitor on the machine I don't know if this is an ssh problem, or a more general problem. Does anyone know what might have happened to this system, and is there any way I can get back into it? Some things I can note: 1) Most things appear to be running fine, as my other computers have no problems with routing or DNS resolution through the gateway, and 2) OpenSSH is definitely starting, because I get asked for a password. Thanks, Chris. __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/
![](https://seccdn.libravatar.org/avatar/6f3707b28d8d3fc154ed3d3da38576da.jpg?s=120&d=mm&r=g)
On Wed, 15 Nov 2000 15:00:29 -0800 (PST), you wrote:
As there is no keyboard / monitor on the machine I don't know if this is an ssh problem, or a more general problem. Does anyone know what might have happened to this system, and is there any way I can get back into it?
When remote administration is the only solution (no physical/local access to the machine), you have to take care of certains "critical" changes you could make in order to NOT take the machine into an isolated state :-) For instance, if you want to touch SSH, you could have (temporaly) enabled telnet access (at port 23354, e.g, if you're so paranoid ;-)). Doing so, if SSH crashes when updating, you have the chance to enter machine via telnet and undo changes. The above applies to other similar cases, like managing firewalls. It's a good idea to open a backdoor in fw, at testing/installation phase. I usually include this code at my fw init script: [Definitions] ALL_RELY="192.168.66.66" # Total access for this host (secure mode) SECURE_ADMIN="yes" # Secure mode: yes / no [Begin of fw rules] if [ $SECURE_ADMIN = yes ]; then ipchains -A input -s $ALL_RELY -j ACCEPT ipchains -A input -d $ALL_RELY -j ACCEPT ipchains -A output -s $ALL_RELY -j ACCEPT ipchains -A output -d $ALL_RELY -j ACCEPT ipchains -A forward -s $ALL_RELY -j ACCEPT ipchains -A forward -d $ALL_RELY -j ACCEPT fi In a deny-policy fw, these lines can save your machine from becoming isolated, due to a config error in your fw rules... (deny-fws are specially dangerous because you must specifically grant access to the services you want to provide; all the rest is filtered out. Take care. Anyway, it's the more secure one). Of course, when the test phase finishes, you can turn off "Secure_admin" and the backdoor is closed. Regards. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** roman@madrid.com http://pagina.de/romansoft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
participants (2)
-
Chris Clarke
-
RoMaN SoFt / LLFB!!