Security Attacks

This page lists types of security attacks. This document will address security issues, measures, and policies which take these types of attacks into consideration.

• DoS- Denial of Service
• Trojan Horse - Comes with other software.
• Virus - Reproduces itself by attaching to other executable files.
• Worm - Self-reproducing program. Creates copies of itself. Worms that spread using e-mail address books are often called viruses.
• Logic Bomb - Dormant until an event triggers it (Date, user action, random trigger, etc.).

Hacker Attacks

I use the term "hacker attacks" to indicate hacker attacks that are not automated by programs such as viruses, worms, or trojan horse programs. There are various forms that exploit weakneses in security. Many of these may cause loss of service or system crashes.

• IP spoofing - An attacker may fake their IP address so the receiver thinks it is sent from a location that it is not actually from. There are various forms and results to this attack.
  • The attack may be directed to a specific computer addressed as though it is from that same computer. This may make the computer think that it is talking to itself. This may cause some operating systems such as Windows to crash or lock up.
• Gaining access through source routing. Hackers may be able to break through other friendly but less secure networks and get access to your network using this method.
• Man in the middle attack -
  • Session hijacking - An attacker may watch a session open on a network. Once authentication is complete, they may attack the client computer to disable it, and use IP spoofing to claim to be the client who was just authenticated and steal the session. This attack can be prevented if the two legitimate systems share a secret which is checked periodically during the session.
• Server spoofing - A C2MYAZZ utility can be run on Windows 95 stations to request LANMAN (in the clear) authentication from the client. The attacker will run this utility while acting like the server while the user attempts to login. If the client is tricked into sending LANMAN authentication, the attacker can read their username and password from the network packets sent.
• DNS poisoning - This is an attack where DNS information is falsified. This attack can succeed under the right conditions, but may not be real practical as an attack form. The attacker will send incorrect DNS information which can cause traffic to be diverted. The DNS information can be falsified since name servers do not verify the source of a DNS reply. When a DNS request is sent, an attacker can send a false DNS reply with additional bogus information which the requesting DNS server may cache. This attack can be used to divert users from a correct webserver such as a bank and capture information from customers when they attempt to logon.
• Password cracking - Used to get the password of a user or administrator on a network and gain unauthorized access.

Some DoS Attacks

• Ping broadcast - A ping request packet is sent to a broadcast network address where there are many hosts. The source address is shown in the packet to be the IP address of the computer to be attacked. If the router to the network passes the ping broadcast, all computers on the network will respond with a ping reply to the sttacked system. The attacked system will be flooded with ping responses which will cause it to be unable to operate on the network for some time, and may even cause it to lock up. The attacked computer may be on someone else's network. One countermeasure to this attack is to block incoming traffic that is sent to a broadcast address.
• Ping of death - An oversized ICMP datagram can crash IP devices that were made before 1996.
• Smurf - An attack where a ping request is sent to a broadcast network address with the sending address spoofed so many ping replies will come back to the victim and overload the ability of the victim to process the replies.
• Teardrop - a normal packet is sent. A second packet is sent which has a fragmentation offset claiming to be inside the first fragment. This second fragment is too small to even extend outside the first fragment. This may cause an unexpected error condition to occur on the victim host which can cause a buffer overflow and possible system crash on many operating systems. 

Soource:-http://www.comptechdoc.org

TACACS+ and RADIUS Comparison

TACACS+ and RADIUS Comparison

                                            Introduction

Two prominent security protocols used to control dial-up access into networks are Cisco's TACACS+ and Livingston Enterprise's RADIUS. Cisco is committed to supporting both protocols with the best of class offerings. It is not Cisco's intention to compete with RADIUS or influence our users to use TACACS+. We want you to choose the solution that will best meet your needs. This document is intended to educate users on the differences between TACACS+ and RADIUS, so that they can make an educated choice.

Cisco has supported the RADIUS protocol since the release of Cisco IOS® Software Release 11.1 in February, 1996. We continue to enhance our RADIUS Client with new features and capabilities, supporting RADIUS as a standard. Cisco Access Servers are the only ones that implement both RADIUS and TACACS+.

Cisco seriously evaluated RADIUS as a security protocol before developing TACACS+. Many features were included in the TACACS+ protocol to meet the needs of the growing dial-up access control and security market. The protocol was designed to scale as networks grow, and to adapt to new security technology as the market matures. The underlying architecture of TACACS+ protocol complements the independent AAA architecture.

RADIUS Background

RADIUS is an access server authentication, authorization, and accounting protocol developed by Livingston Enterprises, Inc. It is a system of distributed security that secures remote access to networks and network services against unauthorized access. RADIUS is comprised of three components:
a protocol with a frame format that utilizes UDP/IP
a server
a client

The server runs on a central computer typically at the customer's site, while the clients reside in the dial-up access servers and can be distributed throughout the network. Cisco has incorporated the RADIUS client into Cisco IOS 11.1.

Client/Server Model

A Network Access Server (NAS) operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response that is returned. RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user. The RADIUS servers can act as proxy clients to other kinds of authentication servers.

Network Security

Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server, to eliminate the possibility that someone snooping on an unsecured network could determine a user's password.

Flexible Authentication Mechanisms

The RADIUS server supports a variety of methods to authenticate a user. When it is provided with the user name and original password given by the user, it can support PPP PAP or CHAP, UNIX login, and other authentication mechanisms.

Server Code Availability

There are a number of distributions of server code commercially and freely available. Cisco's servers include CiscoSecure ACS for Windows, CiscoSecure UNIX and Cisco Access Registrar.

Comparing TACACS+ and RADIUS

The following sections compare several features of TACACS+ and RADIUS.

UDP and TCP

RADIUS uses UDP while TACACS+ uses TCP. TCP offers several advantages over UDP. TCP offers a connection-oriented transport, while UDP offers best effort delivery. RADIUS requires additional programmable variables such as re-transmit attempts and time-outs to compensate for best effort transport, but it lacks the level of built-in support that a TCP transport offers:
Using TCP provides a separate acknowledgment that a request has been received, within (approximately) a network RTT, regardless of how loaded and slow the backend authentication mechanism might be. (TCP ACK).
TCP provides immediate indication of a crashed (or not running) server (RST packets). You can determine when a server has crashed and come back up if you use long-lived TCP connections. UDP can't tell the difference between a down server, a slow server, and a non-existent server.
Using TCP keepalives, server crashes can be detected out-of-band with actual requests. Connections to multiple servers can be maintained simultaneously, and you only need to send messages to the ones that are known to be up and running.
TCP is more scalable and adapts to growing, as well as congested, networks.

Packet Encryption

RADIUS encrypts only the password in the access-request packet, from the client to the server. The remainder of the packet is in the clear. Other information, such as username, authorized services, and accounting, could be captured by a third party.

TACACS+ encrypts the entire body of the packet but leaves a standard TACACS+ header. Within the header is a field that indicates whether the body is encrypted or not. For debugging purposes it is useful to have the body of the packets in the clear. However, normal operation will fully encrypt the body of the packet for more secure communications.

Authentication and Authorization

RADIUS combines authentication and authorization. The access-accept packets sent by the RADIUS server to the client contain authorization information. This makes it difficult to de-couple authentication and authorization.

TACACS+ uses the AAA architecture, which separates authentication, authorization, and accounting. This allows separate authentication solutions that can still use TACACS+ for authorization and accounting. For example, with TACACS+, it is possible to use Kerberos authentication and TACACS+ authorization and accounting. After a NAS authenticates on a Kerberos server, it requests authorization information from a TACACS+ server without having to re-authenticate. The NAS informs the TACACS+ server that it has successfully authenticated on a Kerberos server, and the server then provides authorization information.

During a session, if additional authorization checking is needed, the access server checks with a TACACS+ server to determine if the user is granted permission to use a particular command. This provides greater control over the commands that can be executed on the access server while decoupling from the authentication mechanism.

Multiprotocol Support

RADIUS does not support the following protocols:
AppleTalk Remote Access (ARA) protocol
Net BIOS Frame Protocol Control protocol
Novell Asynchronous Services Interface (NASI)
X.25 PAD connection

TACACS+ offers multiprotocol support.

Router Management

RADIUS does not allow users to control which commands can be executed on a router and which cannot; therefore, it is not as useful for router management or as flexible for terminal services.

TACACS+ provides two ways to control the authorization of router commands on a per-user or per-group basis. The first way is to assign privilege levels to commands and have the router verify with the TACACS+ server whether or not the user is authorized at the specified privilege level. The second way is to explicitly specify in the TACACS+ server, on a per-user or per-group basis, the commands that are allowed.

Interoperability

RADIUS Standard does not guarantee interoperability. Even though several vendors implement RADIUS clients, this does not mean they are interoperable. There are approximately 45 standard RADIUS ATTRIBUTES. Cisco implements most of them today and is consistently adding more. If customers use only the standard ATTRIBUTES in their servers, they can probably interoperate between several vendors, providing that these vendors implement the same ATTRIBUTES. However, many vendors implement extensions that are proprietary ATTRIBUTES. If a customer uses one of these vendor-specific extended ATTRIBUTES, interoperability is not possible.

Traffic

Due to the previously differences between TACACS+ and RADIUS, the amount of traffic generated between the client and server will differ. The following examples illustrate the traffic between the client and server for TACACS+ and RADIUS when used for router management with authentication, exec authorization, command authorization (which RADIUS cannot do), exec accounting, and command accounting (which RADIUS cannot do).

TACACS+ Traffic Example

The following example assumes login authentication, exec authorization, command authorization, start-stop exec accounting, and command accounting is on with TACACS+ when a user telnets to a router, performs a command, and exits the router:








RADIUS Traffic Example

The following example assumes login authentication, exec authorization, and start-stop exec accounting is on with RADIUS when a user telnets to a router, performs a command, and exits the router (other management services are not available):

RODCs: Understanding and Implementing the New Windows Server 2008 R2 Domain Controllers

1. 
   

 RODC in server 2008R2

Read-only domain controllers (RODCs), a new feature of Active Directory Domain Services, represent a fundamental change in how you'll use DCs. Here's what you need to know to implement them in your enterprise.
When physical security is lacking, it becomes essential to increase the focus on data security. Windows Server 2008 and R2 provide some new ways to do so that seem uniquely tailored for environments like remote offices where physical security may not be as tight. Read-only domain controllers (RODCs) are a new feature of the Active Directory Domain Services (AD DS) in the Windows Server systems. They represent a fundamental change to how you'd typically use domain controllers (DCs).
Because many of RODCs' new capabilities impact key aspects of the design and deployment process, it's important to understand how you can leverage them in your enterprise. There are also critical design and planning considerations you must take into account before introducing them into your environment. RODCs are DCs that host complete, read-only copies of Active Directory database partitions, a read-only copy of SYSVOL, and a Filtered Attribute Set (FAS) that restricts the inbound replication of certain application data from writable DCs.

Generally speaking, RODCs are meant for environments that require local authentication and authorization, but lack the physical security to safely use writable DCs.
Branching Out
The most common environments for RODCs using AD DS are still branch offices. These types of environments are typically end points in a hub-and-spoke network topology. They're widely distributed geographically, in large numbers, and they individually host small user populations, connect to hub sites by slow, unreliable network links. Additionally, they often lack local, experienced administrators.
For branch offices already hosting writable DCs, it's probably unnecessary to deploy RODCs. In this scenario, however, RODCs may not only meet existing AD DS-related requirements, but also exceed them with regard to tighter security, enhanced management, simplified architecture and lower total cost of ownership (TCO). For locations where security or manageability requirements prohibit using DCs, RODCs can help you introduce DCs into the environment and provide a number of beneficial, localized services.
Although the new features and benefits make evaluating RODCs compelling, there are additional factors to consider, like application compatibility issues and service impact conditions. These could render RODC deployments unacceptable for certain environments.
For example, because many directory-enabled applications and services read data from AD DS, they should continue to function and work with an RODC. However, if certain applications require writable access at all times, an RODC may not be acceptable. RODCs also depend on network connectivity to a writable DC for write operations. Although failed write operations may be the cause of most well-known application-related issues, there are other issues to consider, such as inefficient or failed read operations, failed write-read-back operations, and general application failures associated with the RODC itself.
Besides application issues, fundamental user and computer operations can be affected when connectivity to a writable DC is disrupted or lost. For example, basic authentication services may fail if account passwords are not both cacheable and cached locally on the RODC. You can easily mitigate this issue by making accounts cacheable through an RODC's Password Replication Policy (PRP), and then caching the passwords through pre-population. Performing these steps also requires connectivity to a writable DC.
Along with other authentication issues, password expirations and account lockouts are significantly impacted when connectivity to a writable DC is unavailable. Password change requests and any attempts to manually unlock a locked account will continue to fail until connectivity to a writable DC is restored. Understanding these dependencies and subsequent changes in operational behavior is critical to ensuring your requirements and any service level agreements (SLAs).
There are several general scenarios in which you can deploy RODCs. They're useful in locations that don't have existing DCs, or in locations that currently host DCs that will either be replaced or upgraded to a newer version of Windows. Although there are comprehensive planning considerations specific to each scenario, we'll focus here on non-specific approaches. They are, however, distinct to RODCs, rather than to traditional writable DCs.
Preplanning
Before you start any formal RODC planning, you should conduct an appropriate level of due diligence and fundamental AD DS preplanning. This should include key tasks like validating the existing AD DS logical structure, and ensuring the administration model and the AD DS physical structure supports existing business and technical requirements. You'll also have to consider hardware requirements, software upgrade strategies, and applicable operating system known issues, and to evaluate RODC AD DS prerequisites. This information will be critical to the planning and deployment processes. You'll find it's well-documented in detailed deployment check lists.
Management Features
There's a substantial manageability feature in RODCs called Administrator Role Separation (ARS). This delegates to non-service administrators the ability to install and administer RODC servers, without granting Active Directory rights. This is a significant change to the traditional considerations with respect to DC server design, delegation of administration, and deployment procedures. This role separation becomes increasingly important with critical applications requiring direct installation on a DC, or for locations that host single, multi-purpose servers.
Additional Server Roles
As a general rule, you should eliminate from the server all roles not required for the RODC to function. Therefore, the only roles you should add to RODCs are the DNS and global catalog server roles. You should install the DNS server role on each RODC so local DNS clients can perform DNS resolution when network connectivity to a writable DC is unavailable. However, if the DNS server role is not installed through Dcpromo.exe, you'll have to install it afterward. You have to use Dnscmd.exe to enlist the RODC in the DNS application directory partitions that host the Active Directory integrated zones. You should also configure RODCs as global catalog servers so they can perform authentication and global catalog queries using just the RODC. From an authentication standpoint, if the global catalog role is not an option, you can use universal group caching. Successful authentication to an RODC may ultimately be dependent on the RODC's PRP configuration.

1.