Xref: utzoo comp.dcom.modems:9124 alt.security:2103 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!bu.edu!stanford.edu!msi.umn.edu!sctc.com!stachour From: stachour@sctc.com (Paul Stachour) Newsgroups: comp.dcom.modems,alt.security Subject: Re: Remote access to modem (was re: security functions in modems) Message-ID: <1991Apr6.223308.12510@sctc.com> Date: 6 Apr 91 22:33:08 GMT References: <1991Apr4.144615.22814@dce.ie> <1991Apr5.215301.13807@netcom.COM> Organization: SCTC Lines: 43 urlichs@smurf.sub.org (Matthias Urlichs) writes: >In alt.security, article <1991Apr5.215301.13807@netcom.COM>, > gandrews@netcom.COM (Greg Andrews) writes: >< >< Access to the modem wouldn't compromise security on the computer. >< If you give the matter some thought, the worst thing that can happen >< is the caller could screw up your modem settings. Big Deal. That >< still won't allow them into the computer. >< ..... >Moral: Configure your modems so that they can't be configured remotely. >Or at all, if possible (AT&B ?). However, how do you **KNOW** they can't be remotely configured. We found out several months ago (when we had a modem problem and called the manufacturer) that the manufacturer had built a trap-door access into his modem software to enable him to diagnose modem software problems. Unfortunately, it also enabled him to re-configure our modems from his site, thus effectively negating any of the security that we had "prgrammed" in from our side. ==== Moral to buyers: Make sure your modems you buy to enhance your security don't in fact lower it. Moral to developers: If you feel you should / must / ... place a test-mode into your equipement, make sure you do it such a way that: a) Your customer can control whether it is on or off b) You can't remotely control test-mode from the front-end c) You document your back-door access test-mode. ==== We were unhappy. We're not using that setup anymore. ..Paul -- Paul Stachour SCTC, 1210 W. County Rd E, Suite 100 stachour@sctc.com Arden Hills, MN 55112 [1]-(612) 482-7467