Review: MacBook Air killer from ASUS

Review: MacBook Air killer from ASUS

ZenBook UX305 is a Windows Ultrabook that copies the MacBook Air’s look, but not its price.

Zenbook
At first glance, you might mistake the ASUS ZenBook UX305 as a dark-gray edition of the 13-inch MacBook Air. It shares nearly the same design cues and size, but is thinner than the Apple notebook is at its thickest point, and weighs less. It also beats many of the current 13-inch MacBook Air’s hardware specs. And it costs less -- a whole lot less – at $699, compared to $999 for the MacBook Air.

Form factor: Kudos and coolness
Because its innards are sealed in an all-aluminum chassis, the UX305 feels persistently cool to the touch. The bezel, bottom and keyboard panel have the same matted surface, and won’t become easily marred with fingerprints; the lid is smooth with a circular polish that is more prone, though, to picking up smudges. The lid closes with a secure tightness making the notebook feel like a single milled object -- a slightly wedged slab.

Keyboard and touchpad: Touches all the bases
The keys have generous spacing among, but the keyboard doesn’t have back-lighting, which the MacBook Air has. The top of the keys are level with the surrounding paneling; when pressed, they don’t feel mushy, and pop back up without looseness. The palm-rest areas are more than large enough for most hand sizes. Because the touchpad is so large (about 4.75 inches) and close to the spacebar, you’d be best to keep your fingers and palms raised in proper ergonomic fashion as you type. The touchpad moves the pointer at an increasingly accelerating rate over the wide expanse of the high-resolution display, with only a short swipe by your finger that feels about right -- neither too slow nor too fast.

Screen: Looking sharp
The surface of the 13.3-inch display is matted. It’s so effective that I didn’t experience glare whether I used the ZenBook indoors or outside in sunlight. The backlight looks even throughout the display -- it remains consistent when viewed from extreme horizontal or vertical angles. The colors appear discernible without any particular one popping out distractingly or bleeding over to another. Text shown on the UX305’s 1920-by-1080-pixel screen, at the default font size settings of Windows 8.1, look sharp. Even the tiny wording of Tiles on the Start Screen are legible if your eyesight is healthy.

Speakers: Sounding weak
Two speakers are set at the bottom of the notebook’s chassis: one each near the edge of the width sides. Because they feature audio technology from Bang & Olufsen, you might expect them to belt out full, warm sound. But, in actuality, the various genres of music I played on the UX305 tended to come off thin in the low end with weak bass. These speakers didn’t necessarily sound bad; they were not unlistenable. They just lacked a powerful audio presence.

Performance: Powerful, quiet
Since this notebook has a resolution that matches high-definition video, I played through a gamut of 1080p videos. With a fast Internet connection, the videos played without lag or stutter. The bottom of the notebook’s aluminum casing barely began to feel warm, as I played videos for over an hour. The Intel Core M-5Y10 processor managed to stay cool, and, because it’s fanless, this notebook doesn’t make any extraneous noise. Even when multitasking, streaming music and video playback hardly faltered, and I purposely kept five other programs open, to try to grind down the processor.

Webcam and mic: In focus
Using the Windows 8.1 Camera app, I found the front-facing camera excellent at focusing on objects held up-close, even within a few inches, and it did so instantly. Taken under typical indoor lighting during the daytime, images and video had a noticeable graininess and leaned a little toward a yellow tint, but they were clear and in focus. Testing the mic, I recorded a few audio clips of my voice, using the Windows 8.1 Sound Recorder app, as I sat a few feet in front of the notebook. The clip of me speaking sounded clear and crisp with no buzzing or other distortion.

Software: Limited third-party apps
The Windows 8.1, 64-bit installation on the UX305 includes a medley of ASUS brand tools. The only third-party apps are Foxit PhantomPDF and McAfee LiveSafe. Over on the Windows Store app side, though, several nonessential ones neither by ASUS nor Microsoft are pre-installed (e.g. iHeartRadio, Netflix, Twitter).

Battery Life: Definitely an issue
The display’s native resolution of 1920-by-1080 pixels eats more power than the 13-inch MacBook Air’s 1440-by-900. ASUS says the UX305 can run up to 10 hours on a fully charged battery. With this notebook on its default settings, I got only around 6 hours and 30 minutes. Charging the battery took about 2 hours and 40 minutes. I then installed all the Windows 8.1 updates, minimized playing streaming media, turned on “power saver,” turned off all the Live Tiles on the Start Screen, turned on auto-dimming, and uninstalled McAfee security. These actions resulted in an additional 30 or so minutes. That’s not terrible, but nor is it as good as one might expect from a notebook like this.

Conclusion: Premium notebook, low price
Although battery life probably had to be sacrificed, the ZenBook UX305 still has a lot going for it: 256GB SSD, beautiful display, good keyboard and touchpad, speedy performance (assisted by 8GB RAM), and a light and thin form that, to be frank, is a knock-off (and a good one at that) of the 13-inch MacBook Air’s. These all add up to a premium notebook that you can buy without paying a premium price.

The specs:
OS: Windows 8.1, 64-bit
Processor: Intel Core M-5Y10, 2 GHz
RAM: 8GB
Onboard storage: 256GB SSD
Display: 13.3”, 1920 x 1080 pixels
Audio: microphone, speakers (two)
Camera: 720p, front
Networking: Bluetooth 4.0, Wi-Fi (802.11n)
Ports: headphone/microphone combo jack, Micro HDMI, SD/SDXC, USB 3.0 (three)
Battery: Up to 10 hours (listed); 6 to about 7 hours (as tested)
Dimensions (width, depth, height): 12.8” x 8.9” x 0.5”
Weight: 2.6 lbs.
Price: $699

---

Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com

VMware just created its first Linux OS, and it’s container-friendly

Photon OS is meant to run containers inside a virtual machine

VMware Monday announced its first operating system, and it’s designed to run containers inside the company’s virtualization management software. In announcing the Linux OS, named Project Photon, VMware is attempting to convince users who are curious about using containers that they can do so while still using the company’s software.

As container technology has gained popularity in recent months there’s been a debate in the cloud computing and virtualization market about whether it is best to run containers on bare metal, meaning without a hypervisor, or in virtual machines. If containers run on bare metal, it could remove the need for VMware’s virtualization software.

In releasing Project Photon, VMware is attempting to make the argument that users gain benefits from running containers inside VMs. Containers that run on top of a VM can be controlled by the same software that VMs are managed through, allowing containers to have the same network and security settings that the VMs do, for example.

VMware has created Photon as an OS that can run in vSphere. VMware says it’s a “lightweight” Linux OS that has only the basic elements required to package applications in containers and run them inside virtual machines. Because of its minimalist feature set, Project Photon is meant to boot up quickly, which is a key advantage of using containers.

Project Photon supports many container image platforms, including those from Docker (which is both an open source container runtime and the name of the company that is commercializing it), as well as container images from CoreOS (called “rkt”) and Pivotal (named “Garden”).

VMware also announced the beta of Project Lightwave, which is an identity and access management tool meant to provide an extra security layer for containers. Lightwave essentially sits between the operating system and VMware’s management technology to authenticate containers, virtual machines and applications. Lightwave is compatible with various identity standards, including Kerberos, LDAP v3, SAML, X.509 and WS-Trust.

Both Lightwave and Photon will be open sourced by VMware. Photon code is available now on GitHub and Lightwave code will be released in coming months. Both are developer previews and have not yet been released commercially. They were developed by a new team at VMware led by Kit Colbert, VP and CTO of the newly formed Cloud Native Apps division.

---

Best VMwareCertification, VMware Training at certkingdom.com

Is an SDN Switch A New Form of a Firewall?

SDN switches can behave like a firewall, but they may not be a replacement for the real thing

Many people anticipated that enterprise organizations would adopt Software Defined Network (SDN) technologies later than service providers or multi-tenant data centers and cloud service providers. We are now seeing more use of Network Functions Virtualization (NFV) within enterprises and some enterprises are starting SDN pilot projects. As enterprises consider how to utilize SDN technologies in their data center environments, they start to consider what new security capabilities SDN can provide. SDN switches can drop packets for flows that are not permitted by the controller. This article explores if SDN switches can behave like a traditional firewall.

Software Defined Networking evolved from the concept of decoupling the lower-layer packet/frame forwarding from the control function that intelligently determines how application traffic should be transported. The separation of the control plane from the forwarding plane allows networks to facilitate packet processing in new and innovative ways and created a new paradigm for network virtualization. SDN has opened up a whole new world of network design and enabled creative approaches to networking. SDN has also caused us to reconsider how security policies are enforced within the network.

In the OpenFlow SDN model, the flows within a network switch are placed there by an OpenFlow controller. If a flow is not present (table-miss), then the switch punts to the controller to ask for help determining how the packet should be forwarded. The OpenFlow technical specifications state that if the table-miss flow entry is not present in the switch and there is no rule to send the packet to the controller, then the packet is dropped by the switch. If the switch punts the packet to the controller, then the controller processes the Packet-in message and determines the fate of that packet. The controller then determines if the packet should be forwarded or dropped. This behavior sounds like the SDN switch is behaving like a firewall and enforcing the “that which is not included in the flow table, is dropped” standard security policy. This can be thought of as similar to the default “Fail-Safe Stance” that was also mentioned in the book Building Internet Firewalls, by Elizabeth D. Zwicky, Simon Cooper and D. Brent Chapman. On first blush, this sounds like a great new form of security and makes it seem like every port of an SDN switch can behave like a firewall.

Many SDN switches behave much like a standard Ethernet switch and flood traffic out all ports for Ethernet frames destined to broadcast, multicast or unknown MAC addresses. Most SDN switches flood normal ARP traffic like a typical hardware-based Ethernet switch. In most situations, the default behavior for an SDN switch is to act like an Ethernet bridge, or learning switch. However, it is possible to put an SDN switch into an explicit forwarding mode whereby only flows allowed or configured/pushed by the controller are allowed.

If every Ethernet switch in the environment could perform like a traditional firewall, it would change the way security policy is implemented in a networked environment. Imagine if every Ethernet switch were a multi-port firewall, then firewall policies could be implemented throughout the network at every ingress switch port and on every link between switches. There would be firewalls for every server, desktop, every link, and the firewall policy would be implemented by a controller that maintained a global view of the current application traffic and what traffic should be permitted. Having security policy enforced throughout the environment would mean the complete erosion of the security perimeter. Having that many security policies implemented and maintained manually would be an administrative nightmare. However, with a controller architecture, the policy would be created once and then pushed down to every network device for enforcement.

Network slicing is one of the popular use cases of SDN. A network can be logically carved up into logically separated networks overlaid upon the same physical network hardware. Network slicing is a popular use case within universities because they would like to separate different departments (admissions, finance, residence halls, computer science departments, etc.) into their own logical network enclaves. The SDN can separate the networks similar to Virtual Routing and Forwarding (VRF) instances may be used to separate layer-3 forwarding. This can also be done by adding a slicing layer between the control plane and the data plane, thus making the security policies slice-specific. Enforcement of strong isolation between slices in “Flowspace” means that actions in one slice do not affect another slice. For more information look at Flowvisor and the FSFW: Flowspace firewall. An example of this would be the Cisco Extensible Network Controller (XNC) with the Networking Slicing application. In these ways, SDNs can provide the “Diversity of Defense” concept which was also mentioned in Building Internet Firewalls.

The key concept to the feasibility of using an SDN-enabled switch as a firewall is the state that it would maintain of the application traffic flows. Access Control Lists (ACLs) are not stateful and do not have awareness of when the connection started or ended. Even with the good-old Cisco ACL CLI parameter “established”, the ACLs became only slightly “statefulish”. ACLs typically do not pay any attention to the three-way TCP handshake (SYN, SYN-ACK, ACK) or the FIN/ACK session teardown. Stateful firewalls, on the other hand, observe the session establishment and close process and apply their policies directionally using Stateful Inspection.

So, how do modern SDN products implement security and could they behave like a traditional firewall? When it comes to Cisco’s Application Centric Infrastructure (ACI), the Nexus 9000 switches operate in a stateless manner. The Application Network Profiles (ANPs) configured in the Application Policy Infrastructure Controller (APIC) are deployed to the switches in the ACI fabric in a stateless fashion. Therefore, an ACI system would not be able to operate with the same level of security as a standard stateful firewall. This is why ACI allows for Layer-4-to-7 Service Graphs to be configured and integrated into the ACI fabric.

When it comes to Open vSwitch (OVS), it has supported only stateless matches on policies. It is possible to configure OVS policies that match TCP flags or configure rules to use a “learn” method to establish the return flow of traffic. However, neither of these methods are stateful like a traditional stateful inspection firewall. There is work being done by the Open vSwitch community to have connection tracking (Conntrack) to allow the OVS to notify a Netfilter (think iptables) connection tracker and maintain a state table of existing sessions.

Project Floodlight can configure ACLs, however, these also operate like a stateless firewall. Floodlight has a Firewall application module that enforces ACL rules by inspecting Packet-In behavior. This works in a reactive way, with the first packet helping to instantiate the flow and traffic is allowed or denied based on the priority-sorted policy rule-set. Rules are allows to have overlapping flowspace but the priority creates the first-match rule action top-down policy.

VMware NSX has the ability to configure security policies within the SDN environment. NSX for vSphere supports logical switching/routing, firewall, load balancing, and VPN functionality. The firewall rules are enforced at the vNIC, but the firewall policy is associated with the VM and when the host moves, so does the policy. The NSX Distributed Firewall is a kernel loadable module and provides stateful L2/L3/L4 dual-protocol firewalling and can do anti-spoofing. The VMware NSX firewall polices operate like a Cisco router with a reflexive ACL. When it comes to Equal Cost Multi-Path (ECMP) designs or High-Availability (HA), the NSX Edge Services Gateway firewall functions in a stateless manner. In other words, stateful firewalling and load balancing or NAT are not supported by the Edge Services Gateway with an HA or ECMP topology.

There are groups who are working to try to create SDN systems that provide robust security policy enforcement. Research projects like FlowGuard and a paper titled “An OpenFlow-Based Prototype of SDN-Oriented Stateful Hardware Firewalls” written by Jacob Collings at the University of North Dakota show that there may be potential to establish statefullness within the SDN network devices.

From this analysis, we can conclude that SDN switches that obtain their forwarding policies from a controller are not necessarily stateful. These SDN-enabled switches are, therefore, unable to provide the same level of protection as a stateful firewall. It is important to ask the vendor about the details of the statefulness of their firewall capabilities in their SDN solutions and understand how they operate. Because many of these SDN systems may operate in a stateless way, if your organization requires stateful firewall protections, then you must use the SDN policies to steer the traffic with service-chaining toward a stateful packet inspection Network Functions Virtualization (NFV) firewall.

---

Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com