Tip of the Day - Fleshing out the details in email policy
If for nothing else than as a survival reflex, anti-virus programs exist in most corporate environments. Further, anti-spam programs appear to be gaining ground. This is all good, but there are a few common mistakes that are worth considering as we review the way we implement our email policies. Some of these issues have an impact on the effectiveness of security and other issues are purely operational in nature, but in the end it is usually the security group that will hold the keys to ensuring these details are addressed. Without further ado, here's a few of the often overlooked do's and don'ts for the email world:
DO view emails in plaintext only
As discussed in a previous tip of the day, avoiding html has many benefits. It reduces the probability for successful phishing attacks, it avoids propagation of exploits that depend upon flaws in html renderers and it reduces the profitability of many SPAMmers who depend upon hits to their embedded advertising banners for general advertising revenue.
DON'T filter abuse boxes for spam and virus
Okay this tip comes with a disclaimer. If you turn off all filtering for abuse boxes, you need to take very special measures to properly train and protect both the environment and the users who open the abuse email. Theoretically, these users should be trained well above average in security practices and know not to blindly open email attachments, etc..., etc..., etc... That being said, if the goal of abuse emails is to be able to receive and appropriately respond to all events that come in, doing any filtering is dangerous due to the very nature of the types of legitimate emails you might expect to receive. The complication here is that abuse emails are often made publicly available and, as a result, these accounts might be subject to an increased amount of SPAM. If the amount of spam from outside sources just becomes too much, at least create a separate internal abuse email for your internal employees to use that has no filtering of any kind.
DON'T turn on auto-respond features
Auto-responding to an email telling someone it's been blocked because it contains a virus or because it was a spam message is generally not held in high regard. A very high percentage of virus and spam emails have a spoofed source address and it is probable that the reply message being sent is going to an innocent bystander who actually had nothing to do with the original email being sent in the first place. Further, if you chose to ignore this tip, at bare minimum don't bounce the virus back to the sender. Again, they are probably an innocent bystander and if you send the original attachment/virus back to the apparent sender, you could be falling into the trap of propagating the virus even further.
UPDATE:Reader Andrew from Vancouver says this point should be underscored: "As a rule, assume that the virus is NOT honest enough to report the true sender's email address as the From address! Viruses randomly generate an email address or use a list of discovered addresses in their spoofed From/mailfrom address. Therefore, your virus alert will NOT go to the user whose workstation is infected.
Again, by sending virus alerts on inbound mail, you WILL be causing backscatter against an innocent bystander who had nothing to do with the virus in the first place or who may not even have an existing account. By sending unsolicited mail to these innocent bystanders, you may end up getting your own server blocklisted."
Well said...
DON'T send failure to deliver messages
Sending failure to deliver messages due to someone sending an email to an invalid account is bad for two reasons. First, suppose the person who sent the email is using a legitimate from address. If they are an attacker, you've just given them an ability to enumerate your mail server and find out which mail addresses are valid and which aren't. This may take an attacker a little longer, but it's effectively the same as leaving the SMTP VRFY command available. On the other hand, consider that a large amount of spam and viruses are propagated to random email addresses using random email addresses as the spoofed from address. By sending a failure to deliver message to the apparent sender, you may be causing backscatter against an innocent bystander who had nothing to do with the spam/virus in the first place or who may not even have an existing account.- Credit for this suggestion goes to reader Art.
DO learn how to read SMTP headers
When reporting abusive email, it is very important that the abuse is reported to the right source. Too many times, users (and sometimes even security administrators) will track down the apparent owner of the source email address or the abuse department for the domain of the source email address to complain to someone who is an innocent bystander (see previous tip). For example, in Microsoft Outlook open the email in question and click on View > Options. Look in the box that says "Internet headers" to access the SMTP headers. Further, when users report spam messages or virus messages to your abuse department, require that these SMTP headers are included in the complaint in order for full and appropriate action to be taken.
DON'T setup vacation messaged that will respond to mailing lists.
Okay, maybe this line item will sound like a rant, but it's very annoying to see messages on mailing lists that are a vacation or out of the office automated email. What's worse is when these messages are setup, it's usually because a person is going to gone for quite some time, which means if no action is taken there will be a lot of these messages built up in the list detracting from the purpose of the list in the first place. A good list administrator should identify these people quickly and immediately remove them from list subscription, followed by an independent email that lets them know how to resign up once they've returned from their vacation.
DON'T setup distribution lists without considering who can send to them.
A few weeks ago, I received an email from a certain telecomm provider giving me an updated escalation procedure. This email appears to have gone to a newly created distribution list for a range of customers for this provider. Immediately after receipt, my email box was flooded with the aforementioned vacation messages. In this case, I don't blame the individuals who setup vacation messages. They had no knowledge that they were about to be added to a new distribution group and it is not in their control that the email that was sent to this new distribution group was sent with the "reply to" address being the same as the distribution group. Further, they had no control over the fact that the telecomm provider failed to block the outside world from being able to send messages to this new distribution group.
DO hide the email addresses of members of email distribution lists/groups.
If setup improperly, sometime emailing to an email group will expand the address line to include all of the email addresses of the members inside a group. This might be acceptable for an internal company communication, but it's not a good idea when the email is destined for locations outside of the company. Further, this basically eliminates the effectiveness of who can send to the distribution list as mentioned on the previous tip since they no longer would have to respond to the email address of the distribution list. Instead, they can now do a reply all and communicate directly to everyone in the list.
DO make use of the BCC field.
BCC fields are very useful for quickly sending a message out to multiple people when you do not have the need, time or ability to create a distribution list as described above. Any recipient in the BCC field will receive the message, but their email address will be hidden from anyone who receives the message. If everyone who is meant to receive the message needs to have their email address hidden, you should put your own email address in the "to" field. This is also useful for giving additional people a copy of an email for documentation sake without the receipient being aware of the fact that there is someone else who is privy to the conversation. This useful feature can be used to archive all emails about a certain subject to an undisclosed mailbox for later review and retrieval (such as for a quality control process).
- Credit for this suggestion goes to reader Robert
--
T. Brian Granier
Trojan dropper in Power Point - a new issue?
These articles a little light in detail with respect to the inner mechanics of the vulnerability, but they sound very similar to issues reported last July as you can see in our previous diary. It is possible that these issues are related to MS06-048 and is just a variant of the attack described by Microsoft here. The question remains whether this is truly a new vulnerability, if Microsoft failed to fix the root cause with MS06-048 or if MS06-048 addresses these issues. Trendmicro's claim is there is no current patch for this issue.
--
T. Brian Granier
Microsoft August 2006 Patches: STATUS
| # | Known Problems with this patch |
Known Exploits |
client rating | server rating |
|---|---|---|---|---|
| MS06-040 | Issue with:
|
Botnets actively exploiting this in the WILD Exploit available in easy to use package
read more... |
PATCH NOW |
PATCH NOW |
| MS06-041 | No reported problems |
Critical | Critical | |
| MS06-042 | Critical issue:
More info: Issue #1:
Issue #2:
|
Original MS06-42: fixes a.o. a FTP vulnerability that;s well-known since 2004 First revision of the MS06-042 patch's buffer overglow has details public.
|
PATCH NOW |
Important |
| MS06-043 | No reported problems | Important | Less urgent | |
| MS06-044 | No reported problems | Critical | Critical | |
| MS06-045 | No confirmed problems | Critical | Less urgent | |
| MS06-046 | No reported problems | Critical | Important | |
| MS06-047 | No reported problems | Trojan dropper reported in word document by Symantec, Trendmicro(1) and Trendmicro(2). The dropper loads a backdoor: Trendmicro, Symantec. See also diary. |
Critical | Less urgent |
| MS06-048 | No reported problems | Trojan dropper in Powerpoint | Critical | Less urgent |
| MS06-049 | Unconfirmed reports about corruption of files on compressed volumes. [Windows 2000 only patch] |
Important |
Less urgent | |
| MS06-050 | No reported problems | Critical | Important | |
| MS06-051 | Although unconfirmed by Microsoft so far, there seem to be problems related to Terminal Services and multiple users loading certain DLLs as part of some applications. Details and fixes or workarounds are too sketchy so far. See also the problem with .ini files and citrix at the citrix support forum. We're still lookign for a more detailed discription of the problems. |
Critical | Critical |
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
Tip of the Day: The -they shall not be broken into- challenge
So let's assume we have a website with fairly static content, some feedback forms where people can inquire the status, a search option and a table in a database that needs to be published somewhat real-time on the website to spice things up a bit. We know from the past that our web traffic is only less than a 1 Mbps.
Connectivity
Let's start with the connectivity.If we build this we'd rather set it in a place where we can will the contest should it come to a DDoS, so we'll preferably not set it in the HQ in a DMZ as we're likely to have much less bandwidth there. One of the solutions would be to outsource the hosting of our servers to a tier-1 ISP and have it at their location.
Make a contract with them that they need to help you during DoS attacks and filter the traffic away from your connection. Over-engineer the physical connection far beyond what you need for your visitors. But do not let the connection become so bug that it can overwhelm your servers. I'd suggest a 100Mbps full duplex link for modern solutions if you have traffic levels in the lower Mbits or less. This allows you to keep it simple.
At such hosting facilities they are likely to connect you on a set of redundant switches with either a IP address in a VLAN with a set of routers doing a failover protocol such as HSRP and a few other customers in the VLAN. Try to negotiate to be the only customer in that VLAN. Negotiating to be the only customer on the link and having an air-gapped switch (not a VLAN) will not work for most of us as ports in routers are really limited in numbers.
Network
For our switches we standardize on a single model of not so big switches from a single vendor. It must have private VLANs, ports that we can shutdown, limits on what MACs can be learned, etc. Traffic reporting needs to be available but we'll not use SNMP v.1/2. We'll manage the switches as much as possible out of band over the consoles. See also the Tip of the Day on switches.Server hardware
For server hardware we're going to standardize on a single model of hardware. We'd like it not to have an Intel CPU as the hackers have way too many exploits ready for it for comfort. moreover the bad guys seem to know hat CPU's architecture much better than the defenders so we'll skip on that if possible. Unfortunately that means we're limited in choices so we might need to concede on this point a bit. See also the Tip of the Day on diversity.We want machines that are fully remote manageable. With a console we can get to easily form far away. Easy to swap hard-drives are a requirement. See further.
We want hardware based raid solutions such as mirrorring (raid 1), that's fully supported by our OS of choice.
Server OS
We want a well tested OS on the security side, developed by a small set of people who really get security and put security above usability, speed or anything else. We'd like the source code and the implementations to be vetted regularly. So we'll go for OpenBSD. There really is nothing else in the same league.This further limits the hardware choices above as current versions of OpenBSD don't like "binary" blobs to be inserted in the OS by vendors of hardware, so we'll need to mix and match a bit to get out platform together.
On our productions servers we'll install the bare minimum of the OS, e.g. no X11, no compilers. So we'll need a machine back in the office that does have at least that compiler and we'd like a test-bed to test new versions and be able to enhance our contraption while the previous version is out there.
Web server
Well once we chose OpenBSD we're left with Apache that even comes in a chroot-ed jail on OpenBSD. But we're going for extremes here, it's our job and reputation that's on the line so we're building 2 machines:- www.example.com will do static content only.
- cgi.example.com will do the form feedback only.
So we'll recompile apache from source and we'll remove all that we do not need in the source and create two binaries out of it:
- The one for www.example.com needs only to be able to display static content. It needs not to be able to display directory content, have a cgi interface or anything lile it. We do want to increase the number of possible processes that can be forked as we'd like to win a DoS attempt or two.
- The one for cgi.example.com needs to have a bit more abilities like doing cgi.
Filtering
We will use pf (packet filter) of OpenBSD, it's extremely powerful in what it can filter and write filters that allow the bare minimum our servers need to do. Future Tips of the Day might expand a bit on the ideas needed to get this working very well. Stay tuned.And the database?
Ah, yes the database link containing items to be displayed and update in near real time. We really do not want to expose our database. Nor do we want to -should something happen- on the webserver to allow them any connectivity to our database as that's a welcome mat for intruders.So how do we solve it? We put up one of our machines where it can reach the database server, let it run the queries and generate html out of it in a static fashion and then keep the initiative and send the data over a management connection to the static webserver. Repeating this process every so often as desired and we have our content on the static website where it's best protected without exposing the database server in any way.
Should in a future update (yes they happen!) there be a need to have some form of feedback towards the database, we can use that same machine, let the cgo.example.com machine collect the feedback, fetch it over the management connection, scrutinize it again, and then insert it in the database. Keeping the initiative on the safe side is the critical part in making it much harder to attack it. Scrutinizing any and every bit of data and treating it as tainted till proven otherwise is the second critical part. And the final part is to create software like this in a right form the first time try. It's like building bridges, not in the typical trial and error fashion.
Management connections
We need a way to connect back to the managment of the server that are hosted out there.We'll have a small set of trusted machines in our organization that are allowed to get to the machines and use ssh to get there. It's important to make sure the ssh ports aren't exposed (while at it, please do not run them on port 22 or 2222 or something predicatble like that) and to make sure the endpoints are well protected. The encryption only protects data while in transit! See also the Tip of the Day: using ssh keys.
We will add at the remote location a management network to connect to the servers out of band. We can also use this network for backup proposes. And we add a terminal server to it that connects to all the serial consoles of all network equipments and servers we have there.
Emergencies prepared.
In an emergency we'd like to be able to put up a "sorry we're closed, will be back soon" website and be able to pull the original one off-line for further incident handling. One of the low-cost ways is to have a hard-disk ready and swap it in the server, another is to have spare server sitting ready to take over (this is better as you can update the server with patches). The "website" might be made not using apache. One of the reasons you failed might be that apache got a security problem. Alternate ways to hand out html are possible, so let's be unpredictable and e.g. use netcat (nc) to hand out content.Logbooks have been discussed in a previous Tip of the Day, we're going to be religious about using them.
Fast recovery in case of hardware failures or other incidents is something we need.
Disaster Recovery is something we need to prepare and perhaps have contracts for.
Backups is something we need to prepare.
Redundancy
Adding redundancy adds a lot of complexity to this kind of solution. We can do it but there are risks. OpenBSD has some features to do it, and you could buy off the shelf solution for it. The problem remains the complexity it introduces.If it's acceptable to have a manual failover I'd strongly suggest to keep offline machine and swap them manually if something does goes wrong. It's much more KISS, and that's just one of those plain good engineering principles.
Having only one type of server and only one type of switch etc. allows us to minimize the support contracts, while allowing for a spare device ready to take over any of it's failed cousins in minutes.
--
Swa Frantzen -- Section 66
Comments