How a Smurf Attack Works

How a Smurf Attack Works

Smurf attacks are a type of denial of service attack, in which the Internet Control Message Protocol (ICMP) and broadcasts are being exploited. Normal ICMP requests (commonly referred to as pings) are used to verify network connectivity. But since they require a response from the target machine, they can maliciously be used to consume network resources if many are sent at once.

Broadcasts come into the equation, however, since they give capability to send requests to every computer on a network. Obviously if a broadcast were to be sent multiple times, the traffic would slow down the network. Imagine 100 computers sending back an ICMP request at the same time- network performance would take a huge dip.

It should be noted that smurf attacks work via an attacker spoofing the IP address of the broadcast. The IP address is actually the IP address of the victim the attacker chooses. When every computer on the network responds to the ICMP request, all of these requests go to the computer the attacker borrowed the IP address from. In this instance, the network only acts as an amplifier to the attack, not necessarily the victim.
Unfortunately, smurf attacks leave little room for victims to recover from an attack. Instead, the attack must be staved off at the network level via filtering. We can do this specifically through the no ip directed-broadcast command in Cisco routers.

No IP Directed-Broadcast
An IP Directed-Broadcast is simply an IP packet, of which has a destination address of a particular IP subnet. The broadcast in this instance is sent from a different network, as one could probably guess from the command name. (The broadcast is being directed via IP, not a unicast address.)

Keep in mind that if you are running a Cisco IOS version 12.0 or above, you do not need to follow these steps. No IP Directed-Broadcast was enabled by default after IOS 12.0. It is strongly recommended that No IP Directed-Broadcast be enabled if your IOS version is below 12.0. If you aren’t sure which version you have, simply type in the following commands from user exec mode:

As you can tell in the above example, the version number is higher than 12.0. In this instance, we would not need to take further action. If the number happens to be below 12.0, then you will need to apply the No IP Directed-Broadcast command. First, you should find out the naming convention for your router’s interfaces, as show below.


Now that we know our interface naming convention, FastEthernet 0/0, we can modify it. You may wish to write this down, since this will be what you will always refer to your interfaces to from now on. You may now proceed to apply the command to the interface, as seen below.


Note that we only applied this to a single interface (FastEthernet 0/0).It should be applied to all interfaces for maximum protection.

Closing Comments
Very few IP applications will make use of the IP directed broadcast, so it is almost always perfectly fine to leave it off. You can, however, configure access lists to permit or deny IP Directed-Broadcasts. This is usually only feasible with smaller networks, since access lists can be quite tedious to maintain on all but the smallest networks.

ASP.NET 1.1 WINDOWS SERVER 2003 IIS6.0 RUNNABLE CODES

ASP.NET 1.1 WINDOWS SERVER 2003 IIS6.0 RUNNABLE CODES

pASSWORD TEXT BOX - TextMode="password"

Enabling ASP.NET 2.0 in Vista RTM

Developing Web Applications on Windows Vista with Visual Studio 2005: Tip/Trick: Using IIS7 on Vista with VS 2005

Microsoft Windows Vista RC1 is now available to the public (view the press release), and many Visual Studio 2005 web developers are eager to start building ASP.NET 2.0 applications running under Internet Information Services 7.0, which is included with the Vista operating system. To build web apps under this environment, there are just a few steps you need to perform:



1. First, you need to install the IIS 7.0 and ASP.NET 2.0 Windows components, since they are not automatically installed by default. Because Visual Studio 2005 uses the IIS metabase APIs to create and configure applications in IIS, you must also install a metabase compatibility component for IIS 7.0. To do this, use the “Programs and Features” control panel in Vista, following the steps below.
To install IIS 7.0 and ASP.NET 2.0 on Windows Vista

1. In Windows Vista, open Control Panel and then click Programs and Features.

In the right pane, click Turn Windows features on or off.
The Windows Features dialog box opens.




2. Select the Internet Information Services check box.

3. Double-click (or expand) Web Management Tools, double-click IIS 6 Management Compatibility, and then select the IIS 6 Metabase and IIS 6 Configuration Compatibility check box.

4. Double-click (or expand) World Wide Web Services, double-click Application Development Features, and then select the ASP.NET check box.

Note The related options that are necessary for Web application development will automatically be selected.

5. Click OK to start the ASP.NET installation process.

Second, you must run Visual Studio 2005 in the context of an administrator account before you can develop web applications on Windows Vista. By default, Windows runs applications in a limited-privilege user account even when you are logged on to the computer as an administrator. To explicitly run Visual Studio as administrator, follow the steps below.



To run Visual Studio with administrative privileges in Windows Vista

1. In Windows Vista, click Start, click All Programs, and then locate Visual Studio.

2. Right-click Microsoft Visual Studio 2005, and then click Run as administrator.



One more note: If you happen to use SQL Server Express for database development, you'll also need to download and install SQL Server Express SP1, which contains updates required to run on Vista.

Enjoy developing on Vista and be sure to let us know what you think of IIS 7.0!



A few people have pinged me over the last week asking about how to use VS 2005 with an IIS 7.0 web-site on Windows Vista. Specifically, they've run into an issue where they see a dialog message asking them to install the FrontPage Server Extensions, or they get a "You must be a member of the administrators group" message when they try to connect (see dialog below):
quickly summarize you need to follow the below two steps to enable it:

1) You need to make sure that you have the the optional "IIS 6 Management Compatibility" option installed within IIS7. This installs an API for the new configuration system that is compatible with the old Metabase APIs (which is what VS 2005 uses). You can select this using the "Turn Windows Features on or Off" option in the Vista Control Panel:

2) You need to make sure you launch VS 2005 with "elevated" privledges so that you have admin privledges to connect to IIS (this is needed to debug a service, as well as create sites and/or change bindings that impact the entire machine). You can do this by right-clicking on the VS icon and select the "Run as Administrator" option when launching VS:


Note that this is needed even if your user is already in the administrators group if you have UAC enabled (which is on by default with Vista). If you disable UAC (which you can also do via the control panel), then this second step isn't required. Running VS 2005 with "elevated" privledges won't be required if you use the built-in VS 2005 Web-Server (since it has reduced privledges already). It is only required when connecting and running/debugging with IIS locally.

We'll be updating Visual Studio 2005 to have more accurate error messages to help guide you to the above steps more naturally in the future. Until then, just use the above steps and you are good to go.


In this post, I will share how I overcome this problem by manually performing extra steps to make ASP.NET works in Visual Studio 2005. Before I start, you should understand that Vista RTM installation comes with total security. That means all web development features are locked down.

The following steps will unlock the web development features so you can get back to your web development:

Open “Services”. Now you can do this very easy by typing Services in the search textbox located at the bottom of start menu panel.
Find “Windows Process Activation Service”. Change its Startup Type to Automatic, and “Start” the service.
Next, find “World Wide Publishing Service”. Notice that you can not directly start this service because it is in “disabled” state. The trick is by changing the Startup Type to Automatic first, then you can start this service.
Next, open “Command Prompt”. Again you can do this quickly by typing “cmd” in the search textbox.
Run this command “aspnet_regiis -i” inside ASP.NET 2.0 Framework folder. This will re-register ASP.NET 2.0 handlers and mapping to all existing web applications.
Finally, run this command “net start w3svc”. Your web server should be started perfectly at this time.
Try to open one of your HTTP project in Visual Studio 2005 and run one of your webform. Here you go.

Core Differences Between IIS and the ASP.NET Development Server

When testing an ASP.NET application locally, chances are you are using the ASP.NET Development Web Server. However, the production website is most likely powered IIS. There are some differences between how these web servers handle requests, and these differences can have important consequences. This tutorial explores some of the more germane differences.

The good news is that most web host providers have some sort of permissions tool that allows you to specify file system permissions in your website. Grant the anonymous ASP.NET account write access to the root directory and then revisit the book review page. (If needed, contact your web host provider for assistance on how to grant write permissions to the default ASP.NET account.) This time the page should load without error and the LastTYASP35Access.txt file should be created successfully.

The take away here is that because the ASP.NET Development Server operates under a different security context than IIS, it is possible that your ASP.NET pages that read or write to the file system, read from or write to the Windows Event Log, or read or write to the Windows registry will work as expected on development but generate exceptions when on production. When building a web application that will be deployed to a shared web hosting environment, do not read or write to the Event Log or the Windows registry. Also take note of any ASP.NET pages that read from or write to the file system as you may need to grant read and write privileges on the appropriate folders in the production environment.

Differences On Serving Static Content
Another core difference between IIS and the ASP.NET Development Server is how they handle requests for static content. Every request that comes into the ASP.NET Development Server, whether for an ASP.NET page, an image, or a JavaScript file, is processed by the ASP.NET runtime. By default, IIS only invokes the ASP.NET runtime when a request comes in for an ASP.NET resource, such as an ASP.NET web page, a Web Service, and so forth. Requests for static content - images, CSS files, JavaScript files, PDF files, ZIP files, and the like - are retrieved by IIS without the involvement of the ASP.NET runtime. (It is possible to instruct IIS to work with the ASP.NET runtime when serving static content; consult the "Performing Forms-Based Authentication and URL Authentication on Static Files with IIS 7" section in this tutorial for more information.)

The ASP.NET runtime performs a number of steps to generate the requested content, including authentication (identifying the requestor) and authorization (determining if the requestor has permission to view the requested content). A popular form of authentication is forms-based authentication, in which a user is identified by entering their credentials - usually a username and password - into textboxes on a web page. Upon validating their credentials, the website stores an authentication ticket cookie on the user's browser, which is sent with every subsequent request to the website and is what is used to authenticate the user. Moreover, it is possible to specify URL authorization rules that dictate what users can or cannot access a particular folder. Many ASP.NET websites use forms-based authentication and URL authorization to support user accounts and to define portions of the site that are only accessible to authenticated users or users that belong to a certain role.

Note: For a thorough examination of ASP.NET's forms-based authentication, URL authorization, and other user account-related features, be sure to check out my Website Security Tutorials.

Consider a website that supports user accounts using forms-based authorization and has a folder that, using URL authorization, is configured to only allow authenticated users. Imagine that this folder contains ASP.NET pages and PDF files and that the intent is that only authenticated users can view these PDF files.

What happens if a visitor attempts to view one of these PDF files by entering the URL directly in his browser's Address bar? To find out, let's create a new folder in the Book Reviews site, add some PDF files, and configure the site to use URL authorization to prohibit anonymous users from visiting this folder. If you download the demo application you'll see that I created a folder called PrivateDocs and added a PDF from my Website Security Tutorials (how fitting!). The PrivateDocs folder also contains a Web.config file that specifies the URL authorization rules to deny anonymous users:










Finally, I configured the web application to use forms-based authentication by updating the Web.config file in the root directory, replacing:

With:


Whenever a user visits an ASP.NET application his browser sends a request to the website. That request is picked up by the web server software, which coordinates with the ASP.NET runtime to generate and return the content for the requested resource. The Internet Information Services (IIS) are a suite of services that provide common Internet-based functionality for Windows servers. IIS is the most commonly used web server for ASP.NET applications in production environments; it's most likely the web server software being used by your web host provider to serve your ASP.NET application. IIS can also be used as the web server software in the development environment, although this entails installing IIS and properly configuring it.

The ASP.NET Development Server is an alternative web server option for the development environment; it ships with and is integrated into Visual Studio. Unless the web application has been configured to use IIS, the ASP.NET Development Server is automatically started and used as the web server the first time you visit a web page from within Visual Studio. The demo web applications we created back in the Determining What Files Need to Be Deployed tutorial were both file system-based web applications that were not configured to use IIS. Therefore, when visiting either of these websites from within Visual Studio the ASP.NET Development Server is used.

In a perfect world the development and production environments would be identical. However, as we discussed in the preceding tutorial it is not uncommon for the environments to have differing configuration settings. Using different web server software in the environments adds another variable that must be taken into consideration when deploying an application. This tutorial covers the key differences between IIS and the ASP.NET Development Server. Because of these differences there are scenarios where code that runs flawlessly in the development environment throws an exception or behaves differently when executed in production.

Security Context Differences
Whenever the web server software handles an incoming request it associates that request with a particular security context. This security context information is used by the operating system to determine what actions are permissible by the request. For example, an ASP.NET page might include code that logs some message to a file on disk. In order for this ASP.NET page to execute without error, the security context must have the appropriate file system-level permissions, namely write permissions on that file.

Using the ASP.NET Development Server, visit the site and enter the direct URL to one of the PDF files in your browser's Address bar. If you downloaded the website associated with this tutorial the URL should look something like: http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf

Entering this URL into the Address bar causes the browser to send a request to the ASP.NET Development Server for the file. The ASP.NET Development Server hands off the request to the ASP.NET runtime for processing. Because we have not yet logged in, and because the Web.config in the PrivateDocs folder is configured to deny anonymous access, the ASP.NET runtime automatically redirects us to the login page, Login.aspx (see Figure 3). When redirecting the user to the log in page, ASP.NET includes a ReturnUrl querystring parameter that indicates the page the user was attempting to view. After successfully logging in the user can be returned to this page.



The ASP.NET Development Server associates incoming requests with the security context of the currently logged on user. If you are logged on to your desktop as an administrator, then the ASP.NET pages served by the ASP.NET Development Server will have the same access rights as an administrator. However, ASP.NET requests handled by IIS are associated with a specific machine account. By default, the Network Service machine account is used by IIS versions 6 and 7, although your web host provider may have configured a unique account for each customer. What's more, your web host provider has likely given limited permissions to this machine account. The net result is that you may have web pages that execute without error in the development environment, but generate authorization-related exceptions when hosted in the production environment.

To show this type of error in action I've created a page in the Book Reviews website that creates a file on disk that stores the most recent date and time someone viewed the Teach Yourself ASP.NET 3.5 in 24 Hours review. To follow along, open the ~/Tech/TYASP35.aspx page and add the following code to the Page_Load event handler:

protected void Page_Load(object sender, EventArgs e)
{
string filePath = Server.MapPath("~/LastTYASP35Access.txt");
string contents = string.Format("Last accessed on {0} by {1}",
DateTime.Now.ToString(), Request.UserHostAddress);

System.IO.File.WriteAllText(filePath, contents);
}

Note: The File.WriteAllText method creates a new file if it does not exist and then writes the specified contents to it. If the file already exists, it's existing content is overwritten.