Monday, August 31, 2015

Understanding Firewalls

Firewalls enable you to define an access control requirement and ensure that only traffic or data that meets that requirement can traverse the firewall (in the case of a network-based firewall) or access the protected system (in the case of a host-based firewall). Firewalls are used to create security checkpoints at the boundaries of private networks. At these checkpoints, firewalls inspect all packets passing between the private network and the Internet and determine whether to pass or drop the packets depending on how they match the policy rules programmed into the firewall.
Firewalls sit on the borders of your network, connected directly to the circuits that provide access to other networks. For that reason, firewalls are frequently referred to as border security. The concept of border security is important—without it, every host on your network would have to perform the functions of a firewall themselves, needlessly consuming computer resources and increasing the amount of time required to connect, authenticate, and encrypt data in local area, high−speed networks. Firewalls allow you to centralize all external security services in machines that are optimized for and dedicated to the task. Inspecting traffic at the border gateways also has the benefit of preventing hacking traffic from consuming the bandwidth on your internal network.
Fundamentally, firewalls need to be able to perform the following tasks:
  • Manage and control network traffic
  • Authenticate access
  • Act as an intermediary
  • Protect resources
  • Record and report on events
And Firewalls function primarily by using three fundamental methods:
  • Packet Filtering Rejects TCP/IP packets from unauthorized hosts and reject connection attempts to unauthorized services.
  • Network Address Translation (NAT) Translates the IP addresses of internal hosts to hide them from outside monitoring. You may hear of NAT referred to as IP masquerading.
  • Proxy Services Makes high−level application connections on behalf of internal hosts in order to completely break the network layer connection between internal and external hosts.
Packet Filters
Filters compare network protocols (such as IP) and transport protocol packets (such as TCP) to a database of rules and forward only those packets that conform to the criteria specified in the database of rules. Filters can either be implemented in routers or in the TCP/IP stacks of servers. Filters implemented inside routers prevent suspicious traffic from reaching the destination network, whereas TCP/IP filter modules in servers merely prevent that specific machine from responding to suspicious traffic. The traffic still reaches the network and could target any machine on it. Filtered routers protect all the machines on the destination network from suspicious traffic. For that reason, filtering in the TCP/IP stacks of servers (such as that provided by Windows NT) should only be used in addition to router filtering, not instead of it.
Network Address Translation
Network Address Translation (NAT) solves the problem of hiding internal hosts. NAT is actually a network layer proxy: A single host makes requests on behalf of all internal hosts, thus hiding their identity from the public network. NAT hides internal IP addresses by converting all internal host addresses to the address of the firewall. The firewall then retransmits the data payload of the internal host from its own address using the TCP port number to keep track of which connections on the public side map to which hosts on the private side. To the Internet, all the traffic on your network appears to be coming from one extremely busy computer.
Proxies
Application−level proxies allow you to completely disconnect the flow of network−level protocols through your firewall and restrict traffic only to higher−level protocols like HTTP, FTP, and SMTP. Application proxies don't have to run on firewalls; any server, either inside or outside your network, can perform the role of a proxy. Security proxies are even capable of performing application−level filtering for specific content. Proxies are extremely specific because they can only work for a specific application. For instance, you must have a proxy software module for HTTP, another proxy module for FTP, and another module for Telnet.

Wednesday, August 26, 2015

Node.js Architecture

Node is an open source toolkit for developing server side applications based on the V8 JavaScript engine. Like Node, V8 is written in C++ and is mostly known for being used in Google Chrome.
Node is part of the Server Side JavaScript environment and extend JavaScript API to offer usual server side functionalities. Node base API can be extended by using the CommonJS module system.

NodeJS is divided into two main components: the core and its modules. The core is built in C and C++. It combines Google’s V8 JavaScript engine with Node’s Libuv library and protocol bindings including sockets and HTTP.
V8 Runtime Environment
Google’s V8 engine is an open-source Just In Time, or JIT, compiler written in C++. In recent benchmarks, V8’s performance has surpassed other JavaScript interpreters including Spider Monkey and Nitro. It has additionally surpassed PHP, Ruby and Python performance. Due to Google’s approach, it is predicted that in fact it could become as fast as C. The engine compiles JavaScript directly into assembly code ready for execution by avoiding any intermediary representations like tokens and opcodes which are further interpreted. The runtime environment is itself divided into three majors components: a compiler, an optimizer and a garbage collector.
Libuv
The C++ Libuv library is responsible for Node’s asynchronous I/O operations and main event loop. It is composed of a fixed-size thread pool from which a thread is allocated for each I/O operation. By delegating these time-consuming operations to the Libuv module, the V8 engine and remainder of NodeJS is free to continue executing other requests. Before 2012, Node relied on two separate libraries, Libio and Libev, in order to provide asynchronous I/O and support the main event loop. However, Libev was only supported by Unix. In order to add Windows support, the Libio library was fashioned as an abstraction around Libev.