Nuffnang

Sunday, October 2, 2011

How to rebuild the domain SYSVOL replica set across enterprise environments

This section describes how to rebuild the domain SYSVOL replica set across enterprise environments.

Summary of the steps

The following is a summarized list of steps that are performed in a hub or branch restart:

  1. Stop the FRS on all domain controllers in the domain.
  2. Move all files and folders that should reside in the SYSVOL tree to a temporary folder on the reference domain controller. The temporary folder should be located on the same partition the SYSVOL tree is located.

    Note When you move files within a partitions, the files are not altered. Therefore, they retain their original security settings. Files or Folders that are moved partitions or copied within or between partitions inherit the security of the destination parent directory. Therefore, any custom delegations of GPO management may be lost as a result. Additionally, the access control list (ACL) on the SYSVOL part of the Group Policy object is set to inherit permissions from the parent folder. Therefore, you may receive the following error message when you open a GPO by using GPMC:

The Permissions for This GPO in the SYSVOL Folder Are Inconsistent with Those in Active Directory

If you have permissions to modify security on the GPO, click OK when you receive this error message. This action modifies the ACLs on the Sysvol part of the Group Policy object and makes them consistent with the ACLs on the Active Directory component. In this case, Group Policy removes the inheritance attribute in the Sysvol folder.

  1. Verify junction points and required folders on each domain controller in the domain.
  2. Restart the FRS on the reference domain controller with the D4 registry entry set.
  3. Restart the FRS on all other domain controllers in the domain with the D2 registry entry set.
  4. On the reference domain controller, move all files and folders to the root folder of the replica set. By default, this folder is the C:\Windows\Sysvol\Domain folder.
  5. Monitor the consistency of files and folders for all domain controllers in the domain.

Note If a member of any replica set has been restarted with the Burflags registry entry set to D4, restart the FRS on all other members of the replica set with the Burflags registry entry set to D2. This configuration prevents morphed folders.

When the Burflags registry entry is set to D2 or to D4, and the FRS is restarted, the originator GUID (OrigGUID) changes. If you want to track the source of a specific activity, you can run the File Replication Service Diagnostics Tool (FRSDiag) to obtain GUID2Name before you set the Burflags registry entry.

Detailed list of the steps

The following is a detailed list of steps that are performed in a hub or branch restart:

  1. On all domain controllers in the domain, stop the FRS, and then set the service startup type value for the FRS to Disabled.
  2. On a single domain controller, configure the SYSVOL replica set to be authoritative. This reference domain controller will contain the authoritative copy of the SYSVOL tree for all other members of the replica set. For example, other domain controllers in the domain will directly or transitively replicate from this reference domain controller.

    Choose the reference domain controller based on connectivity and physical server resources. This domain controller will be known as the "reference domain controller" in all subsequent steps.

    To configure the SYSVOL replica set to be authoritative, follow these steps:

a. Click Start, click Run, type regedit, and then click OK.

b. Locate and then click the BurFlags entry under the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID

GUID is the GUID of the domain system volume replica set that is shown in the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets\GUID

c. Right-click BurFlags, and then click Modify.

d. Type D4 in the Value Data field (HexaDecimal), and then click OK.

On all domain controllers in the domain, verify that the file structure and junction points are correct. To do this, follow these steps:

. Verify that the following folders exist in the SYSVOL tree :

\SYSVOL
\SYSVOL\domain
\SYSVOL\staging\domain
\SYSVOL\staging areas
\SYSVOL\domain\Policies
\SYSVOL\domain\scripts
\SYSVOL\SYSVOL

a. Verify that the following reparse points exist:

\SYSVOL\SYSVOL\ DNS Domain Name
This reparse point must be linked to the \SYSVOL\domain folder.

\SYSVOL\staging areas\DNS Domain Name
This reparse point must be linked to the \SYSVOL\staging\domain folder.

The default path for the SYSVOL tree is under the \WINDOWS or \WINNT folder on the partition where the operating system is installed. However, the SYSVOL tree may be installed on any partition that is formatted by using the NTFS file system.

Verify that each domain controller in the domain has all the required folders and that the reparse points exists. Re-create any missing folders as needed. Do not use Windows Explorer to move or copy contents of the SYSVOL tree, or the reparse points may be damaged.

The SYSVOL tree contains reparse points to other folders in the SYSVOL tree. These reparse points are in the NTFS file system. Think of a reparse point as a source folder that maps or points to a destination folder when the source folder is accessed. The contents of the reparsed folders appear as mirror images of each other.

The following two reparse points for a SYSVOL tree are installed in the C:\WINNT\SYSVOL folder:

  • C:\WINNT\SYSVOL\SYSVOL\DNS Domain Name.
    This reparse point is linked to the C:\WINNT\SYSVOL\domain folder.
  • C:\WINNT\SYSVOL\staging areas\DNS Domain Name
    This reparse point is linked to C:\WINNT\SYSVOL\staging\domain folder.

On each domain controller in the domain, follow these steps:

  1. Click Start, click Run, type cmd, and then click OK.
  2. Type net start ntfrs to start the File Replication service.
  3. Type ntfrsutl ds |findstr /i "root stage", and then press ENTER. The NTFRSUTIL command returns the current root directory for the SYSVOL replica set that is referred to as the “replica set root” and the staging folder. For example, this command returns:

Root: C:\WINNT\SYSVOL\domain
Stage: C:\WINNT\SYSVOL\staging\domain

  1. Type Linkd %systemroot%\SYSVOL\SYSVOL\ DNS Domain name, and then press ENTER. The LINKD command returns the following:

Source DNS Domain Name is linked to %systemroot%\SYSVOL\domain

  1. Type linkd "%systemroot%\SYSVOL\staging areas\DNS Domain Name", and then press ENTER. This command returns the following:

Source DNS Domain Name is linked to %systemroot%\SYSVOL\Staging\domain

Note The path that is reported by the LINKD command varies depending on the location of the SYSVOL\SYSVOL\DNS Domain Name folder. If the SYSVOL folder is in the default location in the %systemroot%\SYSVOL folder, use the commands that are listed. Otherwise, type the actual path of the SYSVOL folders.

For example, if the NTFRSUTL and LINKD commands are run on a domain controller in the contoso.com domain, and the SYSVOL folder is in the C:\Windows\SYSVOL folder, the command syntax and results for the SYSVOL and Staging folders will appear similar to the following:

C:\>ntfrsutl ds |findstr /i "root stage"

Root: C:\windows\sysvol\domain

Stage: C:\windows\sysvol\staging\domain

C:\>Linkd %systemroot%\SYSVOL\SYSVOL\Contoso.com

Source domain.com is linked to

C:\WINDOWS\SYSVOL\domain

C:\>linkd “%systemroot%\SYSVOL\staging areas>\Contoso.com

Source domain.com is linked to

C:\WINDOWS\SYSVOL\staging\domain

To re-create the junction points if the LINKD command reports missing or invalid junction points, follow these steps:

    1. Type linkd C:\WINNT\SYSVOL\sysvol\DNS_Domain_Name Source, where Source is the root path that is determined by using the NTFRSUTL command.
    2. Type C:\linkd "C:\WINNT\SYSVOL\staging areas\DNS_Domain_Name " Source, where Source is the stage path that is determined by using the NTFRSUTL command.

For more information about creating junction points, click the following article number to view the article in the Microsoft Knowledge Base:

  1. On all domain controllers in the domain, verify that enough staging space is available. The ratio of staging area size to data set size depends upon a range of factors. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

To determine the size of the replica set root, right-click the replica set root that uses the Winnt\SYSVOL\domain folder in Windows Explorer, and then click Properties.

To adjust the staging folder size, follow these steps:

a. Click Start, click Run, type regedit, and then click OK.

b. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters

c. Right-click Staging Space Limit in KB, and then click Modify.

d. Click decimal, type the size of the staging folder in kilobytes, and then click OK.

e. Quit Registry Editor.

On the reference domain controller, build a good set of policies and scripts, and then put them in a temporary folder outside the SYSVOL replica set folders on the FRS reference domain controller.

To complete this step, examine Active Directory to determine the group policies that are still used and that contain orphaned data. Policy information is located in the Group Policies container. To view this container, follow these steps:

. Start Active Directory Users and Computers.

a. On the View menu, click Advanced Features if it is not already selected.

b. Expand the domain container, expand the System container, and then expand the Policies container.

In the right pane of Active Directory Users and Computers, all the Group Policy objects (GPOs) in Active Directory are listed. There should be a one-to-one mapping between valid GPOs in Active Directory with Group Policy folders in the SYSVOL tree.

§ If the SYSVOL folder contains a folder name that has a GUID that is not listed in Active Directory, the file system contains an orphaned GPO, and you can safely delete the folder from the file system.

§ If Active Directory contains a Group Policy GUID that does not map to a GUID in the SYSVOL\domain\policies folder on any domain controller in the domain, you can safely delete that policy setting from Active Directory.

Note If any domain controller that is participating in the domain has a newer version of a Group Policy in its local SYSVOL tree, make sure that it is copied to a temporary location on the reference domain controller.

c. On the reference domain controller, delete any files or folders that are in the FRS replica set root or in the replica set stage folders.

For default SYSVOL replica sets, delete files and folders under the following two folders:

C:\WINNT\SYSVOL\domain
C:\WINNT\SYSVOL\staging\domain



Note Do not delete the folders themselves.

d. On the reference domain controller, move the policies and scripts folders and the folder contents from the temporary location that you used in step c to the FRS replica set root folder. For the SYSVOL folder, the default location for the replica set root is the following folder:

C:\WINNT\SYSVOL\domain

e. On all domain controllers except the reference domain controller, configure the FRS to be non-authoritative. To do this, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the BurFlags entry under the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID

GUID is the GUID of the domain system volume replica set that is shown in the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets\GUID

3. On the Edit menu, point to New, and then click DWORD Value.

4. Type D2 for the name of the DWORD, and then press ENTER.

Note For domain controllers that are not participating in Distributed File System (DFS) replication, set the DWORD to D2 in the following registry subkey for bulk modifications:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process atStartup\BurFlags

f. Quit Registry Editor.

The FRS is instructed to reinitialize its database and to overwrite the contents of the SYSVOL tree with data from an upstream partner.

In large sites, we recommend that you use a staggered approach to rebuilding the SYSVOL tree. This approach helps avoid overloading a single domain controller or causing the FRS to source its contents from a domain controller that has not completed its own re-sourcing of the system volume. This process involves setting the Burflags registry entry to D2 on all hub site domain controllers before proceeding to branch office or to satellite sites.

Use the Replica Set Parent registry entry to specify a source domain controller for the D2 setting:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\SYSVOL Seeding\DOMAIN SYSTEM VOLUME (SYSVOL SHARE)

o Replica Set Parent
Type: REG_SZ
Value: The source domain controller

Note If this registry entry does not exist, you must create it.

We recommend that a single domain controller not become the source for more than 10 to 15 domain controllers at the same time. If you must source more than 15 domain controllers off a single source, start the FRS on only 15 downstream partners of any particular source domain controller, and then wait for them to complete sourcing the SYSVOL tree before the FRS service is started on the next group of 15 computers.

Notes

o We do not recommend that more than 15 domain controllers source their contents off of a single domain controller at the same time.

o Incoming replication depends on a schedule that is defined on the relevant site link or on the connection object that is used by the destination domain controller that allows replication. If the replication schedule is disabled, incoming replication will be delayed.

o If the “Replica set parent” registry entry is used, the FRS will source data upon restart of the service, independent of the whether replication is enabled or disabled on the day or the hour that the service restart occurred. After the initial source is complete, all additional replication will be based on connection schedules. If the registry entry is not used, the FRS will initiate replication based on the schedule that is defined on the relevant site link or connection object.

On all domain controllers in the domain except the reference domain controller, delete any files or folders under the FRS replica set root and the replica set stage directories. For example, for default SYSVOL replica sets, delete files and folders in the following two locations:

C:\WINNT\SYSVOL\domain
C:\WINNT\SYSVOL\staging\domain

Note Do not delete the folders themselves.

This step enables faster replication of the SYSVOL tree for the given source. This step eliminates the need for the FRS server to move the existing contents before replicating the new data. This step is not required but it is recommended.

On all domain controllers in the hub site, except the reference domain controller, restart FRS, and then verify that SYSVOL and NETLOGON are shared.

Note The service startup type for the FRS should be set to Automatic.

On all non-reference domain controllers in the branch sites, start the FRS service and verify that SYSVOL and NETLOGON are shared.

How to temporarily stabilize the domain SYSVOL tree

  1. Stop FRS on all domain controllers in the domain and set the service to Disabled.
  2. Manually copy the full set of policies to the following folder on each domain controller:

\SYSVOL\SYSVOL\dns domain name\policies

Typically, the following two policies are required for authentication:

    • Default Domain Controllers Policy {6AC1786C-016F-11D2-945F-00C04fB984F9}
    • Default Domain Policy {31B2F340-016D-11D2-945F-00C04FB984F9}


Note You may have to copy additional policies depending on Group Policy requirements for the environment.

  1. Manually copy all necessary scripts to the following folder:

\SYSVOL\SYSVOL\DNS Domain name\scripts

Monday, September 26, 2011

vSphere 5.0 New Features

Here are some of the New Features for Vsphere 5.0

  1. Storage DRS
  2. Storage I/O Control for NFS
  3. VMFS-5
  4. ESXi Firewall
  5. VMFS Scalability and Performance enhancements
  6. 2TB+ pass-through RDM support
  7. vCenter inventory extensibility
  8. Storage APIs -- VAAI T10 Compliancy
  9. Storage APIs -- VAAI Offloads for NAS
  10. Storage APIs -- VAAI Thin Provisioning
  11. Storage APIs -- Storage Awareness/Discovery
  12. Storage APIs -- Data Protection compatible with MN
  13. APD, Permanent APD Survivability Enablement
  14. Snapshot enhancements
  15. Storage vMotion scalability improvements
  16. iSCSI Enablement: iSCSI UI Support
  17. iSCSI Enablement: Stateless Support
  18. Multi-queue Storage IO adapters
  19. Increase NFSv3 Max Share Count to 256
  20. SATA 3.0
  21. Software FCoE initiator support
  22. Enhanced logging support
  23. Enhanced Storage metrics
  24. Profile-Driven Storage
  25. Storage vMotion support for snapshots
  26. vSphere Storage Appliance (VSA)
  27. SSD Detection and Enablement
  28. vSphere Replication
  29. vSphere Data Recovery 2.0
  30. VADP enhancements
  31. vCenter Orchestrator (vCO) Enhancements
  32. vCO -- Library extension and consolidation
  33. vCO -- Scalability
  34. Network I/O Control (NIOC) Phase 2
  35. NIOC -- User Defined Resource Pools
  36. NIOC -- HBR traffic type
  37. NIOC -- 802.1p tagging
  38. Network Traffic Stats for iOPS
  39. Improvement to UDP and Multicast traffic types
  40. New networking drivers for server enablement
  41. vDS support for Port mirror, LLDP and NetFlow V5
  42. vDS Manage Port Group UI enhancement
  43. Hot-Insert/Remove of Filters
  44. Enhanced vMotion Compatibility
  45. Storage vMotion support for Linked Clones
  46. vMotion scalability (dual-NIC & longer latency support)
  47. vNetwork API enhancements
  48. vNetwork Opaque Channel
  49. Support for 8 10GbE Physical NIC ports per host
  50. Add Host Resources MIB to SNMP offering
  51. Metro vMotion
  52. Host Profile for DRS to support Stateless ESX
  53. HA interop with agent VMs
  54. DRS/DPM interop with agent VMs
  55. DRS enhancements for Maintenance Mode
  56. Enhanced processor support for FT
  57. vSphere 5.0 HA aka "FDM / Fault Domain Manager"
  58. vSphere HA - Heartbeat Datastores
  59. vSphere HA - Support for partitions of management network
  60. vSphere HA - Default isolation response changed
  61. vSphere HA - New Status information in UI
  62. vSphere HA - IPv6 support
  63. vSphere HA - Application Awareness API publicly available
  64. Extensions to create special icons for VMs
  65. ESX Agent Management
  66. Solution Management Plugin
  67. Next-Gen vSphere Client
  68. Host Profiles Enhancements
  69. vCenter enhancements for stateless ESXi
  70. vCenter Server Appliance
  71. vCenter: Support for FileManager and VirtualDiskManager APIs
  72. Virtual Hardware - Smartcard support for vSphere
  73. Virtual Hardware Version 8
  74. Virtual HW v8 -- 1TB VM RAM
  75. Virtual HW v8 -- 32-way Virtual SMP
  76. Virtual Hw v8 -- Client-Connected USB Devices
  77. Virtual HW v8 -- EFI Virtual BIOS
  78. Virtual HW v8 -- HD Audio
  79. Virtual Hw v8 -- Multi-core Virtual CPU Support UI
  80. Virtual HW v8 -- New virtual E1000 NIC
  81. Virtual HW v8 -- UI and other support
  82. Virtual HW v8 -- USB 3.0 device support
  83. Virtual HW v8 -- VMCI device enhancements
  84. Virtual HW v8 -- xHCI
  85. Support SMP for Mac OS X guest OS
  86. Universal Passthrough (VMdirect path with vMotion support)
  87. Guest Management Operations (VIX API)
  88. Guest OS Support -- Mac OS X Server
  89. VM Serial Port to Host Serial Port Redirection (Serial Port Pass-Through)
  90. Passthrough/SR-IOV
  91. VMware Tools Portability
  92. VMRC Concurrent Connections enhancements
  93. Scalability: 512 VMs per host
  94. ESXCLI enhancements
  95. Support SAN and hw-iSCSI boot
  96. Hardware -- Interlagos Processor Enablement
  97. Hardware -- SandyBridge-DT Processor Enablement
  98. Hardware -- SandyBridge-EN Processor Enablement
  99. Hardware -- SandyBridge-EP Processor Enablement
  100. Hardware -- Valencia Processor Enablement
  101. Hardware -- Westmere-EX Processor Enablement
  102. Platform -- CIM Enhancements
  103. Platform -- ESX i18n support
  104. Host Power Management Enhancements
  105. Improved CPU scheduler
  106. Improved scalability of CPU (NUMA) scheduler
  107. Memory scheduler improvements to support 32-way VCPU's
  108. Swap to host cache
  109. API enhancements to configure VM boot order
  110. VMX swap
  111. Support for ESXi On Apple XServe
  112. Redirect DCUI to host serial port for remote monitoring and management
  113. UEFI BIOS Boot for ESXi hosts
  114. Scalability -- 160 CPU Threads (logical PCPUs) per host
  115. Scalability -- 2 TB RAM per host
  116. Scalability -- 2048 VCPUs per host
  117. Scalability -- 2048 virtual disks per host
  118. Scalability -- 2048 VMs per VMFS volume
  119. Scalability -- 512 VMs per host
  120. Stateless -- Host Profile Engine and Host Profile Completeness
  121. Stateless -- Image Builder
  122. Stateless -- Auto Deploy
  123. Stateless -- Networking Host Profile Plugin
  124. Stateless -- VIB Packaging Enhancement
  125. Stateless -- VMkernel network core dump
  126. Host profiles enhancements for storage configuration
  127. Enhanced driver support for ESXi
  128. Intel TXT Support
  129. Memsched policy enhancements w.r.t. Java balloon
  130. Native Driver Autoload support
  131. Root password entry screen in interactive installer
  132. vCenter Dump Collector
  133. vCenter Syslog Collector
  134. VMware Update Manager (VUM) enhancements
  135. VUM -- Virtual Appliance enhancements
  136. VUM -- vApp Support
  137. VUM -- Depot management enhancements
  138. vCLI enhancements
  139. PowerCLI enhancements
  140. VProbes -- ESX Platform Observability

Sunday, September 18, 2011

Host Based Firewall - TCP Wrapper

TCP Wrapper is a host-based Networking ACL system, used to filter network access to Internet Protocol servers on (Unix-like) Operating System such as Linux or BSD. It allows host or subnetwork IPAddress, names and/or ident query replies, to be used as tokens on which to filter access control for purposes.

The original code was written by Wietse Venema in 1990 to monitor a cracker's activities on the Unix workstations at the Dept. of Math and Computer Science at the Eindhoven University of Technology. He maintained it until 1995, and on June 1, 2001, released it under its own BSD-style license.

Using TCP_WRAPPERS makes securing your servers against outside intrusion is a lot simpler and painless. TCP_WRAPPERS is controlled from two files:

/etc/hosts.allow
/etc/hosts.deny

hosts.allow is checked first, and the rules are checked from first to last. If it finds a rule that explicitly allows you in (i.e., a rule allowing your host, domain, subnet mask, etc.) it lets you connect to the service. If it fails to find any rules that pertain to you in hosts.allow, it then goes to check hosts.deny for a rule denying you entry.

Again it checks the rules in hosts.deny from first to last, and the first rule it finds that denies you access (i.e., a rule disallowing your host, domain, subnet mask, etc.) means it doesn't let you in. If it fails to find a rule denying you entry it then by default lets you. If you are really paranoid for security (or only rule if you are going to a default policy of non-optimistic security) should be in hosts.deny:

ALL: 0.0.0.0/0.0.0.0

which means all services, all locations, so any service not explicitly allowed is then blocked (remember the default is to allow). You might also want to just default deny access to say telnet and leave ftp wide open to the world. To do this you would have in hosts.allow:

in.telnetd: 10.0.0.0/255.255.255.0 # allow access from my internal network of 10.0.0.*
in.ftpd: 0.0.0.0/0.0.0.0 # allow access from anywhere in the world

in hosts.deny:

in.telnetd: 0.0.0.0/0.0.0.0 # deny access to telnetd from anywhere

or if you wish to be really safe:

ALL: 0.0.0.0/0.0.0.0 # deny access to everything from everywhere

This may affect services such as ssh and nfs, so be careful!

Monday, September 12, 2011

DDOS PREVENTION MECHANISMS

Attack prevention methods try to stop all well known signature based and broadcast based DDoS attacks from being launched in the first place or edge routers, keeps all the machines over Internet up to date with patches and fix security holes. Attack prevention schemes are not enough to stop DDoS attacks because there are always vulnerable to novel and mixed attack types for which signatures and patches arenot exist in the database.

Techniques for preventing against DDoS can be broadly divided into two categories: (i) General techniques, which are some common preventive measures i.e. system protection, replication of resources etc. that individual servers and ISPs should follow so they do not become part of DDoS attack process. (ii) Filtering techniques, which include ingress filtering, egress filtering, router based packet filtering, history based IP filtering, SAVE protocol etc.

A. General Techniques
1) Disabling unused services
The less there are applications and open ports in hosts, the less there are chance to exploit vulnerabilities by attackers. Therefore, if network services are not needed or unused, the services should be disabled to prevent attacks, e.g. UDP echo, character generation services .

2) Install latest security patches
Today, many DDoS attacks exploit vulnerabilities in target system. So removing known security holes by installing all relevant latest security patches prevents re-exploitation of vulnerabilities in the target system.

3) Disabling IP broadcast
Defense against attacks that use intermediate broadcasting nodes e.g. ICMP flood attacks, Smurf attacks etc. will be successful only if host computers and all the neighboring networks disable IP broadcast.

4) Firewalls
Firewalls can effectively prevent users from launching simple flooding type attacks from machines behind the firewall. Firewalls have simple rules such as to allow or deny protocols, ports or IP addresses. But some complex attack e.g. if there is an attack on port 80 (web service), firewalls cannot prevent that attack because they cannot distinguish good traffic from DoS attack traffic.

5) Global defense infrastructure
A global deployable defense infrastructure can prevent from many DDoS attacks by installing filtering rules in the most important routers of the Internet. As Internet is administered by various autonomous systems according their own local security policies, such type of global defense architecture is possible only in theory.

6) IP hopping
DDoS attacks can be prevented by changing location or IP address of the active server proactively within a pool of homogeneous servers or with a pre-specified set of IP address ranges. The victim computer’s IP address is invalidated by changing it with a new one. Once the IP addresses change is completed all internet routers will be informed and edge routers will drop the attacking packets. Although this action leaves the computer vulnerable because the attacker can launch the attack at the new IP address, this option is practical for DDoS attacks that are based on IP addresses. On the other hand, attackers can make this technique useless by adding a domain name service tracing function to the DDoS attack tools.

B. Filtering Techniques
1) Ingress/Egress filtering
Ingress Filtering, proposed by Ferguson et al., is a restrictive mechanism to drop traffic with IP addresses that do not match a domain prefix connected to the ingress router. Egress filtering is an outbound filter, which ensures that only assigned or allocated IP address space leaves the network. A key requirement for ingress or egress filtering is knowledge of the expected IP addresses at a particular port. For some networks with complicated topologies, it is not easy to obtain this knowledge.

One technique known as reverse path filtering can help to build this knowledge. This technique works as follows. Generally, a router always knows which networks are reachable via any of its interfaces. By looking up source addresses of the incoming traffic, it is possible to check whether the return path to that address would flow out the same interface as the packet arrived upon. If they do, these packets are allowed. Otherwise, they are dropped.

Unfortunately, this technique cannot operate effectively in real networks where asymmetric Internet routes are not uncommon. More importantly, both ingress and egress filtering can be applied not only to IP addresses, but also protocol type, port number, or any other criteria of importance. Both ingress and egress filtering provide some opportunities to throttle the attack power of DoS attacks. However, it is difficult to deploy ingress/egress filtering universally. If the attacker carefully chooses a network without ingress/egress filtering to launch a spoofed DoS attack, the attack can go undetected.

Moreover, if an attack spoofs IP addresses from within the subnet, the attack can go undetected as well. Nowadays DDoS attacks do not need to use source address spoofing to be effective. By exploiting a large number of compromised hosts, attackers do not need to use spoofing to take advantage of protocol vulnerabilities or to hide their locations. For example, each legitimate HTTP Web page request from 10,000 compromised hosts can bypass any ingress/egress filtering, but in combination they can constitute a powerful attack. Hence, ingress and egress filtering are ineffective to stop DDoS attacks.

2) Router based packet filtering
Route based filtering, proposed by Park and Lee, extends ingress filtering and uses the route information to filter out spoofed IP packets. It is based on the principle that for each link in the core of the Internet, there is only a limitedset of source addresses from which traffic on the link could have originated.

If an unexpected source address appears in an IP packet on a link, then it is assumed that the source address has been spoofed, and hence the packet can be filtered. RPF uses information about the BGP routing topology to filter traffic with spoofed source addresses. Simulation results show that a significant fraction of spoofed IP addresses can be filtered if RPF is implemented in at least 18% of ASs in the Internet. However, there are several limitations of this scheme. The first limitation relates to the implementation of RPF in practice. Given that the Internet contains more than 10,000 ASs, RPF
would need to be implemented in at least 1800 ASs in order to be effective, which is an onerous task to accomplish. The second limitation is that RPF may drop legitimate packets if there has recently been a route change. The third potential limitation is that RPF relies on valid BGP messages to configure the filter. If an attacker can hijack a BGP session and disseminate bogus BGP messages, then it is possible to mislead border routers to update filtering rules in favor of the attacker. RPF is effective against randomly spoofed DoS attacks. However, the filtering granularity of RPF is low. This means that the attack traffic can still bypass the RPF filters by carefully choosing the range of IP addresses to spoof. Hence, RPF is ineffective against DDoS attacks. The router-based packet filter is vulnerable to asymmetrical and dynamic Internet routing as it does not provide a scheme to update the routing information.

3) History based IP filtering
Generally, the set of source IP addresses that is seen during normal operation tends to remain stable. In contrast, during DoS attacks, most of the source IP addresses have not been seen before. Peng et al. relies on the above idea and use IP address database (IAD) to keep frequent source IP addresses. During an attack, if the source address of a packet is not in IAD, the packet is dropped. Hash based/Bloom filter techniques are used for fast searching of IP in IAD. This scheme is robust, and does not need the cooperation of the whole Internet community.

However, history based packet filtering scheme is ineffective when the attacks come from real IP addresses. In addition, it requires an offline database to keep track of IP addresses. Therefore, Cost of storage and information sharing is very high.

4) Capability based method
Capability based mechanisms provides destination a way to control the traffic directed towards itself. In this approach, source first sends request packets to its destination. Router marks (pre-capabilities) are added to request packet while passing through the router. The destination may or may not grant permission to the source to send. If permission is granted then destination returns the capabilities, if not then it does not supply the capabilities in the returned packet. The data packets carrying the capabilities are then send to thedestination via router. The main advantage achieved in this architecture is that the destination can now control the traffic according to its own policy, thereby reducing the chances of DDoS attack, as packets without capabilities are treated as legacy and might get dropped at the router when congestion happens.

However, these systems offer strong protection for established network flows, but responsible to generate a new attack type known as DOC (Denial of Capability), which prevents new capability-setup packets from reaching the destination, limits the value of these systems. In addition, these systems have high computational complexity and space requirement.

5) Secure overlay Service (SOS)
Secure Overlay Service proposed by Keromytis et al. defines an architecture called secure overlay service (SOS) to secure the communication between the confirmed users and the victim. All the traffic from a source point is verified by a secure overlay access point (SOAP). Authenticated traffic will be routed to a special overlay node called a beacon in an anonymous manner by consistent hash mapping. The beacon then forwards traffic to another special overlay node called a Filtering Technique

Benefsecret servlet for further authentication, and the secret servlet forwards verified traffic to the victim. The identity of the secret servlet is revealed to the beacon via a secure protocol, and remains a secret to the attacker. Finally, only traffic forwarded by the secret servlet chosen by the victim can pass its perimetric routers.

Secure Overlay Service (SOS) addresses the problem of how to guarantee the communication between legitimate users and a victim during DoS attacks. SOS can greatly reduce the likelihood of a successful attack. The power of SOS is based on the number and distribution level of SOAPs. However, wide deployment of SOAPs is a difficult DoS defense challenge. Moreover, the power of SOS is also based on the anonymous routing protocol within the overlay nodes. Unfortunately, the introduction of a new routing protocol is in itself another security issue. If an attacker is able to breach the security protection of some overlay node, then it can launch the attack from inside the overlay network. Moreover, if attackers can gain massive attack power, for example, via worm spread, all the SOAPs can be paralyzed, and the target's services will be disrupted.

6) SAVE: Source Address Validity Enforcement
Li et al. have proposed a new protocol called the Source Address Validity Enforcement (SAVE) protocol, which enables routers to update the information of expected source IP addresses on each link and block any IP packet with an unexpected source IP address. The aim of the SAVE protocol is to provide routers with information about the range of source IP addresses that should be expected at each interface. Similarly to the existing routing protocols, SAVE constantly propagates messages containing valid source address information from the source location to all destinations. Hence, each router along the way is able to build an incoming table that associates each link of the router with a set of valid source address blocks. SAVE is a protocol that enables the router to filter packets with spoofed source addresses using incoming tables. It overcomes the asymmetries of Internet routing by updating the incoming tables on each router periodically.

However, SAVE needs to change the routing protocol, which will take a long time to accomplish. If SAVE is not universally deployed, attackers can always spoof the IP addresses within networks that do not implement SAVE. Moreover, even if SAVE were universally deployed, attackers could still launch
DDoS attacks using non spoofed source addresses.


To conclude, attack prevention aims to solve IP spoofing, a fundamental weakness of the Internet. However, as attackers gain control of larger numbers of compromised computers, attackers can direct these “zombies” to attack using valid source addresses. Since the communication between attackers and “zombies” is encrypted, only “zombies” can be exposed instead of attackers. According to the Internet Architecture Working Group, the percentage of spoofed attacks is declining. Only four out of 1127 customer-impacting DDoS attacks on a large network used spoofed sources in 2004. Moreover, security awareness is still not enough, so expecting installation of security technologies and patches in large base of Internet seems to be an ambitious goal in near future. To add on, there exists no way out to enforce global deployment of a particular security mechanism. Therefore, relying on attack prevention schemes is not enough to stop DDoS attacks.