Monu

How DSL is working

All of us are either a DSL user or just heard about DSL. Everybody knows what DSL (Digital Subscriber Line) is. It’s just high speed internet over legacy telephone line. Do you know what is behind it? How it’s working. Some of you might hear that port is not available when applying a new DSL connection. What is this port? Which port they mentioning?

Well I will explain you what does it mean

First of all how a legacy telephone line becomes DSL line?

        It requires a device, DSLAM (Digital Subscriber Line Access Multiplexer). DSLAM delivers exponentially high-speed data transmission over existing copper telephone line. A DSLAM separates the voice frequency signals from the high speed data traffic and controls and routes Digital Subscriber Line traffic between the subscriber’s equipment (DSL Modem) and the service provider’s network. DSLAM has lines (ports) and which is identical to telephone Exchange system. Let’s say DSLAM with 48ports or 192 ports. This can covert 48 or 192 lines of legacy exchange to DSL. So whenever you heard no port available, this means lack of ports in DSLAM.

Remember we are speaking about IP DSLAM (Internet Protocol DSLAM) .Traditional 20th century DSLAM used Asynchronous Transfer Mode (ATM) technology to connect to upstream ATM routers/switches. These devices then extract the IP traffic and pass it on to an IP network. IP-DSLAMs extract the IP traffic at the DSLAM itself. Thus it is all IP from there. Advantage of IP-DSLAM over a traditional ATM DSLAM is in terms of lower capital expenditure and operational expenditure and a richer set of features and functionality.

Below diagram will explain you the function more clearly

Security is fundamentally about protecting assets. Assets may be tangible items, such

as a Web page or your customer database — or they may be less tangible, such as

your company’s reputation.

Security is a path, not a destination. As you analyze your infrastructure and applications, you identify potential threats and understand that each threat presents a degree of risk. Security is about risk management and implementing effective countermeasures.

The Foundations of Security

Security relies on the following elements:

● Authentication

Authentication addresses the question: who are you? It is the process of uniquely identifying the clients of your applications and services. These might be end users, other services, processes, or computers. In security parlance, authenticated clients are referred to as principals.

● Authorization

Authorization addresses the question: what can you do? It is the process that governs the resources and operations that the authenticated client is permitted to access. Resources include files, databases, tables, rows, and so on, together with system-level resources such as registry keys and configuration data. Operations include performing transactions such as purchasing a product, transferring money from one account to another, or increasing a customer’s credit rating.

● Auditing

Effective auditing and logging is the key to non-repudiation. Non-repudiation guarantees that a user cannot deny performing an operation or initiating a transaction. For example, in an e-commerce system, non-repudiation mechanisms are required to make sure that a consumer cannot deny ordering 100 copies of a particular book.

● Confidentiality

Confidentiality, also referred to as privacy, is the process of making sure that data remains private and confidential, and that it cannot be viewed by unauthorized users or eavesdroppers who monitor the flow of traffic across a network. Encryption is frequently used to enforce confidentiality. Access control lists (ACLs) are another means of enforcing confidentiality.

Integrity

Integrity is the guarantee that data is protected from accidental or deliberate (malicious) modification. Like privacy, integrity is a key concern, particularly for data passed across networks. Integrity for data in transit is typically provided by using hashing techniques and message authentication codes.

● Availability

From a security perspective, availability means that systems remain available for legitimate users. The goal for many attackers with denial of service attacks is to crash an application or to make sure that it is sufficiently overwhelmed so that other users cannot access the application.

Threats, Vulnerabilities, and Attacks Defined

A threat is any potential occurrence, malicious or otherwise, that could harm an asset. In other words, a threat is any bad thing that can happen to your assets. A vulnerability is a weakness that makes a threat possible. This may be because of poor design, configuration mistakes, or inappropriate and insecure coding techniques. Weak input validation is an example of an application layer vulnerability, which can result in input attacks. An attack is an action that exploits a vulnerability or enacts a threat. Examples of attacks include sending malicious input to an application or flooding a network in an attempt to deny service.

To summarize, a threat is a potential event that can adversely affect an asset, whereas

a successful attack exploits vulnerabilities in your system.

A vulnerability in a network will allow a malicious user to exploit a host or an application.

A vulnerability in a host will allow a malicious user to exploit a network or an application.

A vulnerability in an application will allow a malicious user to exploit a network or a host

• Asset. A resource of value such as the data in a database or on the file system, or a system resource

• Threat. A potential occurrence — malicious or otherwise — that may harm an asset

• Vulnerability. A weakness that makes a threat possible

• Attack (or exploit). An action taken to harm an asset

• Countermeasure. A safeguard that addresses a threat and mitigates risk

General Web Application Security Recommendations

Even the most elaborate application security can fail if a malicious user can use simple ways to gain access to your computers. General Web application security recommendations include the following:

·                  Back up data often and keep your backups physically secure.

·                  Keep your Web server physically secure so that unauthorized users cannot gain access to it, turn it off, physically steal it, and so on.

·                  Use the Windows NTFS file system, not FAT32. NTFS offers substantially more security than FAT32. For details, see the Windows Help documentation.

·                  Protect the Web server and all of the computers on the same network with strong passwords.

·                  Close any unused ports and turn off unused services.

·                  Run a virus checker that monitors site traffic. Use a firewall

·                  Learn about and install the latest security updates from Microsoft and other vendors.

·                  Use Windows event logging and examine the logs frequently for suspicious activity. This includes repeated attempts to log on to your system and excessive requests against your Web server.

Run Applications with Minimum Privileges

When your application runs, it runs within a context that has specific privileges on the local computer and potentially on remote computers. To run with the minimum number of privileges needed, follow these guidelines:

·                  Do not run your application with the identity of a system user (administrator).

·                  Run the application in the context of a user with the minimum practical privileges.

·                  Set permissions (ACLs, or Access Control Lists) on all the resources required for your application. Use the most restrictive setting. For example, if practical in your application, set files to be read-only.

·                  Keep files for your Web application in a folder below the application root. Do not allow users the option of specifying a path for any file access in your application. This helps prevent users from getting access to the root of your server.

Know Your Users

In many applications, it is possible for users to access the site without having to provide credentials. If so, your application accesses resources by running in the context of a predefined user. By default, this context is the local ASPNET user (Windows 2000 or Windows XP) or NETWORK SERVICE user (Windows Server 2003) on the Web server.

To restrict access to users who are authenticated, follow these guidelines:

·                  If your application is an intranet application, configure it to use Windows Integrated security. This way, the user's login credentials can be used to access resources.

·                  If you need to gather credentials from the user, use one of the ASP.NET authentication strategies.

Guard Against Malicious User Input

As a general rule, never assume that input you get from users is safe. It is easy for malicious users to send potentially dangerous information from the client to your application. To help guard against malicious input, follow these guidelines:

·                  In forms, filter user input to check for HTML tags, which might contain script.

·                  Never echo (display) unfiltered user input. Before displaying untrusted information, encode HTML to turn potentially harmful script into display strings.

·                  Similarly, never store unfiltered user input in a database.

·                  If you want to accept some HTML from a user, filter it manually. In your filter, explicitly define what you will accept. Do not create a filter that tries to filter out malicious input; it is very difficult to anticipate all possible malicious input.

·                  Do not assume that information you get from the header (usually via the Request object) is safe. Use safeguards for query strings, cookies, and so on. Be aware that information that the browser reports to the server (user agent information) can be spoofed, in case that is important in your application.

·                  If possible, do not store sensitive information in a place that is accessible from the browser, such as hidden fields or cookies. For example, do not store a password in a cookie.

·                  View state is stored in a hidden field in an encoded format. By default, it includes a message authentication code (MAC) so that the page can determine whether view state has been tampered with.

Access Databases Securely

Databases typically have their own security. An important aspect Web application security is designing a way for the application to access the database securely. Follow these guidelines:

·                  Use the inherent security of your database to limit who can access database resources. The exact strategy depends on your database and your application:

·                                  If practical in your application, use Windows Integrated security so that only Windows-authenticated users can access the database. Integrated security is more secure than using SQL Server standard security.

·                                  If your application uses anonymous access, create a single user with very limited permissions, and perform queries by connecting as this user.

·                  Do not create SQL statements by concatenating strings that involve user input. Instead, create a parameterized query and use user input to set parameter values.

·                  If you must store a user name and password somewhere to use as the database login credential, store them securely. If practical, encrypt or hash them.

Create Safe Error Messages

If you are not careful, a malicious user can deduce important information about your application from the error messages it displays. Follow these guidelines:

·                  Do not write error messages that echo information that might be useful to malicious users, such as a user name.

·                  Configure the application not to show detailed errors to users. If you want to display detailed error messages for debugging, check first that the user is local to the Web server.

·                  Use the customErrors configuration element to control who can view exceptions from the server.

·                  Create custom error handling for situations that are prone to error, such as database access.

Keep Sensitive Information Safely

Sensitive information is any information that you need to keep private. A typical piece of sensitive information is a password or an encryption key. If a malicious user can get to the sensitive information, then the data protected by the secret is compromised. Follow these guidelines:

·                  If your application transmits sensitive information between the browser and the server, consider using Secure Sockets Layer (SSL.

·                  Use Protected Configuration to secure sensitive information in configuration files such as the Web.config or Machine.config files.

·                  If you must store sensitive information, do not keep it in a Web page, even in a form that you think people will not be able to view (such as in server code).

·                  Use the strong encryption algorithms supplied in the System.Security.Cryptography namespace.

Use Cookies Securely

Cookies are an easy and useful way to keep user-specific information available. However, because cookies are sent to the browser's computer, they are vulnerable to spoofing or other malicious use. Follow these guidelines:

·                  Do not store any critical information in cookies. For example, do not store a user's password in a cookie, even temporarily. As a rule, do not store any sensitive information in a cookie that. Instead, keep a reference in the cookie to a location on the server where the information is located.

·                  Set expiration dates on cookies to the shortest practical time you can. Avoid permanent cookies if possible.

·                  Consider encrypting information in cookies.

·                  Consider setting the Secure and HttpOnly properties on your cookies to true.

Guard Against Denial-of-Service Threats

An indirect way that a malicious user can compromise your application is by making it unavailable. The malicious user can keep the application too busy to service other users, or if nothing else can simply crash the application. Follow these guidelines:

·                  Close or release any resource you use. For example, always close data connections and data readers, and always close files when you are done using them.

·                  Use error handling (for example, try/catch blocks). Include a finally block in which you release resources in case of failure.

·                  Configure IIS to use throttling, which prevents an application from using a disproportionate amount of CPU.

·                  Test size limits of user input before using or storing it.

·                  Put size safeguards on database queries to help guard against large queries using up system resources.

·                  Put a size limit on file uploads, if those are part of your application. You can set a limit in the Web.config file using syntax such as the following code example, where the maxRequestLength value is in kilobytes:

<configuration>

           <system.web>

                       <httpRuntime maxRequestLength=”5120”/>

           </system.web>

You can also use the RequestLengthDiskThreshold property in to reduce the memory overhead of large uploads and form posts.

How To: Secure Your Developer Workstation

  Improving Web Application Security: Threats and Countermeasures

Summary: This How To helps you improve your development workstation security. Developers often have computers running software such as IIS, Microsoft SQL Server, or the Microsoft SQL Server Desktop Engine (MSDE.) For example, Microsoft Visual Studio® .NET is designed for local development with IIS, so it is common for a developer to run IIS locally. As a developer, you need to be able to secure these services against attack, even if your computer is in a protected local area network.

This How To provides quick tips to help you improve the security of your developer workstation, along with tips about how to keep it secure. It also helps you avoid common problems that you are likely to encounter when you secure your workstation. Finally, it provides tips about how to determine problems and to revert security settings if they prove too restrictive.

Note   This How To is not exhaustive, but it highlights many of the key issues.

Before You Begin

Before you begin securing your workstation, you need the following tools:

·                  Microsoft Baseline Security Analyzer (MBSA). Microsoft provides the MBSA tool to help analyze the security configuration of your computers and to identify missing patches and updates. You can download the MBSA tool from http://www.microsoft.com/technet/security/tools/mbsahome.mspx.

·                  IISLockdown. The IISLockdown tool reduces your computer's attack surface by hardening default IIS and Windows configuration settings and by removing unnecessary IIS extensions. IISLockown also installs the "404.dll" ISAPI filter, which is used to report "404 File Not Found" messages when disabled extensions are requested.

You can download the IISLockdown tool from http://download.microsoft.com/download/iis50/Utility/2.1/NT45XP/EN-US/iislockd.exe.

·                  URLScan. URLScan is an ISAPI filter that rejects or allows HTTP requests based on a configurable set of rules. It is integrated with IISLockdown, although you can also download it separately. It comes with customizable templates for each supported server role.

To install URLScan without IISLockdown, see Microsoft Knowledge Base article 307608, "INFO: Availability of URLScan Version 2.5 Security Tool," at http://support.microsoft.com/default.aspx?scid=kb;en-us;307608, in the Microsoft Knowledge Base.

Steps to Secure Your Developer Workstation

To secure your developer workstation, perform the following tasks:

·                  Run using a least privileged account

·                  Patch and update

·                  Secure IIS

·                  Secure SQL Server and MSDE

·                  Evaluate your configuration categories

·                  Stay secure

Run Using a Least-Privileged Account

You should develop applications using a non administrator account. Doing so is important primarily to limit the exposure of the logged on user and to help you to design more secure software. For example, if you design, develop, and test an application while you are interactively logged in as an administrator, you are much more likely to end up with software that requires administrative privileges to run.

You should not generally log on using the local administrator account. The account that you use on a daily basis should not be a member of the local Administrators group. Sometimes you might still need an account that has administrative privileges — for example, when you install software or edit the registry. Because the default local administrator account is well known, however, and it is the target of many attacks, create a non-standard administrator account and use this only when it is required.

To create accounts for development

1.                  Remove your current user account from the Administrators group if it is a member.

2.                  Create a new custom administration account using a nonstandard name and strong password.

3.                  Use your non-administrator account to logon interactively on a daily basis. When you need to run a command with administrative privileges, use your custom administration account with the Runas.exe command line utility.

Running Privileged Commands

To run a privileged command, you can use one of the following techniques to temporarily change your security context:

·                  Use the Runas.exe utility from a command line. The following command shows you how to use the Runas.exe utility to launch a command console that runs under your custom administration account.

By executing Cmd.exe, you start a new command window that runs under the security context of the user you specify with the /user switch. Any program you launch from this command window also runs under this context.

·                  Use Run As from Windows Explorer. You can right-click an executable file in Windows Explorer and click Run As. To display this item on Windows 2000 or Windows Server 2003, hold down the SHIFT key and then right-click an executable file. When you click Run As, you are prompted for the credentials of the account you want to use to run the executable file.

·                  Use Run As shortcuts. You can create quick launch and desktop shortcuts to easily run applications using a privileged user account. The following example shows a shortcut that you can use to run Windows Explorer (Explorer.exe) using the administrator account:

Note   If using a non-administrator account proves impractical for your environment, still test your application or component while running as a least privileged user to catch and correct problems before deploying. For example, your application might incorrectly require administrator privileges without your realizing it, which would cause the application to fail when it is deployed in a production environment.

Patch and Update

Ensure that your workstation has the latest service packs and patches. Check the operating system, IIS, SQL Server, MSDE, Microsoft Data Access Components (MDAC), and the .NET Framework. Microsoft offers several tools and methods to help you scan and update your system. These include the Windows Update site, the Microsoft Baseline Security Analyzer (MBSA) tool, and the Automatic Updates feature.

Using Windows Update

You can use Windows Update (available from the Start menu) to scan for updates and patches for Windows. Alternatively, you can directly scan for updates at http://windowsupdate.microsoft.com.

Note   After you update your system using the Windows Update site, use MBSA to detect missing updates for SQL Server, MSDE, and MDAC.

Using MBSA

You can use MBSA to assess security and to verify patches. If you used automatic updates or Windows Update to update your operating system and components, MBSA verifies those updates and additionally checks the status of updates for SQL Server and Microsoft Exchange Server. MBSA lets you create a script to check multiple computers.

To detect and install patches and updates

1.                  Download MBSA from the MBSA home page at http://www.microsoft.com/technet/security/tools/mbsahome.asp.

If you do not have Internet access when you run MBSA, MBSA cannot retrieve the XML file that contains the latest security settings from Microsoft. You can use another computer to download the XML file, however. Then you can copy it into the MBSA program directory. The XML file is available at http://download.microsoft.com/download/xml/security/1.0/nt5/en-us/mssecure.cab.

2.                  Run MBSA by double-clicking the desktop icon or selecting it from the Programs menu.

3.                  Click Scan a computer. MBSA defaults to the local computer.

4.                  Clear all check boxes except for Check for security updates. This option detects which patches and updates are missing.

5.                  Click Start scan. Your server is now analyzed. When the scan completes, MBSA displays a security report, which it also writes to the %Userprofile%\SecurityScans directory.

6.                  Download and install the missing updates. Click Result details next to each failed check to view the list of missing security updates.

The resulting dialog box displays the Microsoft security bulletin reference number. Click the reference to find out more about the bulletin and to download the update.

For more information about using MBSA, see "How To: Use Microsoft Baseline Security Analyzer (MBSA)," in the How To section of this guide.

Note   MBSA will not indicate required .NET Framework updates and patches. Browse the .NET Framework downloads page at http://msdn.microsoft.com/netframework/downloads/default.asp.

Using Automatic Updates

The Automatic Updates feature offers the easiest method to update your operating system with the latest critical security patches. The feature is built into Windows XP, Windows Server 2003 and is installed with Windows 2000 Service Pack 3.

To configure Automatic Updates with Windows 2000, click Automatic Updates in the Control Panel. For more information about Automatic Updates and Windows 2000, see Microsoft Knowledge Base article 327850, "How To: Configure and Use Automatic Updates in Windows 2000."

To configure Automatic Updates with Windows XP

1.                  Right-click the My Computer icon on the desktop or the System icon in Control Panel.

2.                  Click System Properties.

For more information about Automatic Updates and Windows XP, see Microsoft Knowledge Base article, 306525, "How To: Configure and Use Automatic Updates in Windows XP."

Note   For more information about Automatic Updates for Windows Server 2003, see Microsoft Knowledge Base article 327838, "How to schedule automatic updates in Windows Server 2003, in Windows XP, and in Windows 2000."

Automatic Updates scans and installs updates for the following operating systems (including the .NET Framework and IIS where applicable):

·                  Microsoft Windows 2000 Professional

·                  Microsoft Windows 2000 Server

·                  Microsoft Windows XP Professional

·                  Microsoft Windows Server 2003

In addition to using Automatic Updates, use MBSA to detect missing updates for SQL Server, MSDE and MDAC.

Secure IIS

You often need to run IIS locally for Web development. If you run IIS, secure it. IISLockdown and URLScan significantly reduce your Web server's attack profile. IISLockdown points unused or forbidden script mappings to 404.dll and helps secure access to system directories and system tools. URLScan blocks known dangerous requests.

Although IISLockdown improves IIS security, if you choose the wrong installation options or do not modify the URLScan configuration file, URLScan.ini, you could encounter the following issues:

·                  You cannot create new ASP.NET Web applications. NTFS file system permissions are configured to strengthen default access to Web locations. This may prevent the logged on user from creating new ASP.NET Web applications.

·                  Cannot debug existing ASP.NET Web applications. URLScan blocks the DEBUG verb, which is used when you debug ASP.NET Web applications.

The following steps show you how to improve IIS security on your development workstation and avoid the issues listed above:

·                  Install and run IISLockdown

·                  Configure URLScan

·                  Restrict access to the local Web server

Install and Run IISLockdown

Note   By default, IIS 6.0 has security-related configuration settings similar to those made by the IIS Lockdown Tool. Therefore you do not need to run the IIS Lockdown Tool on Web servers running IIS 6.0. However, if you are upgrading from a previous version of IIS (5.0 or lower) to IIS 6.0, it is recommended that you run the IIS Lockdown Tool to enhance the security of your Web server.

To install and run IISLockdown

1.                  Run the IISLockdown installation program (Iislockd.exe) from http://download.microsoft.com/download/iis50/Utility/2.1/NT45XP/EN-US/iislockd.exe.

Note   If you run Iislockd.exe a second time, it removes all changes based on the log file \WINNT\System32\Inetsrv\oblt-log.log.

2.                  During setup, choose the Dynamic Web Site option, and choose the option to install URLScan. ASP.NET Web Forms use the HTTP POST verb. Choosing the static option and installing URLScan blocks the POST verb in URLScan.ini.

Continued at http://maneeshpnair.spaces.live.com/blog/cns!80E0D4743A9BF96C!238.entry