Links zum Thema Computer-Netzwerke und Sicherheit [Englisch]

Vor einigen Jahren hatte ich hier eine Sammlung von wichtigen Information und Links zum Computer-Netzwerke und Netzwerksicherheit online gestellt. Diese Sammlung sollte Cisco CCNA und CCNP Kandidaten das Lernen erleichtern. Im Zuge meiner Aufräum-Aktion habe ich die Links überprüft und stelle sie hiermit wieder online.

Continue reading “Links zum Thema Computer-Netzwerke und Sicherheit [Englisch]”

Cisco IronPort AsyncOS 7.6 for Email

Ironport has updated their operating system AsyncOS for Email to version 7.6

This is a overview of new features and enhancements which are also getting included in the new Cisco Ironport Email Security Channel Partner Trainings.


  • New Feature: IPv6 Support
  • New Feature: RSA Enterprise Manager Integration
  • Enhancement: DLP Message Tracking Privileges By User Group
  • Enhancement: RSA Email DLP’s “Quarantine a Copy and Deliver” Option
  • Enhancement: DLP Message Actions
  • Enhancement: New and Updated RSA Email DLP Policy Templates
  • Enhancement: SenderBase Reputation Service Requires an Anti-Spam Feature
  • New Feature: DKIM Verification Profiles
  • Enhancement: New Tags for DKIM Signing Profiles
  • New Feature: DKIM Signing of System-Generated Messages
  • Enhancement: Skip DKIM Signing Action
  • Enhancement: Rate Limiting and Enforced TLS for Envelope Senders in Mail Flow Policies
  • Enhancement: Separate Update Servers for AsyncOS Upgrades and Other Service Updates
  • Enhancement: Message Size for Encryption
  • Enhanced: Web User Interface Protection


  • IPv6 Support
    not available for: clustering, ESQ, SMA communication, DNS, LDAP, SNMP, FTP, Updates/ Upgrades, Sending Alerts, Remote Access
  • Reputation Engine
    now running directly on-box with database on-box as well – no communication with senderbase database necessary any more
    commands: listenerconfig / setup, fullsenderbaseconfig, repengupdate
  • Extended Header Editing in Content Filter
  • DKIM setup restructured
  • Rate Limit can now be based on “mail-from” within the envelope instead of IP/Domain combination
  • TLS settings based on “mail-from” are also possible using address-lists


The full documentation can be found at

The first email was sent 40 years ago this month

It’s become a firm fixture of everyday life, loathed by some but essential to nearly all of us, and yet its future is far from certain. Email is forty years old this month, with the first message having been sent in October 1971.

The birth of email

Like many technological innovations, email has its roots in military technology. In the late 1960s, MIT graduate Ray Tomlinson was working at research and development firm Bolt, Beranek and Newman. His work included contributing to technologies related to the ARPANET, the military communications network that was the earliest form of the Internet. This included a file transfer program for mainframe computers.

With this file transfer experience, Tomlinson was assigned to modify a program called SNDMSG, which allowed messages to be sent between different users of the same computer – this was in the days when computers were incredibly expensive, and the idea of one person having a computer to themselves was impractical. His task was to allow messages to be sent between two different computers, and in October 1971 he cracked it.

As Tomlinson told The Times in 2008, he doesn’t remember what that first email actually said – perhaps ‘QWERTY’ or another string of characters, but whatever it was, it traveled a distance of one meter between two separate computers. One small step for a message, one giant leap for mankind.

Besides inventing email, Tomlinson is also the man to thank for the popularity of the ‘@’ symbol. He established the convention of an email ‘address’ in order to identify the recipient and the computer or network that they were using. To separate these two pieces of information, he chose ‘@’. He told The Times,  ”It conveyed a sense of place, which seemed to suit.”

The growth, growth and growth of email

Email use on ARPANET quickly took off after that first message in 1971, but it wasn’t embraced on a wide scale until the 1990s when the birth of the World Wide Web led to consumers embracing the Internet. By the end of that decade, it had become an essential part of working life in many offices around the world.

Back in 2001, the School of Information Management and Systems at UC Berkley reported that around 31 billion emails were sent daily. By 2008, that figure had risen to 170 billion each day, at a rate of 2 million per second. It hasn’t stopped accelerating; Pingdom reported that in 2010, the daily rate was 294 billion.

Original & Full Article by

Proxy Auto-Configuration and its challenges

I was a fan of WCCP for setting up transparent proxy within a network – it always seemed the easiest way but all together it only seemed like that. A lot of problems came up in the past few month on customer sides and within my installation so I decided to give Proxy Auto-Configuration a try.

Biggest benefit of using PAC (Proxy Auto-Configuration) is: “You get rid of transparent proxy.” That makes life easier – but before I had to learn a lot of stuff the hard way.

Rollout the URL for the PAC File without touching the client

2 Options are available – DNS and Option 252 for DHCP

Easiest way is DHCP and the configuration therefore is straight forward. Extend your DHCP configuration with the option 252 and put the URL for the PAC file as a value into. The client fetches with the next renew of the DHCP settings also the proxy information.

DHCP has a higher priority than DNS: if DHCP provides the WPAD URL, no DNS lookup is performed. Notice that Firefox and Chrome do not support DHCP, only DNS.

Next step is to set up DNS for the browsers lacking DHCP support. It’s also straight forward – redirect any request for to the PAC file server. The browser is going to fetch the file wpad.dat (which is our PAC file) from the file server.

Verify your Clients

Very important for your client PCs and/or applications is that they are set to auto-detect proxy settings from your network. If this is not set up – you have to touch the client or use some kind of scripting to set that on your browsers.

PAC file hosting

One challenge could be the PAC file hosting. If you use a webserver – it is important that every PAC file (nevertheless if it is called proxy.pac or wpad.dat) sent to the client gets the right MIME type. The MIME type of the configuration file must be “application/x-ns-proxy-autoconfig”.

If you are using DNS to get the PAC file – every client is requesting the wpad.dat file from the URL mentioned above on port 80.

PAC file hosting with Cisco Ironport Web Appliance

If you are using a Cisco Ironport S-Series or Web Appliance – a lot of things get handled by the Ironport itself. MIME type is set right and a few other things which we are talking right now.

Ironports PAC file hosting lets you specify a port for the PAC file service – per default 9001. If you use DNS – the PAC file service has to listen on port 80 as well. That is not a problem as long as you are not using port 80 for your web proxy service and your AsyncOS Version is 7.x
Just add the port 80 to the PAC file service and submit the changes.

Next step is to upload your PAC file – the PAC File can have any name as long as you can remember it and use it right if you set up your DHCP settings. Ironport also supports multiple PAC files as long as they have a different name. That’s it if you can use DHCP – every DHCP pool within your network could fetch a different PAC file from the same Ironport Appliance.

Talking about DNS – you need to host wpad.dat files – Ironport is helping out. In the section “Hostnames for Serving PAC Files Directly” you can set up a GET hostname (the URL the client is using to access the PAC hoster) and choose a PAC file from your uploaded one and Ironport is renaming it on demand for the client requesting.

For example, if you enter in the Hostnames field and pacfile1.pac in the Default PAC File for “Get/” Request through Proxy Port field, then requests for fetch pacfile1.pac and requests for fetch default.pac.

Additional Information

Cisco Global Threat Report Quarter 1 2011

The Cisco Quarter 1 2011 Global Threat Report has been released. The Cisco Global Threat Report is a compilation of data collected across the four segments of Cisco Security: ScanSafe, IPS, RMS and IronPort.

A good summary was done by Brian Pennington

The original document can be found on

SPDY: An experimental protocol for a faster web

SPDY Whitepaper Executive Summary

As part of the “Let’s make the web faster” initiative, we are experimenting with alternative protocols to help reduce the latency of web pages. One of these experiments is SPDY (pronounced “SPeeDY”), an application-layer protocol for transporting content over the web, designed specifically for minimal latency.  In addition to a specification of the protocol, we have developed a SPDY-enabled Google Chrome browser and open-source web server. In lab tests, we have compared the performance of these applications over HTTP and SPDY, and have observed up to 64% reductions in page load times in SPDY. We hope to engage the open source community to contribute ideas, feedback, code, and test results, to make SPDY the next-generation application protocol for a faster web.

Few months ago I stumbled over SPDY and was wondering if the known proxy implementations will ever be able to handle this protocol. Now, it is getting more and more interesting for products like Ironport’s Web Proxy to handle SPDY (somehow). Google is going to switch theire protocol handling for Google Apps in combination with Google Chrome to the faster and more secure SPDY protocol in the near future.

At Let’s make the web faster you can find lots of articles and user discussions about several things Google uses to fix the slow HTTP handling. From my point of view – it is necessary to exchange the HTTP(s) paradigm with a better one, which fits the needs of the internet we know!

And you would be surprised how easy it is to extend your WebApp to support SPDY besides the traditional HTTP(s) handling.

Using DomainKey and Sender ID as an end user

Most implementations for using DomainKeys (or DKIM) and Sender ID are written and used on the level of the MTA to verify the authenticity of the message.

Now iconix has written a piece of software which allows the verification at end-user-level. That allows them to bring the whole process and system behind DomainKeys, DKIM, Sender IDs, SPF and so on from the MTA level to the end-user and in this case allows a broader mass to use the feature.

The tool has still some hick-hacks but its working quite well and the developers trying to fix problems as fast as possible. There are a lot of implementations available at the moment, for different mail programs as well as webmail systems.

If you wanna use one of the above features in your mail environment please don’t hesitate to ask the internet or drop me a message, especially if you are also one of these guys trying to give SPAM no chance. And most important,  if you are using one of the incredible Ironport C-Series machines, setting up DomainKeys or DKIM verification is only a few clicks away 😉