> Again, not "acting" as an open relay, or did you > actually test to > determine whether it was configured to refuse > attempts to relay. This is one of the things about public lists such as this...getting clarification on issues. Whether the original poster (OP) refrains from posting the specifics due to time/space issues, or due to not knowing, the fact remains that a lot of really useful information is never passed onto the community as a whole. > Another question is how you determined that the > server is actually being used as an open relay. Exactly. For example, my Exchange server is configured to NOT allow relaying. When an attempt occurs, it's logged to the Event Log. From there, I can collect and parse all of these attempts. > > Given the physical security, I can only deduce > that someone > > else took advantage of the weak password security, > and helped > > themselves. > > I assume you meant "given the NETWORK security" as > "PHYSICAL" security > is something completely different. I think that in this case, physical security would apply just as well, particularly in the context. However, you do bring up a good point. Are Event Logs configured to audit failed logon attempts? If so, were there any attempts to login? Explore other avenues by which the relay setting could have been changed. > If, in fact, the firewall is configured as > indicated, and that only > authorized IP addresses from the software vendor's > IP space is permitted > to access pcAnywhere, then it is NOT a trivial hack > to gain access to > pcAnywhere in order to exploit the weak passwords. True. Which is why I suggested that this be verified. Since the client is paying for the management service, they should be able to get a copy of the firewall rulesets for verification. > IMHO, if you are confident that neither the software > vendor nor the > customer made the change (if, indeed, a change was > actually made) then I > would be more concerned about how the intruder > gained access to server in the first place. Good point. Which is why a root cause analysis (RCA), based on *facts*, must be conducted. Far too often, such things are not done, largely due to time constraints. However, back in the "old days" of the Internet, Unix admins took pride in knowing their systems. For whatever reason, it seems to be different with Windows admins (this is NOT a dig at Windows admins, simply an observation from working with them and performing many, many vulnerability assessments). Anyway, just some thoughts...perhaps a bit tangential to the subject. Harlan __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------------- Attend Black Hat Briefings & Training Federal, September 29-30 (Training), October 1-2 (Briefings) in Tysons Corner, VA; the world's premier technical IT security event. Modeled after the famous Black Hat event in Las Vegas! 6 tracks, 12 training sessions, top speakers and sponsors. Symantec is the Diamond sponsor. Early-bird registration ends September 6.Visit us: www.blackhat.com ----------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Sat Aug 23 2003 - 13:44:38 PDT