Security-conscious people tend to disable unnecessary features to improve the security of software that we use. For example, most web browsers can be made more secure by disabling features like Java, ActiveX, or even JavaScript by default. Sure, it's a trade-off with functionality, but when you're constantly processing untrusted data by viewing web pages, it makes sense to minimize your attack surface. The same techniques can be applied to your email client. For example, most popular email clients include an option to display messages as plain text. In Improving Internet Safety and Security Settings, Microsoft recommends setting the option "Read all messages in plain text."

It is reasonable to guess that the "Read all messages in plain text" option means that Outlook Express displays only the plain text MIME part of an email message. Or perhaps it just strips out the HTML tags from the message. However, both these guesses are wrong. Outlook Express is doing much more than this.

When Outlook Express receives an HTML email message, it determines the handler for the "text/html" MIME type. Outlook Express then uses the Internet Explorer rendering engine (MSHTML) to process the message. If the "Read all messages in plain text" option is specified, then the content is reduced to a plain text form. The important concept here is that the Internet Explorer rendering engine is used to process HTML email messages, regardless of the plain text setting.

In fact, ironically, setting the option to read messages in plain text can put the system at increased risk! While investigating attack vectors for the Windows animated cursor stack buffer overflow vulnerability (VU#191609), I noticed that when the "Read all messages in plain text" option was enabled, Outlook Express could be compromised just by displaying an email message in the preview pane. The default configuration of displaying messages in HTML format was not vulnerable via the preview pane. The HTML email referenced an ANI file on a remote server, and even though it was configured to display messages in plain text, Outlook Express retrieved the remote ANI file and processed it. Microsoft was notified of this behavior, and they updated their security bulletin with the text: "Note Reading e-mail in plain text on Outlook Express does not mitigate attempts to exploit this vulnerability." The behavior of Outlook Express does not appear to have changed since then.

Consider the recent Windows 7 / Server 2008 R2 denial-of-service vulnerability. This vulnerability can cause a Windows 7 or Server 2008 R2 system to hang upon attempting to create an SMB connection to a malicious server. Similar to the ANI bug, if Windows Live Mail is configured to display messages in plain text, the vulnerability can be triggered by simply receiving a malicious email and displaying it in the preview pane. The default configuration of displaying messages in HTML format is not as vulnerable because it appears to require additional user interaction, such as clicking the "Show images" link or forwarding or replying to the message.

If you are using an email client based on Outlook Express (including Windows Mail and Windows Live Mail), avoid using the "Read all messages in plain text" option. While it is possible that the setting could protect against some vulnerabilities, I have investigated several scenarios where it puts the user at increased risk. Note that Microsoft Outlook does not appear to be affected by this problem. In Outlook, the option to read messages in plain text does appear to offer increased protection against vulnerabilities.

• Many hosts that currently have private IPv4 addresses will have global, publicly reachable addresses.
• ICMPv6 contains much of the functionality of DHCP in IPv4 and cannot easily be entirely filtered.
• IPv6 addresses can be predictable or partially random. Modern operating systems allow both, and there is a tradeoff between system management ease of use and user privacy.

These changes can cause problems. For example, a host that accepts any ICMPv6 type can be fingerprinted easily from remote systems. That might not be a problem for some networks, but it could be critical for others.

There are ways for administrators to handle these challenges. The examples below aren't universally applicable, so use them as a general guide.

Managing networks using global IPv6 addresses

Globally reachable addresses are not "hidden" in the same way as NAT addresses. To filter traffic destined to these clients, administrators can use application-layer proxy servers, stateful network filtering, or host-based firewalls.

Below is an example of filtering traffic to a globally reachable IPv6 address. For the purpose of these rules, 2001:1::/64 is the local network, eth0 is the LAN interface on a firewall, eth1 is the WAN interface on the firewall, and 2001:3::1 is an IPv6 address on the internet.

ip6tables -A FORWARD -p tcp -i eth0 -s 2001:1::/64 -p tcp -j ACCEPT
ip6tables -A FORWARD -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A FORWARD -p tcp -i eth1 --dport 3389 -s 2001:3::1 -j ACCEPT
ip6tables -A FORWARD -p tcp -i eth1 -m state --state NEW,INVALID -j DROP

The following is an explanation of what's happening in these rules, based on the behavior of a typical router doing NAT.

ip6tables -A FORWARD -p tcp -i eth0 -s 2001:1::/64 -p tcp -j ACCEPT
Pass any traffic that has entered on our LAN's ethernet interface (-i eth0) and that has a source address in the range our LAN is using (2001:1::/64).

ip6tables -A FORWARD -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
Pass any traffic that is part of an existing connection.

ip6tables -A FORWARD -p tcp -i eth1 --dport 3389 -s 2001:3::1 -j ACCEPT
Allow any traffic coming into our WAN interface (-i eth1) to pass through to our LAN if it matches the TCP port used for RDP (--dport 3389).

ip6tables -A FORWARD -p tcp -i eth1 -m state --state NEW,INVALID -j DROP
Drop all other traffic.

After configuring the firewall, administrators should test the ruleset to confirm it is working as expected. Two commonly used tools that can test IPv6 TCP and UDP policies are nmap and netcat6.

Building on the example above, let's imagine that a user logs into a host with IP address 2001:1::2/64 and starts a netcat listener on port 3389:

$ netcat6 -l -p 3389

A scan of that IP from any host on the internet other than 2001:3::1 should fail. This result can be verified with an nmap comand:

$ nmap -PN -sT 2001:1::2/64 -p 3389

Starting Nmap 4.76 ( http://nmap.org ) at 2009-09-02 14:32 EDT
Interesting ports on 2001:1::2:
PORT     STATE SERVICE


Filtering selected ICMPv6 types

The ICMPv6 protocol includes some great functionality. IANA maintains a list of ICMPv6 types and codes.

It is hard to make general statements about which ICMPv6 types should be allowed or denied. The following chart provides some guidance about reasonable firewall policies applied to ICMPv6 types. The types are listed based on whether or not the ICMPv6 type can typically be allowed or denied.

We've talked about filtering ICMPv6 types before, so there's no reason to discuss it again. Instead, let's focus on some test case generation options.

There don't seem to be many tools that can generate arbitrary ICMPv6 packets. One of the more commonly used tools is ping6 or ping -6. The ping command sends an echo request message to an individual IPv6 address. Creating arbitrary ICMPv6 types requires a different tool.

Newer versions of the scapy packet crafting tool can be used to generate most ICMPv6 types. Here's an example of typical scapy usage:

# scapy
Welcome to Scapy (2.0.1-dev)
>>> a=IPv6(dst="2001:1::2")/ICMPv6ND_Redirect()
>>> send(a)

To list the available ICMPv6 types (layers), use the ls() command:

>>> ls()
ARP        : ARP
ASN1_Packet : None
BOOTP      : BOOTP
CookedLinux : cooked linux
...
ICMPerror  : ICMP in ICMP
ICMPv6DestUnreach : ICMPv6 Destination Unreachable
ICMPv6EchoReply : ICMPv6 Echo Reply
ICMPv6EchoRequest : ICMPv6 Echo Request
ICMPv6HAADReply : ICMPv6 Home Agent Address Discovery Reply
ICMPv6HAADRequest : ICMPv6 Home Agent Address Discovery Request
ICMPv6MLDone : MLD - Multicast Listener Done
ICMPv6MLQuery : MLD - Multicast Listener Query
ICMPv6MLReport : MLD - Multicast Listener Report
...

To view what parameters a layer will take, use the ls() command again:

>>> ls(ICMPv6ND_Redirect())
type       : ByteEnumField        = 137             (137)
code       : ByteField            = 0               (0)
cksum      : XShortField          = None            (None)
res        : XIntField            = 0               (0)
tgt        : IP6Field             = '::'            ('::')
dst        : IP6Field             = '::'            ('::')

This information can be used when creating packets to allow greater control over specific packets:

a=IPv6(dst="2001:1::2")/ICMPv6ND_Redirect(tgt="2001:1::3")

Disabling/enabling privacy extensions

Currently, IPv6 addresses are typically assigned via stateless autoconfiguration, DHCPv6 or static assignment.

With stateless autoconfiguration, an operating system is expected to generate part (usually the lower 64-bits) of its address. If privacy extensions are enabled, the generated address will be pseudo-random. This is good for privacy but makes remote management difficult.

On Windows Server 2008, privacy extensions can be controlled with a netsh command:

C:\> netsh interface ipv6 privacy enabled|disabled

Linux users should check /proc/sys/net/ip6/conf (the exact location varies between distributions and kernel versions).

Testing the address status of other systems on the same Ethernet segment is possible, assuming that echo requests and replies are accepted on those machines. If the following commands run on a Linux system produce predictable addresses, privacy extensions are disabled:

$ ping6 -B -I eth0 -I [global IPv6 address attached to eth0] ff02::1
$ ip neighbor

Windows users can use these commands:

C:\> ping -S [global IPv6 address] -6 ff02::2
C:\> netsh interface ipv6 show neighbors


• Many networks have IPv6 connectivity running on their LAN but do not have IPv6 WAN connectivity. Programs may see the connectivity on the LAN and unsuccessfully attempt to use IPv6 to connect to remote IPv6-enabled servers.
• Local IPv6 traffic might be able to bypass IDS systems or other low-layer network defenses.
• Operating systems may obtain global (publicly reachable) IPv6 addresses by creating tunnels.
• Running an additional protocol increases a system's attack surface.
• Global addressing restores end-to-end connectivity.

There are also more than a couple of reasons why an administrator wouldn't want to disable IPv6 connectivity:

• The network has full IPv6 connectivity, and software on the network actively uses some of the features (usually the large pool of global addresses) found only in IPv6.
• Network services running on the LAN are actively using IPv6.
• The network is designed to be a "dump pipe," and the administrator is expected to not interfere with passing traffic.
• Global addressing restores end-to-end connectivity.

Below are instructions for disabling IPv6 on some popular operating systems. At the bottom of the entry are links to scripts that you can run from the command line.

Disabling IPv6 via firewalls or access control lists

To disable IPv6 at a router or firewall, block protocols 41, 43, 44, 58, 59, and 60 as well as UDP ports 3544 and 3545. This firewall policy will likely miss some tunneled and non-routed IPv6 traffic (such as Teredo-compatible tunnels on non-standard ports) running on the local network.

There is too much variation in firewall syntax for us to list rules for every vendor; instead, we've written a few rules in Cisco's ACL syntax and included an ip6tables script linked at the bottom of this page.

access-list ipv6 deny 41 any any
access-list ipv6 deny 43 any any
access-list ipv6 deny 44 any any
access-list ipv6 deny 58 any any
access-list ipv6 deny 59 any any
access-list ipv6 deny 60 any any
access-list ipv6 deny udp any any eq 3544
access-list ipv6 deny udp any any eq 3545 

Disabling IPv6 on Windows XP and Server 2003

The easiest way to disable IPv6 on Windows XP and Server 2003 is to run this command from a prompt with administrator privileges and reboot:

netsh.exe interface ipv6 uninstall

Disabling IPv6 on Windows Vista and Server 2008

The IPv6 protocol cannot be uninstalled from Windows Vista. The most effective way of disabling it is to edit the registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents]
"Compatibility Flags"=dword:0xFFFFFFFF


If you don't want to edit the registry, the following netsh commands will effectively block IPv6. Note to administrators: using the "domain profile" feature of the Windows firewall will allow you to create rules that block IPv6 connectivity based on whether the user is authenticated to your domain.

netsh advfirewall firewall add rule name "IPv6" protocol=icmpv6 dir=out action=block
netsh advfirewall firewall add rule name "IPv6" protocol=icmpv6 dir=in action=block
netsh advfirewall firewall add rule name "IPv6" action=block protocol=41 dir=out
netsh advfirewall firewall add rule name="IPv6 protocol 43" protocol=43 action=block dir=out
netsh advfirewall firewall add rule name="IPv6 protocol 44" protocol=44 action=block dir=out
netsh advfirewall firewall add rule name="IPv6 protocol 58" protocol=58 action=block dir=out
netsh advfirewall firewall add rule name="IPv6 protocol 59" protocol=59 action=block dir=out
netsh advfirewall firewall add rule name="IPv6 protocol 60" protocol=60 action=block dir=out

Disabling IPv6 on Red Hat Enterprise Linux 5

1. Edit /etc/sysctl.conf
2. Append "net.ipv6.conf.all.disables_ipv6 = 1"
3. Execute "sysctl -p" as root

You can modify "net.ipv6.conf.all.disables_ipv6 = 1" for a specific interface (e.g., "net.ipv6.conf.eth1.disables_ipv6 = 1") to selectively disable IPv6 on that interface.

The following steps will disable IPv6 connectivity on all interfaces:

1. Edit /etc/modprobe.conf
2. Append "alias net-pf-10 off"
3. Execute the command "modprobe -a" as root

For those of you who really want to disable IPv6, add these lines to your iptables scripts:

ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP

ip6tables -I INPUT -p all -j DROP
ip6tables -I OUTPUT -p all -j DROP

Disabling IPv6 on Ubuntu Linux (version 9.04)

1. Edit /etc/sysctl.conf
2. Append "net.ipv6.conf.all.disable_ipv6 = 1"
3. Execute "sysctl -p" as root

You can modify "net.ipv6.conf.all.disable_ipv6 = 1" for a specific interface (e.g., "net.ipv6.conf.eth1.disable_ipv6 = 1") to selectively disable IPv6 on that interface.

The following steps will disable IPv6 connectivity on all interfaces:

1. Edit /etc/modprobe.d/blacklist
2. Append "blacklist ipv6"
3. Execute the command "modprobe -a" as root

Ubuntu users who run UFW can check /etc/default/ufw. If IPV6=no, you can block IPv6 connectivity with this command:

sudo ufw disable && sudo ufw enable

Scripts

Here are files you can use to disable IPv6. As with all scripts, make sure you understand the implications before running these on your system.

• ip6tables router/firewall shell script
• batch file to disable on Windows XP and Server 2003
• reg file to disable IPv6 on Windows Vista and Server 2008 (Microsoft has published instructions on how to import. Also see the instructions in the solution section of TA09-020A.)

Slowloris holds connections open by sending partial HTTP requests. It continues to send subsequent headers at regular intervals to keep the sockets from closing. In this way webservers can be quickly tied up. In particular, servers that have threading will tend to be vulnerable, by virtue of the fact that they attempt to limit the amount of threading they'll allow.

We've generated a few packet capture files that show Slowloris in action. The web server being targeted is an Apache 2 (172.16.65.5) installation, a normal web browser is connecting from 172.16.65.4 and the Slowloris tool is running on 172.16.65.2. During the attack, Apache became unresponsive after a few seconds but recovered quickly once the attack was stopped.

We know that Slowloris works, and SANS reports that some attackers are already using a similar tool to attack web servers. As an administrator, we have some ideas about how you can stop an attack. Our mitigations below only apply to a limited number of deployed servers—ones that have relatively low volume and serve (usually) a small number of clients.

Before going further, it's important to figure out what device is actually affected by Slowloris. Although your routers shouldn't be affected (wrong network layer), reverse proxies, web application firewalls, and web servers might be.

After you've determined what components are affected, you'll probably want to look for something like Apache's TimeOut directive on an affected device. By lowering the TimeOut directive, Apache will more quickly discard the partial HTTP requests the Slowloris tool is sending. This change (slightly) increases the amount of bandwidth an attacker needs to sustain a DoS attack on the web server.

In addition to lowering the timeout for connections, Slowloris needs to use a different (although not sequential) source port for each connection. This makes each connection appear "new" to the web server and the operating system that it is running on. Below are some iptables rules using the recent module that demonstrate this concept. The rules allow ten new connections from a given IP every fifteen seconds and drop additional packets from the sending host that is over that limit.

iptables -I INPUT -p tcp -m state --state NEW --dport 80 -m recent \
--name slowloris --set

iptables -I INPUT -p tcp -m state --state NEW --dport 80 -m recent \
--name slowloris --update --seconds 15 --hitcount 10 -j DROP

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

View the packet capture file to see how well our mitigations worked.

Although the results look good, it's important to note that the TimeOut directive doesn't help that much, and these iptables rules will trigger an unacceptable amount of false positives on busy servers receiving connections from proxies and NAT gateways. The workarounds listed above might be applicable on low-volume but critical web servers. They might also be useful for servers under attack when the option of serving pages to some clients is better than serving pages to none.

Thanks to Robert Hansen of SecTheory and Jason McCormick of the Software Engineering Institute for providing technical advice.

Shortly after the JBIG2 vulnerability in Adobe Reader was disclosed, I started investigating other image formats. Just like JBIG2, the JPX format is slightly obscure, and the support for it within PDF documents is relatively new. JBIG2 support was introduced in version 1.4 of the PDF specification, while JPX support is even newer at version 1.5 of the spec. Though not always the case, one would think that newer formats are not tested as well as older, popular formats such as JPEG.

As the result of investigating JPX format support in PDF readers, I found vulnerabilities in both Adobe Reader and in Foxit Reader. Both vendors wrote faulty JPX-handling code. Nobody is perfect at writing software; if they were, my job would be quite different. However, there is an important difference between the two applications with respect to attack surface: Adobe Reader comes with JPX support built in, while Foxit Reader requires an add-on to view JPX (and JBIG2) images. The modular design of Foxit Reader means that the extra functionality such as JBIG2/JPX decoding is only present on systems where the user has made the decision that they would like that ability. This design reduces attack surface.

Adobe Reader and Foxit Reader are just two examples that I have chosen to demonstrate the problem of software attack surface. Both vendors appear to understand security, and both handled the coordination aspect of the vulnerabilities quite well. Feature creep is a problem that is endemic to the software industry.

One driving force with software vendors is to include more features and to have those features enabled by default. End users of software may appreciate not having to make decisions about what features to enable when installing an application. However, not even giving them a choice is doing them a disservice, especially when it comes to security. I would like to see a more modular design with software and its installers. If I want the kitchen sink, I'll let you know. Don't give it to me by default.

To investigate IPv6 tunnels' effect on firewalls, we created a test to see how an IPv6 Teredo-compatible tunnel can be used to trivially bypass an IPv4-only firewall. The video referenced in the first paragraph shows our whole exercise in real time. We used a typical iptables firewall and appended the following rules to reject TCP connections that have the string "google" anywhere in the packet:

iptables -A OUTPUT -p tcp -m string --algo bm --string "google" -j REJECT
iptables -A INPUT -p tcp -m string --algo bm --string "google" -j REJECT

The rules work; browser connections to www.google.com fail. But the rules produce a large number of false positives, won't catch HTTPs connections, and are "expensive" to process, so don't paste them into your iptables script.

Lines 1-5 of this packet capture show exactly how the REJECT rule works (connections are closed, not discarded). There are also some interesting packets on lines 6 and 7. The packets in these lines are IPv6 packets being transported by IPv4 UDP. More specifically, the lines show a router solicitation (us asking for an IPv6 address) and a router advertisement (a router offering an IP prefix).

To see what happens when we browse to an IPv6-enabled website, let's go to http://ipv6.google.com. Looking at the capture file, you can see that the connection was successful. The HTTP GET string was transferred inside of a UDP packet and didn't trigger the iptables rules that were searching for that string inside of TCP packets (line 22).

We've illustrated the potential problem, but what about a solution? Trying to block ports can be effective but is likely to only work for specific brokers who are using the expected ports. Consider the following alternatives:

• IPv6-aware host-based firewalls can be effective. In our example, calling the ip6tables rules below would have blocked connections to http://ipv6.google.com.
  

  ip6tables -A OUTPUT -p tcp -m string --algo bm --string "google" -j REJECT
ip6tables -A INPUT -p tcp -m string --algo bm --string "google"-j REJECT


• If you're trying to block IPv6 tunnels on the network, you could look for router advertisements or solicitations. Those messages are sent to the all-nodes multicast address ff02::1. Here is an un-optimized example iptables rule that uses iptables:
  
  iptables -I FORWARD 1 -p udp --dport 1024: -m string --hex-string "|ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02|" --algo bm -j REJECT

  One of our readers pointed out that blocking local IPv6 traffic could cause an operating system to activate an IPv6 tunnel. He is correct; however, this rule should not interfere with native IPv6—it only applies to IPv4 UDP connections that are going between two interfaces (the FORWARD chain).

• We've heard that IPFilter development version 5.06 will decapsulate IPv6 in IPv4 packets and apply filtering rules. The following syntax, which we haven't tested, might block IPv6 in IPv4 tunnels:
  
  decapsulate in on bge0 family inet6 proto ip all head ipinip6
block in all group ipinip6


• Evan Wright from our Network Situational Awareness team pointed out that blocking protocols at border routers can stop some types of IPv6 connectivity. Using access control lists at border routers to block protocols 41 (used by 6to4), 43, 44, 58, 59, 60, and 192.88.99.1 (default anycast address of some 6to4 systems) would be a good place to start.  Shown as an iptables example, it would look like this:
  
  iptables -A FORWARD -p 41 -j REJECT
iptables -A FORWARD -p 43 -j REJECT
iptables -A FORWARD -p 44 -j REJECT
iptables -A FORWARD -p 58 -j REJECT
iptables -A FORWARD -p 59 -j REJECT
iptables -A FORWARD -p 60 -j REJECT



These examples may not directly apply to your network, but hopefully they illustrated the problem and gave you some suggestions that you can use as a starting point for improving the security of your firewalls.

See the original guidelines for details about configuring and using your secured browser. The following sections describe how to use the reference implementations.

Mozilla Firefox

The implementation of the recommended settings for Mozilla Firefox 2.x and Firefox 3.x is available in a user.js file. To use these settings:

1. Install NoScript using Firefox.
2. Download the user.js [sig] file into your Firefox profile location.
3. Restart Firefox.

The settings specified in the user.js file will override any of the corresponding settings that you have set. The advantage of this behavior is that if the user.js file is removed, then Firefox will behave as it did before the change. The disadvantage is that the settings that are specified in this file cannot be set by using the Firefox preferences GUI.

To apply site-specific security settings, use the NoScript add-on. This component gives the browser the ability to whitelist sites so that you can enable features such as JavaScript, Java, and other plug-ins. You can add a site to the whitelist either permanently or temporarily (until the browser is closed) by clicking the NoScript icon.

Internet Explorer

The recommended settings for Internet Explorer 6 and Internet Explorer 7 are available as a Windows registry file. To incorporate these changes, simply open the ie_sywb.reg [sig] file to merge the changes into the registry. Note that this will overwrite the existing security settings for the web browser. If you use Internet Explorer 7, you can undo the changes by clicking the "Reset all zones to default level" button.

To apply site-specific security settings, use the Security Zones feature of the browser. The Internet Zone, which is the default zone for sites on the internet, is locked down with high security settings, while the Trusted Sites Zone is configured to be the equivalent of the default Internet Zone for Internet Explorer. This way, Internet Explorer uses high security settings by default, and as you encounter sites you trust that need extra features, you can add them to the Trusted Sites zone. The easiest way to add a site to the Trusted Sites zone is to

1. double-click the zone indicator icon near the bottom right side of the screen
2. click the Trusted sites icon
3. click the Sites... button

This dialog allows the user to add the current or other sites to the Trusted Sites zone. Wildcards are also supported. For example, a user can add "*.cert.org" to the list, and any site that resides on the cert.org domain will be trusted.

The initial reaction to a secured web browser may be that sites no longer work, because you are now responsible for deciding which sites can use features that may provide additional functionality but at the same time are more dangerous, such as ActiveX and Signed Java Applets. As time goes on, the sites that you visit regularly will be added to your Firefox NoScript whitelist or Internet Explorer Trusted Sites Zone, and those sites should work fine with minimal user interaction. However, you now have significant protection against malicious web sites, including sites that you have not visited before, such as one that may be linked to from a malicious email message, or sites that you may reach when a trusted site is compromised with an injected IFRAME to a malicious site. In both of these cases, you will be protected against the majority of vulnerabilities that affect web browsers.

One tip to getting sites to work properly with your secured browser is to be aware that some sites use multiple domains, several of which may require restricted features, such as JavaScript. For example, a Yahoo! Mail user would need to allow both *.yahoo.com and *.yimg.com. Or YouTube users would need to enable both *.youtube.com and *.ytimg.com. NoScript clearly indicates which domains are available to add to the whitelist; however, Internet Explorer does not have this ability.

Customization

Both the Mozilla Firefox and Microsoft Internet Explorer reference files are annotated to describe which settings they will change. Feel free to view and modify them to suit your own needs if necessary.

• Provide an easily identifiable role email address specifically for product security issues
  In our experience, it's extremely beneficial for the vendor to provide a role email address (e.g., a shared mailbox or an alias) for receiving information. Pick an intuitive and memorable name for the role address, such as "product-security@", "security-team@", "security-response@", or "secure@". Note that "security@" may not be a viable option because IETF RFC 2142 suggests using that mailbox name for reporting or inquiring about network operational security issues. Sites that have implemented the recommendations in this RFC may have already allocated that name, and external sites that are familiar with the recommendation may resist sending other types of messages to that address.
  
  Even if this address only has a small number of recipients, having a fixed point of contact is valuable to external parties. Avoid using individuals as direct points of contact because of the potential problems that can be caused by job changes. Vulnerability reporters get frustrated when messages to individuals bounce or when they learn that the individual is no longer connected with the product(s) in question. While there is some additional management overhead in maintaining a role address, our experience indicates that it's a worthwhile investment. Giving members of the product security group the ability to respond from this role address provides additional consistency to external parties.
  
  We discourage the use of standard email addresses such as "info@", "support@", and "webmaster@" for the security point of contact because security reports sent to these addresses can easily be overlooked or mishandled.

• Provide a web-based reporting form
  A web-based reporting form allows vendors to collect reports in a well-structured manner so that the reports can potentially be searched and managed more efficiently. The form also provides a slightly easier mechanism for vulnerability reporters who may wish to remain anonymous. You may want to consider our vulnerability reporting form for ideas about how to construct your own page.

• Use cryptography if possible
  The vulnerability reports you will receive may contain sensitive information that could be damaging to users or customers if it were exposed to an unauthorized source. Publishing an encryption key corresponding to the role address mentioned above allows researchers, especially those that consider confidential reporting part of the responsible disclosure process, to securely communicate vulnerability reports. If you think the importance of crypto in the vulnerability reporting process is exaggerated, consider this example: We once sent an encrypted mail containing sensitive information to an external researcher. We received a response from the individual telling us how relieved he was that we encrypted the message because his ISP's POP server was discovered to be compromised not long after we sent the message. Disclosure of the information would've had negative implications for a considerable number of parties.
  
  We use PGP in our processes, but vendors may choose to offer PGP, S/MIME, or both.  Maintaining crypto keys also lets vendors sign patches, support bulletins, or advisories. Users can then verify the authenticity of these publications before taking any of the actions they prescribe. Signing can be done with the same key used to receive reports or with a separate signing-only key, depending on the key management practices a vendor chooses to follow. As with the email alias mentioned above, there is some additional overhead in maintaining keys; however, it's been our experience with this, too, that the benefits can outweigh the costs if managed appropriately. The U.S. National Institute of Standards and Technology (NIST) maintains some good resources for key management policies.

Note that we haven't provided any recommendations here about what vendors should actually DO when they receive product security reports. That is a separate topic that we'll try to cover in a future post.

Because communication should be a bidirectional process, let's next consider the publication of product security information.  Here are some specific recommendations:

• Provide a "slash security" web page
  One of the first places users and potential vulnerability reporters will visit to learn about a vendor's product security is the "/security" page on the vendor's main website (e.g., "http://www.example.com/security"). Ideally, this page will be the primary focal point for everything related to product security. We recommend that it contain or refer to, as appropriate, the following content:
  • product security bulletins and advisories
  • product security contact information, including all of the resources described above
  • security patches and updates
  • documents (e.g., whitepapers, FAQs, support bulletins, electronic books) describing best practices for secure deployment or operation
  • documents describing secure development practices involving relevant products

In some cases, vendors have already devoted the "/security" page to their security product offerings (recall the distinction we described above). Vendors often have a lot of time and money invested in their site layout, so it's unreasonable to expect them to redesign. In these cases, we encourage vendors to include a reference to product security somewhere on the "/security" page, possibly redirecting to a "/support/security" or "/product-security" page, for example.  Having "Security" as a dropdown option from a "Support" menu is also helpful.

We have received positive feedback about vendors that provide good product security pages, and, from a public perception standpoint, it's perhaps the single most valuable security-related resource you can provide.

• Offer security mailing list subscription
  Sending copies of security advisories (or notifications of their availability on the web) to a mailing list is an effective way to get your users and customers to take action in mitigating a vulnerability. We regularly tell users to subscribe to this type of mailing list for the products they use whenever the lists are available. As with other publications mentioned above, email messages sent to these lists should be cryptographically signed to let users verify the authenticity of the message before taking action. A common technique attackers use is to send spoofed "security advisory" emails that contain malicious code in the form of "security patches." To confirm authenticity, signing is crucial if you intend to email information to customers.

We recognize that it may be counterproductive for vendors of specialized products or those that are used exclusively in critical deployments to publish product security information so broadly. In these cases, we encourage vendors to contact known customers directly or provide information in a way that is restricted to existing customers.

One of the underlying themes in this post is the recommendation to centralize points of contact as much as possible. For vendors that have a small or closely related product lines, this centralization can be a straightforward process. However, we understand that many vendors are conglomerates that have a large number of independent divisions. We've dealt with instances where one affected product division had no idea another affected product division even existed. Mergers and acquisitions present another challenge to centralization. The general recommendation we can provide in these cases is to still create points of contact at the coarsest level possible. For example, a company with a network equipment division based in the U.S. and an automation systems division based in Germany might choose to set up "www.bigcorp-networks.example/security/" and "www.bigcorp-automation.de.example/security/" and ideally have links to both of these pages at "www.bigcorp.example/security/". The same redundancy should apply to email contacts.

Vendors' attention to product security is receiving increased scrutiny in security and IT communities.  Presenting organized methods for communicating product security information is an important element to demonstrating to customers (both current and potential), security researchers, the media, and the general public that you have at least some awareness of and commitment to security.

Consider these three disclaimers before reading further:

1. Don't use any of these rules in production without testing.
2. These rules may or may not apply to link local addresses. Proceed with caution.
3. The examples in this entry are not complete. More complete rules are available.
4. The ICMPv6 types listed below can be represented by either rules or type codes.

When it comes to building rules, RFC 4890, "Recommendations for Filtering ICMPv6 Messages in Firewalls," has done most of the hard work for us. Looking at section 4.4 and its subsections (we're focusing on host-based firewalls), various ICMPv6 types are assigned to four categories:

1. Traffic That Must Not Be Dropped:
   Types 1,2,3,4,128,129,130,131,132,143,148,149,151,152,153,133,134,135,136,141,142
2. Traffic That Normally Should Not Be Dropped:
   Types Type 3 - Code 1, Type 4 - Code 0
3. Traffic That Will Be Dropped Anyway -- No Special Attention Needed:
   Types 138,144,145,146,147
4. Traffic for Which a Policy Should Be Defined:
   Types 137,139,140,5-99,102,126

The following example rules do not attempt to cover all the advice in RFC 4890. Instead, we'll get you started with some rules that take advantage of some of the new features offered by IPv6.

First, let's set a default deny policy:

ip6tables -P INPUT -j DROP

ip6tables -P OUTPUT -j DROP

The "Traffic That Must Not Be Dropped" section lists echo request (128) and echo response (129). An attacker could use echo requests (pings) as a DoS attack vector, so we might want to block or limit these requests. Since we're talking about host-based firewalls, we can't stop echo requests from reaching us, but we can limit how many of them we respond to: 

ip6tables -A INPUT -p icmpv6 --icmpv6-type 128 -m limit --limit 900/min -j ACCEPT

ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 129 -m limit --limit 900/min -j ACCEPT

If our host uses DHCPv6 or we manually assign an IPv6 address and gateway, we don't need stateless auto-configuration. We can drop router advertisements and block router solicitations.

You could disable the processing of router advertisements in the kernel using sysctl, and this traffic is dropped by the default policy. For practice, let's reject instead of drop (note that these rules violate RFC 4890 and will break stateless autoconfig):

ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 133 -j REJECT

ip6tables -A INPUT -p icmpv6 --icmpv6-type 134 -j REJECT

The default setting of the hop limit field is usually set to 255 and gets decremented by one every time a router forwards a packet. Assuming the router works correctly, this next rule will only allow echo request and echo response messages to and from nodes on the local Ethernet segment. Using the hop limit value, we can allow certain types of traffic only from other nodes connected to the same router.

You can adjust the rate to be anything that you think is reasonable. If you only want to use echo request and echo response with nearby nodes, the hl (hop limit) module can be useful. These rules restrict echo request and reply to packets that have 255 as the hop limit:

ip6tables -A INPUT -p icmpv6 --icmpv6-type 128 -m limit --limit 900/min -m hl --hl-eq 255 -j ACCEPT

ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 129 -m limit --limit 900/min -m hl --hl-eq 255 -j ACCEPT

ip6tables -A INPUT -p icmpv6 --icmpv6-type 128 -m limit --limit 900/min -m hl --hl-lt 255 -j DROP

ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 129 -m limit --limit 900/min -m hl --hl-let 255 -j DROP

By default, the Windows Firewall in Vista (and Server 2008) drops inbound packets and allows outbound packets. Let's work on filtering rules for the "Traffic for Which a Policy Should Be Defined" section of RFC 4890.

Use the following command to block router redirects (type 137):

netsh advfirewall firewall add rule name "block icmpv6 type 137" dir=in action=block protocol=icmpv6:137,any

Although blocking router redirects on untrusted networks is probably a good idea, the default state of the Vista firewall doesn't explicitly allow that ICMPv6 type inbound, so we haven't done anything. Let's try something a little more advanced. This next rule allows ICMPv6 redirect messages, but only if the computer is using the "domain" profile. We could get similar functionality with ip6tables, but only if Networkmanager scripts are used (we might talk about this in a future blog entry).

netsh advfirewall firewall add rule name "allow icmpv6 type 137 for the domain profile" dir=in action=allow protocol=icmpv6:137,any profile=domain

This rule implies that the computer is logged into a domain controller and has authenticated via Active Directory. Microsoft offers more information about the profiles.

Administrators may worry about bandwidth on some links more than others. The following rule allows inbound echo requests on wired connections only:

netsh advfirewall firewall add rule name "allow icmpv6 type 128 when wired" dir=in action=allow protocol=icmpv6:128,any inerfacetype=lan

The Vista firewall includes the ability to allow (or deny) connections that are authenticated by IPsec. The security= directive can also require that connections are authenticated (authenticate) or authenticated and encrypted (authenc):

netsh advfirewall firewall add rule name "allow icmpv6 type 128 when wired" dir=in action=allow protocol=icmpv6:128,any security=authenticate

netsh advfirewall firewall add rule name "allow icmpv6 type 128 when wired" dir=in action=allow protocol=icmpv6:128,any security=authenc

If you'd like to learn more about configuring the Vista firewall by using netsh commands, see the Microsoft Technet article "Netsh Commands for Windows Firewall with Advanced Security." The ip6tables documentation is in their man page.

If you're interested in ip6tables rules, we have a more complete list that includes rules not mentioned in this blog entry.