Nuffnang

Monday, September 26, 2011

vSphere 5.0 New Features

Here are some of the New Features for Vsphere 5.0

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

Sunday, September 18, 2011

Host Based Firewall - TCP Wrapper

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

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

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

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

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

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

ALL: 0.0.0.0/0.0.0.0

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

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

in hosts.deny:

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

or if you wish to be really safe:

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

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

Monday, September 12, 2011

DDOS PREVENTION MECHANISMS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Sunday, September 4, 2011

Boot SSG Firewall with Junos.

Juniper had released Junos as new Operating System for Routing, Switching and Security Juniper devices.

Here is a how to, that explains how you can make a usb stick ready to run JUNOS and use this one on a device that is running ScreenOS.

First need 1 device that runs JUNOS (SRX), on this device we will plug in the USB stick and create a copy of the OS.

root@SRX>request system snapshot as-primary partition media usb
Clearing current label...
Partitioning usb media (da0) ...
Partitions on snapshot:

Partition Mountpoint Size Snapshot argument
a / 1024MB root-size
e /config 196MB config-size
g /data 701MB data-size
Running newfs (1024MB) on usb media / partition (da0s1a)...
Running newfs (196MB) on usb media /config partition (da0s1e)...
Running newfs (701MB) on usb media /data partition (da0s1g)...
Copying '/dev/ad0s1a' to '/dev/da0s1a' .. (this may take a few minutes)
Copying '/dev/ad0s1e' to '/dev/da0s1e' .. (this may take a few minutes)
The following filesystems were archived: / /config

After this we can use this USB stick to use in a ScreenOS device (or in a JUNOS device)

IF you want to use this USB stick on a JUNOS device do the following:

root@SRX> request system reboot media usb

This will make the router reboot and boot from USB stick (you can use this to test upgrades for example)

IF you want to use this USB stick on a ScreenOS device do the following:

SSG550M-> System change state to Active(1)

SSG550M->
SSG550M-> set boot junos usb
Boot device has been set to USB
SSG550M->reset
Configuration modified, save? [y]/n : n
System reset, are you sure? y/[n] : y
In reset ...

After this you will boot in JUNOS (so you are running JUNOS on a ScreenOS device).

When you do a "request system reboot", it will boot back from Compact Flash and will of course run ScreenOS again.