John (et al); The issue of iMail and IIS co-existing on a single server is both documented in the manual and has been well discussed (in fact beaten to death - no offense meant to anyone who didn't see or participate in those discussions) on this forum on several occasions. Both the iMail web interface and the IIS web interface use port 80.
Since they both use port 80 for the web interface, you have to jump thru some pretty elaborate hoops to make them work together simultaneously - but that was not the entire reason that I brought up the issue of them being on the same server. The real SECURITY issue for IIS (and SQL Server) is that the security on those two items must be AIR TIGHT or hackers WILL find ways to get around the programs and install programs onto the servers, change security levels and send spam without the server owner ever realizing that it has ever been done. When it comes to security, both IIS and SQL Server have many well known security issues. If you haven't installed ALL of the available patches from Microsoft then your installation of Microsoft's IIS or SQL Server is a sitting duck for a hacker. (see: http://support.microsoft.com/default.aspx?scid=FH;[LN];sp&; and scroll down to the middle of the page where you will find the "Server Products" list) Web servers traditionally have FRONT PAGE extensions or FTP portals for the people who design and host the web sites to send their files up to the server. These present another set of security problems where both programs, viruses and worms can be introduced into the machines. And NO Microsoft based server should ever have TELNET installed or enabled. It cannot be properly secured. Windows 2000 allows the use of Terminal Server for remote access and control and can be installed without the payment of any license or royalty fees if it is used only for administrative accounts. In today's environment, the rule of thumb should be to dedicate servers to a SINGLE JOB and not start mixing the reason's for their existence. If you have a e-mail server, it should do nothing except process e-mail. If you have a web server, it should do nothing except server up web pages. If you have a DNS server, it should do nothing except maintain DNS entries and give out DNS information. We still have one DNS server that we inherited from the old IT staff at Rinella and it is the one that runs iMail for us. They had done no maintenance to the box, never cleaned out any of the files and the main logical drive - the "C" drive was almost completely filled up. We finally cleaned up all of the DNS entries so they had both the "A" and "PTR" records they were supposed to have and the next thing we will do is purchase another box to move the iMail to. The current box is a Dell server with 3 SCSI drives and two 1.4 MHz processors. When the DNS was really busy (we also act as a primary DNS server to several of our clients who run WINS in their networks so it can generate a substantial amount of traffic) and one of our hosted clients would send out a mass e-mail to more than 3,000 recipients (one of our clients, a genealogy group, send out to more than 8,000 recipients on their list at a time), about half the e-mails would never be sent, and about a third would end up in the dead-letter office. Since we cleaned up the trash files, compressed all of the logs we want to keep and deleted the rest of them, we gained back about 1/2 of the "C" drive and there is very little rejection or loss when even the largest of lists gets sent out. Remember, too, that while Microsoft doesn't document this, you must ALWAYS have at least 1/4 of your the drive on which your OS is installed (your ROOT drive) free for the OS to work with any given time. If you get to having less than that on any Microsoft based server, you will notice a considerable slowdown in the machine's performance. If you completely fill up an NT Server's root drive, and shut the machine down, you will never be able to boot the machine again. As a general rule of thumb, I always install a single package to a server. It makes it a little more expensive when you consider the cost of the server and the OS package, but my servers are only down when I am doing maintenance on them and I have only been hacked on one server on one occasion. That was caused when we had a new kid to whom we gave the assignment to do the OS install on the server and he did not follow the checklist that we provided him - he followed the Microsoft instructions. When we looked at the cost of purchasing the hardware and OS, vs the cost of the time spent troubleshooting, chasing problems and otherwise defending ourselves against hackers, the cost of purchasing a separate box and the OS to install won hands down. Install to iMail on it's own server. Get rid of any unnecessary background programs. Run a recommended anti-virus and/or spam program on the iMail box. Run NORTON Corporate Edition on everything else. Run a firewall. Compress the old logs you must keep and delete what you can. Eliminate relaying. Keep the "C" drive clean, with at least 25% free space. Run a good defrag program. LOG EVERYTHING. Set your local security policy to LOCK OUT any account that has more than 3 invalid password attempts in a five-hour period and keep them locked out until you MANUALLY reset them. If you follow these guidelines, you should have very little problems with hackers or viruses. The initial cost will be a little higher, but it will actually SAVE you both time and money in the long run. Bruce Barnes, CEO Rinella Internet Services, Chicago IL In the long run, it's always cheaper to do it right the first time. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John K. Dyer Sent: Monday, February 17, 2003 10:26 To: [EMAIL PROTECTED] Subject: Re: L RE: [IMail Forum] imail, meltdown 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/ 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/
