Resolving 404 error using Web Deploy on IIS

I recently used Web Platform Installer to install Web Deploy 3 on IIS 8 so I could remotely develop a PHP site in WebMatrix. After installing and setting up a publishing profile in WebMatrix, a quick test showed a 404 returned by IIS error when attempting to connect with Web Deploy. I confirmed that the IIS Web Management Service (WMSvc) was started and configured properly. I also confirm proper IIS Manager permissions for the user I was using to connect with Web Deploy. WMSvc tracing showed IIS was returning a 404 error code when attempting to access https://servername:8172/MsDeploy.axd – the Web Deploy handler in IIS. After much troubleshooting, I stumbled across a stackoverflow post that described the fix. Even though I had installed Web Deploy via the Web Platform Installer, it appears it didn’t actual install the Web Deploy Handler. To resolve this, I manually ran the MSI installer for Web Deploy and selected the appropriate components. After a restart of WMSvc, I was able to successfully connect to IIS from WebMatrix via Web Deploy.

The Web Deploy Windows Installer can be downloaded here:

http://technet.microsoft.com/en-us/library/dd569059(v=ws.10).aspx

Linking spam sent through shared IIS SMTP server to a user

As a web host, one of the most time-consuming processes is investigating spam sent through mail servers. Many legit websites have forms and other functions that send email to users. If left unchecked, spammers can leverage these to send unsolicited mail.

In our environment, we enable the IIS SMTP role on our web servers and configure them to allow relaying only from localhost with basic authentication. This means that only local sites hosted in IIS can send mail and they have to provide a username and password to do so. Unfortunately, the IIS SMTP service does not log that username – it’s long been a point of contention with the IIS SMTP service. Most administrator’s recommendations suggest using another service, such as SmarterMail. However, there are ways to extract the authenticated username sending spam.

In order to use this method, you’ll need to capture a packet trace while spam is being sent. This will allow you to see the entire SMTP transaction between client and server. The catch here is that we are using localhost and most packet capture utilities cannot capture loopback traffic. Wireshark has an article that goes into detail about why it can’t capture loopback traffic. There is a utility that we can use called RawCap that will capture this local traffic at the socket level and output it into a format that Wireshark can parse. So, depending on the source of the spam, you’ll either want to use Wireshark (for remote) or RawCap (for local) to capture network data.

RawCap has an interactive prompt to guide you through the capture process:

Once you’ve capture sufficient traffic, you can cancel the capture by hitting Ctrl+C and then opening the resulting file in Wireshark for analysis. You’ll likely have a lot of network “noise” that you’ll want to filter out by using a filter of “smtp”:

From here, we can drill down to the AUTH LOGIN command sent by the client, and a 334 response from the server:

To explain what’s happening here, after the EHLO command, the server responds with what verbs it supports. The client then issues the AUTH LOGIN command and the server responds with “334 VXNlcm5hbWU6" where "VXNlcm5hbWU6"is a BASE64 encoded string "Username:". The client then responds with the BASE64 encoded username. We can decode this value on base64decode.org to find the username sending spam.