Bruce could you elaborate more on why you said you should never have IIS and IMail installed at the same time? What problems/syptoms would I see in this case. How is port 80 figuring in Imail (other than webmail, webcalendar)?
I have some issues with mail not getting delivered to users from certain domains; this may be a separate issue, maybe not? Thanks, John On Monday 17 February 2003 08:10 am, you wrote: > Timothy, > > I think you have finally hit on the magic words: "This is a very clean > install, just iis, iMail [and] Sql on the box, as it is to be kept clean > being used as a development server." > > If you are running IMail on the box, then you should NEVER have IIS > installed at the same time. They cannot comfortably share port 80 unless > you go about enabling that setup EXACTLY the right way. > > The other issue here is the SQL install. There are numerous known hackers > issues with both IIS and SQL. > > If you are running Windows NT or 2000, did you REMOVE the EVERYONE group > completely from all of the directory permissions BEFORE you installed > IMail? (see how to do that in the article I have included below). > > The company I own, ChicagoNetTech, recently purchased a company called > Rinella Internet Services. Rinella Internet Services was (and still is) > ruining IMail. We initially thought about switching all of the user > accounts on them to another product and decided against it after giving > IMail a thorough look. In fact, we have been negotiating the purchase of > Rinella for almost 18 months and joined this group as part of our research > on the purchase of the company, > > They also had several problems relating to spam and relaying that were not > totally resolved by just using the built in solutions that IMail provides. > After some substantial research, we found that the server they were running > the IMail software on was providing the opportunity for the hackers and > spammers to get in via the security loopholes in the OS. > > Here is a document from the former head of It Security for the US Secrete > Service that discusses Windows 2000 Security - much of what he says is also > pertinent to Windows NT as well. > > This was originally published in a newsletter that I get from a group I am > a member of and I am passing it on to you (and everyone else on here) > because it is extremely important to have your SECURITY properly setup on > any machine BEFORE YOU INSTALL ANY SOFTWARE on the machine. > > Here's my suggestion to solve your problems: > > 1: Completely wipe the machine of everything. - REFORMAT ALL OF THE HARD > DRIVES and START OVER. > > 2: Install your OS and apply the security instructions included in the > article below > > 3: Install ALL MICROSOFT SECURITY PATCHES > > 4: Install SQL SERVER > > 5: Install SQL SERVER Service Pack III > > 6: Check the Windows UPDATE web site. Scan for UPDATES and install ONLY > the CRITICAL UPDATES. DO NOT INSTALL ANY of the .NET updates. DO NOT > install any of the language packages that you don't absolutely require. > > 7: Get rid of any GAMES, video players, ENTERTAINMENT software, coding > software and any other software that auto-installs on the server and check > for patches AGAIN to make certain you haven't removed anything. Remember, > a server should NEVER be simultaneously used as a workstation. > > 8: REINSTALL Windows 2000 Service Pack 3 - if you have added or changed > anything since your original install, it is quite possible that you have > overwritten some of the updated files. > > 9: Install IMail and configure your main domain. If you have any virtual > domains, then configure them as well. > > 10: Test your IMail server. > > 11: RENAME your GUEST ACCOUNT to something other than guest. > > 12: Do not allow anyone who doesn't absolutely need to log into the server > to have a login on that server that is enabled as a "login locally to > server" account. > > 13: Do not install any shared printers to this machine. It is OK to > install a printer that is located on another machine, but change the > permissions on the printer so that NO ONE can use the printer on the server > except the SYSTEM and the ADMINISTRATOR. > > Bruce Barnes, CEO > Rinella Internet Services, Chicago IL > > > > Here is the article from Mike Mullens, former Assistant Network > Administrator for the US Secret Service. > > REMEMBER - ALWAYS MAKE A BACKUP COPY OF YOUR REGISTRY BEFORE MAKING CHANGES > TO THE REGISTRY! > > --------------------------------------------------------------------------- >- ----------------------- > > PLAY BY THE RULES FOR WIN2K SECURITY > > Security fixes and patches are useless if your Windows 2000 server is > placed on the network without a secure configuration. You can significantly > reduce your server's vulnerability and eliminate denial of service attacks > by following seven simple rules. > > RULE 1 > > Remove all unnecessary programs and Windows Components. You can do this via > the Control Panel's Add/Remove Programs module. (Why patch a service or > program that shouldn't be running in the first place?) > > RULE 2 > > Disable unneeded services. A significant number of services and background > processes are installed and started by default; disable any services that > aren't absolutely necessary for your server's everyday performance. This is > done via the Services module under Administrative Tools. > > For a complete listing of Windows 2000 services and a description of their > purpose, take a look at Microsoft's Glossary of Windows 2000 Services. > http://www.microsoft.com/windows2000/techinfo/howitworks/management/w2kserv >i ces.asp > > RULE 3 > > Change User Rights. By default, User Rights is wide open. Close this hole > with the following recommendations for specifying Group or User rights. > > 1. Access this computer from the network--Remove the Everyone Group and > replace it with a group that's more restrictive, such as Authenticated > Users. [NOTE: Make certain you ADD the AUTHENTICATED USERS group BEFORE > you delete the EVERYONE group, You need to do this with EVERY LOGICAL > DRIVE > > 2. Bypass Traverse Checking--Remove the Everyone Group and replace it with > Authenticated Users. > > 3. Create Permanent Shared Objects--Replace with Administrators Group only. > > 4. Logon Locally--Replace with Administrators by username and Service > Accounts. I recommend by username because this creates an additional > security mechanism in case a rogue user tries to gain console access with a > tool that escalates the user's privilege to Administrator. > > 5. Shutdown System--Replace with Administrators Group only. > > RULE 4 > > Synchronize your clocks and enable auditing. If you're going to compare > logs from different systems after a security incident, all of your systems > must have the same time. Auditing will track changes to your system when > employed properly. At a minimum, audit these events for both Success and > Failure: > > * Account logon events > * Account management > * Directory service access > * Logon events > * Object access (monitor for failure only) > * Policy change > * Privilege use > * Restart, Shutdown, and System > > RULE 5 > > Disable unnecessary file sharing. Unless absolutely necessary, remove > hidden drive letters and remote admin shares (ADMIN$, C$, D$, etc.). To > remove these admin shares permanently, set the registry key AutoShareServer > to 0. This key is found at: > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameter >s > > If the key isn't present, add a value of type REG_DWORD and set that to 0. > This permanently disables all automatic hidden shares. > > RULE 6 > > Set and enforce strict file level and registry permissions. Go through your > directories and verify that only specific groups have access to the > information contained within them. Restrict anonymous users from accessing > the registry. This can be done by a registry key: > HKLM\System\CurrentControlSet\Control\LSA\restrictanonymous > > Or via a Group Policy: > > Group Policy\Computer Configuration\Windows Settings\Security > Settings\Local Policies\Security Options\Additional restrictions for > anonymous connections > > The values for the registry key or the Group Policy Object are: > > 1=Do not allow enumeration of SAM accounts and shares. > 2=No access without explicit anonymous permissions. > > RULE 7 > > Minimize your servers' exposure to denial of service attacks. Windows 2000 > allows you to adjust the TCP/IP parameters to have greater control over > connection state. Take advantage of this by modifying the following hive > with these registry entries: > > HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters > > 1. SynAttackProtect: REG_DWORD=2. Drops third packets of the TCP/IP > handshake in an attempt to consume available session handles. > > 2. TcpMaxHalfOpen: REG_DWORD=500. Limits the number of half-opened TCP > sessions. > > 3. EnablePMTUDiscovery: REG_DWORD=0. Prevents the use of nonstandard Path > Maximum Transmission Unit size for all external connections. > > 4. Netbt\Parameters\NoNameReleaseOnDemand: REG_DWORD = 1. Prevents an > external host request for the server's NetBIOS name. > > 5. EnableDeadGWDetect REG_DWORD = 0. Prevents a server from switching > gateways and allowing an attacker to hijack a session. > > 6. EnableICMPRedirects: REG_DWORD = 0. Prevents an external host from > modifying the server's routing table. > > 7. DisableIPSourceRouting: REG_DWORD=1. Disables client source routing > attempts. > > Patching a poor configuration is useless until you add the first layer of > security to your operating system: Locking down the operating system is the > start of any deployment. After your operating system is secure, verify that > your server isn't listening on any ports that aren't integral to its > day-to-day operation and block all nonessential traffic from the Internet > to your system. Security is a layered approach, and this list is by no > means complete. But it's a start to hardening Internet-exposed servers. > > NOTE: Be sure to back up the registry before editing it so that you can > restore it if something goes wrong. > > Mike Mullins has served as a database administrator and assistant network > administrator for the U.S. Secret Service. He is a Network Security > Administrator for the Defense Information Systems Agency. > > --------------------- > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Timothy > Hunold-Cre8ive guy > Sent: Monday, February 17, 2003 00:57 > To: [EMAIL PROTECTED] > Subject: RE: [IMail Forum] imail, meltdown > > > Weblogs just show me logging in, or trying to, that is when I realized that > my web was down. Why would a dictionary attack cause web to crash, it would > be more efficient to do it via pop3... You would have to be doing post > commands all day long. > > Why google? I would get vague info... The specific info I am seeking is as > it pertains to imail. I had used Kendra, and other dictionary attacks to > test my own servers back on v6.04... but at the same time, that was not > spawing email. I have all mail cc'd to another account, and I get all sorts > of stuff on Chinatimes, and other far eastern asia related topics. Seems > like it is relaying, and even if it is a dictionary attack, I find think it > might take about 100 years to reach my password in mixed case, and it also > is an acronym for a very highly specific industry term, along with a > sequence of numbers. It is the kind of thing that will never occur in any > language. > > I guess it sounds like a game of who can hold their breath longer. But in > the meantime, my server has been under attack for 2 weeks. > > I want to know why webmail keeps crashing after i change the ports at > random? > > This is a very clean install, just iis, imail sql on the box, as it is to > be kept clean being used as a development server. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Newland > Sent: Sunday, February 16, 2003 10:38 PM > To: [EMAIL PROTECTED] > Subject: RE: [IMail Forum] imail, meltdown > > > As I said before, you are seeing a dictionary attack, nothing else. There > are several ways to stop or reduce these, just google for dictionary > attack. A 9 meg smtp log file isn't overly large, but in order to "prove" > your original theory correct, we need to see the web logs where your > attacker is doing the attacking..... To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
