The Linux Command Line - 13.07

    Type: E-Book

Why Use The Command Line?
Have you ever noticed in the movies when the “super hacker,” — you know, the guy who can break into the ultra-secure military computer in under thirty seconds — sits down at the computer, he never touches a mouse? It's because movie makers realize that we, as human beings, instinctively know the only way to really get anything done on a computer is by typing on a keyboard!
Most computer users today are only familiar with the graphical user interface (GUI) and have been taught by vendors and pundits that the command line interface (CLI) is a terrifying thing of the past. This is unfortunate, because a good command line interface is a marvelously expressive way of communicating with a computer in much the same way the written word is for human beings. It's been said that “graphical user interfaces make easy tasks easy, while command line interfaces make difficult tasks possible” and this is still very true today.
Since Linux is modeled after the Unix family of operating systems, it shares the same rich heritage of command line tools as Unix. Unix came into prominence during the early 1980s (although it was first developed a decade earlier), before the widespread adoption of the graphical user interface and, as a result, developed an extensive command line interface instead. In fact, one of the strongest reasons early adopters of Linux chose it over, say, Windows NT was the powerful command line interface which made the “difficult tasks possible.”


What This Book is about
This book is a broad overview of “living” on the Linux command line. Unlike some books that concentrate on just a single program, such as the shell program, bash, this book will try to convey how to get along with the command line interface in a larger sense. How does it all work? What can it do? What's the best way to use it?
This is not a book about Linux system administration. While any serious discussion of the command line will invariably lead to system administration topics, this book only touches on a few administration issues. It will, however, prepare the reader for additional study by providing a solid foundation in the use of the command line, an essential tool for any serious system administration task.
This book is very Linux-centric. Many other books try to broaden their appeal by including other platforms such as generic Unix and OS X. In doing so, they “water down” their content to feature only general topics. This book, on the other hand, only covers contemporary Linux distributions. Ninety-five percent of the content is useful for users of other Unix-like systems, but this book is highly targeted at the modern Linux command line user.

Like it ? Share it.

Denial of Service (DoS)

A Denial of Service (DoS) attack is a malicious attempt to make a server or a network resource unavailable to users, usually by temporarily interrupting or suspending the services of a host connected to the Internet.

DoS and DDoS Attack

It is important to differentiate between Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks.

In a DoS attack, one computer and one internet connection is used to flood a server with packets, with the aim of overloading the targeted server’s bandwidth and resources.
A DDoS attack, uses many devices and multiple Internet connections, often distributed globally into what is referred to as a botnet. A DDoS attack is, therefore, much harder to deflect, simply because there is no single attacker to defend from, as the targeted resource will be flooded with requests from many hundreds and thousands of multiple sources.


Types of DoS Attacks

The most common type of Denial of Service attack involves flooding the target resource with external communication requests. This overload prevents the resource from responding to legitimate traffic, or slows its response so significantly that it is rendered effectively unavailable.
Resources targeted in a DoS attack can be a specific computer, a port or service on the targeted system, an entire network, a component of a given network any system component. DoS attacks may also target human-system communications (e.g. disabling an alarm or printer), or human-response systems (e.g. disabling an important technician's phone or laptop).
DoS attacks can also target tangible system resources, such as computational resources (bandwidth, disk space, processor time); configuration information (routing information, etc.); state information (for example, unsolicited TCP session resetting). Moreover, a DoS attack can be designed to: execute malware that maxes out the processor, preventing usage; trigger errors in machine microcode or sequencing of instructions, forcing the computer into an unstable state; exploit operating system vulnerabilities to sap system resources; crash the operating system altogether.
The overriding similarity in these examples is that, as a result of the successful Denial of Service attack, the system in question does not respond as before, and service is either denied or severly limited.

Types of DDoS Attacks

DDoS attacks can divided in three types:

• Volume Based Attacks - This type of attack includes UDP floods, ICMP floods, and other spoofed packet floods. The goal of this DDoS attack is to saturate the bandwidth of the attacked site. The magnitude of a volume-based attack is usually measured in Bits per second.
• Protocol Attacks - This type of DDoS attack consumes the resources of either the servers themselves, or of intermediate communication equipment, such as routers, load balancers and even some firewalls. Some examples of protocol attacks include SYN floods, fragmented packet attacks, Ping of Death, Smurf DDoS and more. Protocol attacks are usually measured in Packets per second.
• Application Layer Attacks - Perhaps the most dangerous type of DDoS attack, application layer attacks are comprised of seemingly legitimate and innocent requests. The intent of these attacks is to crash the web server. SDome examples of application layer attacks include Slowloris, Zero-day DDoS attacks, DDoS attacks that target Apache, Windows or OpenBSD vulnerabilities and more. The magnitude of this type of attack is measured in Requests per second.

Symptoms and Manifestations

The United States Computer Emergency Readiness Team (US-CERT) defines symptoms of denial-of-service attacks to include:

• Unusually slow network performance (opening files or accessing web sites)
• Unavailability of a particular web site
• Inability to access any web site
• Dramatic increase in the number of spam emails received—(this type of DoS attack is considered an e-mail bomb)[2]
• Disconnection of a wireless or wired internet connection
• The term "hit offline" being used on you, then you (the target) may disconnect from the internet

Denial-of-service attacks can also lead to problems in the network 'branches' around the actual computer being attacked. For example, the bandwidth of a router between the Internet and a LAN may be consumed by an attack, compromising not only the intended computer, but also the entire network.
If the attack is conducted on a sufficiently large scale, entire geographical regions of Internet connectivity can be compromised without the attacker's knowledge or intent by incorrectly configured or flimsy network infrastructure equipment.

Methods of attack

A "Denial-of-Service" attack is characterized by an explicit attempt by attackers to prevent legitimate users of a service from using that service. There are two general forms of DoS attacks: those that crash services and those that flood services.
A DoS attack can be perpetrated in a number of ways. The five basic types of attack are:

• Consumption of computational resources, such as bandwidth, disk space, or processor time.
• Disruption of configuration information, such as routing information.
• Disruption of state information, such as unsolicited resetting of TCP sessions.
• Disruption of physical network components.
• Obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.

A DoS attack may include execution of malware intended to:[citation needed]

• Max out the processor's usage, preventing any work from occurring.
• Trigger errors in the microcode of the machine.
• Trigger errors in the sequencing of instructions, so as to force the computer into an unstable state or lock-up.
• Exploit errors in the operating system, causing resource starvation and/or thrashing, i.e. to use up all available facilities so no real work can be accomplished or it can crash the system itself
• Crash the operating system itself.

Preventing DoS and DDoS Vulnerabilities

Defending against Denial of Service attacks typically involves the use of a combination of attack detection, traffic classification and response tools, aiming to block traffic that they identify as illegitimate and allow traffic that they identify as legitimate. A list of prevention and response tools is provided below:

Firewalls
Firewalls can be setup to have simple rules such to allow or deny protocols, ports or IP addresses. In the case of a simple attack coming from a small number of unusual IP addresses for instance, one could put up a simple rule to drop all incoming traffic from those attackers.
More complex attacks will however be hard to block with simple rules: for example, if there is an ongoing attack on port 80 (web service), it is not possible to drop all incoming traffic on this port because doing so will prevent the server from serving legitimate traffic. Additionally, firewalls may be too deep in the network hierarchy. Routers may be affected before the traffic gets to the firewall. Nonetheless, firewalls can effectively prevent users from launching simple flooding type attacks from machines behind the firewall.

Some stateful firewalls, like OpenBSD's pf packet filter, can act as a proxy for connections: the handshake is validated (with the client) instead of simply forwarding the packet to the destination. It is available for other BSDs as well. In that context, it is called "synproxy".

Switches
Most switches have some rate-limiting and ACL capability. Some switches provide automatic and/or system-wide rate limiting, traffic shaping, delayed binding (TCP splicing), deep packet inspection and Bogon filtering (bogus IP filtering) to detect and remediate denial of service attacks through automatic rate filtering and WAN Link failover and balancing.
These schemes will work as long as the DoS attacks are something that can be prevented by using them. For example SYN flood can be prevented using delayed binding or TCP splicing. Similarly content based DoS may be prevented using deep packet inspection. Attacks originating from dark addresses or going to dark addresses can be prevented using Bogon filtering. Automatic rate filtering can work as long as you have set rate-thresholds correctly and granularly. Wan-link failover will work as long as both links have DoS/DDoS prevention mechanism.

Routers
Similar to switches, routers have some rate-limiting and ACL capability. They, too, are manually set. Most routers can be easily overwhelmed under DoS attack. Cisco IOS has features that prevent flooding, i.e. example settings.

Application Front-end Hardware
Application front end hardware is intelligent hardware placed on the network before traffic reaches the servers. It can be used on networks in conjunction with routers and switches. Application front end hardware analyzes data packets as they enter the system, and then identifies them as priority, regular, or dangerous. There are more than 25 bandwidth management vendors.

IPS Based Prevention
Intrusion-prevention systems (IPS) are effective if the attacks have signatures associated with them. However, the trend among the attacks is to have legitimate content but bad intent. Intrusion-prevention systems which work on content recognition cannot block behavior-based DoS attacks.
An ASIC based IPS may detect and block denial of service attacks because they have the processing power and the granularity to analyze the attacks and act like a circuit breaker in an automated way.
A rate-based IPS (RBIPS) must analyze traffic granularly and continuously monitor the traffic pattern and determine if there is traffic anomaly. It must let the legitimate traffic flow while blocking the DoS attack traffic.

DDS Based Defense
More focused on the problem than IPS, a DoS Defense System (DDS) is able to block connection-based DoS attacks and those with legitimate content but bad intent. A DDS can also address both protocol attacks (such as Teardrop and Ping of death) and rate-based attacks (such as ICMP floods and SYN floods).
Like IPS, a purpose-built system, such as the well-known Top Layer IPS products, can detect and block denial of service attacks at much nearer line speed than a software based system.

Blackholing and Sinkholing
With blackholing, all the traffic to the attacked DNS or IP address is sent to a "black hole" (null interface, non-existent server, ...). To be more efficient and avoid affecting network connectivity, it can be managed by the ISP.
Sinkholing routes to a valid IP address which analyzes traffic and rejects bad ones. Sinkholing is not efficient for most severe attacks.

Clean Pipes
All traffic is passed through a "cleaning center" or a "scrubbing center" via various methods such as proxies, tunnels or even direct circuits, which separates "bad" traffic (DDoS and also other common internet attacks) and only sends good traffic beyond to the server. The provider needs central connectivity to the Internet to manage this kind of service unless they happen to be located within the same facility as the "cleaning center" or "scrubbing center".

Like it ? Share it.

Folder Option is Missing in Windows Vista/ Windows 7

The Folder Options dialog box lets users set many properties of Windows Explorer, such as Active Desktop, Web view, Offline Files, hidden system files, and file type. Folder option" is most usable thing in Windows System. You can do a lot by using Folder option like hide/show files etc.

Error Details : This operation has been cancelled due to restrictions in effect on this computer. Please contact your system Adminstrator.

(Click image for large view)

You must be signed in as and administrator to be able to do the steps in this tutorial.
1. Press Windows + R and type gpedit.msc then click on OK

2. A windows will appear. This is Local Group Policy. Now go to 

User Configuration → Administrative Templates → Windows Components → Windows Explorer. Now carefully watch the list there you will see "Remove the Folder Options menu item from the Tools menu " Right Click on this and click on Edit

3. Now select Disabled and Click OK

(Click image for large view)

4. Restart System.

Note - This tutorial is also useful if you want to Enable/Disable your folder option for some reason. Above method tells you how can you Enable Folder Option. If you want to Disable Folder Option. you just need to choose Enabled option from Image no 3 

In short :

To Enable Folder Options

Select Disabled or Not Configured and click on OK. (Image No 3)

NOTE: Not Configured is the default setting.

To Disable Folder Options

Select Enabled and click on OK. (Image No 3 but you just need to choose Enabled)

Cross-site Request Forgery

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

Key Concepts of Cross-Site Request Forgery

• Malicious requests are sent from a site that a user visits to another site that the attacker believes the victim is validated against.
• The malicious requests are routed to the target site via the victim’s browser, which is authenticated against the target site.
• The vulnerability lies in the affected web application, not the victim’s browser or the site hosting the CSRF.

Executing a CSRF Attack

In a Cross Site Request Forgery attack, the attacker is exploiting how the target web application manages authentication. For CSRF to be exploited the victim must be authenticated against (logged in) to the target site. For instance let’s say examplebank.com has online banking that is vulnerable to CSRF. If I visit a page containing a CSRF attack on examplebank.com but am not currently logged in, nothing happens. I am logged in however, the requests in the attack will be executed as if they were actions that I had intended to do.
Let’s look at how the attack described above would work in a bit more detail. First let’s assume that I’m logged in to my account on examplebank.com which allows for standard online banking features, including transferring funds to another account.
Now let’s say I happen to visit somemalicioussite.com. It just so happens that this site is trying to attack people who bank with examplebank.com and have setup a CSRF attack on their site. The attack will transfer $2500.00 to their account, which is account number 123456789. Somewhere on somemalicioussite.com attackers have added this line of code:
<iframe src="http://examplebank.com/app/transferFunds?amount=2500&destinationAccount=123456789">
Upon loading that iframe, my browser will send that request to examplebank.com which my browser has already logged in as me. The request will be processed and send $2500.00 to account 123456789.

Limitations

Several things have to happen for cross-site request forgery to succeed:

• The attacker must target either a site that doesn't check the referrer header (which is common) or a victim with a browser or plugin bug that allows referer spoofing (which is rare).
• The attacker must find a form submission at the target site, or a URL that has side effects, that does something (e.g., transfers money, or changes the victim's e-mail address or password).
• The attacker must determine the right values for all the form's or URL's inputs; if any of them are required to be secret authentication values or IDs that the attacker can't guess, the attack will fail.
• The attacker must lure the victim to a Web page with malicious code while the victim is logged in to the target site.

Note that the attack is blind; i.e., the attacker can't see what the target website sends back to the victim in response to the forged requests, unless they exploit a cross-site scripting or other bug at the target website. Similarly, the attacker can only target any links or submit any forms that come up after the initial forged request if those subsequent links or forms are similarly predictable. (Multiple targets can be simulated by including multiple images on a page, or by using JavaScript to introduce a delay between clicks.)

Given these constraints, an attacker might have difficulty finding logged-in victims or attackable form submissions. On the other hand, attack attempts are easy to mount and invisible to victims, and application designers are less familiar with and prepared for CSRF attacks than they are for, say, password-guessing dictionary attacks.

Preventing Cross-Site Request Forgery (CSRF) Vulnerabilities

The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append unpredictable challenge tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user.

Individual Web users using unmodified versions of the most popular browsers can do relatively little to prevent cross-site request forgery. Logging out of sites and avoiding their "remember me" features can mitigate CSRF risk; not displaying external images or not clicking links in spam or untrusted e-mails may also help.

Browser extensions such as RequestPolicy (for Mozilla Firefox) can prevent CSRF by providing a default-deny policy for cross-site requests. However, this can significantly interfere with the normal operation of many websites. The CsFire extension (also for Firefox) can mitigate the impact of CSRF with less impact on normal browsing, by removing authentication information from cross-site requests. The NoScript extension mitigates CSRF threats by distinguishing trusted from untrusted sites, and removing payloads from POST requests sent by untrusted sites to trusted ones.

Web sites have various CSRF countermeasures available:

• Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the right token in its submissions[1]
• Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security implications (money transfer, etc.)
• Limiting the lifetime of session cookies
• Ensuring that there is no clientaccesspolicy.xml file granting unintended access to Silverlight controls.
• Ensuring that there is no crossdomain.xml file granting unintended access to Flash movies
• Verifying that the request's header contains a X-Requested-With (used by Ruby on Rails before v2.0 and Django before v1.2.5), or checking the HTTP Referer header and/or HTTP Origin header. These protections have been proven insecure under a combination of browser plugins and redirects which can allow an attacker to provide custom HTTP headers on a request to any website, hence allowing a forged request.

An easy and effective solution is to use a CSRF filter such as OWASP's CSRFGuard. The filter intercepts responses, detects if it is a html document and inserts a token in to the forms and optionally inserts script to insert tokens in ajax functions. The filter also intercepts requests to check that the token is present.

A variation on this approach is to double submit cookies for users who use JavaScript. If an authentication cookie is read using JavaScript before the post is made, JavaScript's stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of dangerous GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain.

Checking the HTTP Referer header to see if the request is coming from an authorized page is commonly used for embedded network devices because it does not increase memory requirements. However a request that omits the Referer header must be treated as unauthorized because an attacker can suppress the Referer header by issuing requests from FTP or HTTPS URLs. This strict Referer validation may cause issues with browsers or proxies that omit the Referer header for privacy reasons. Also, old versions of Flash (before 9.0.18) allow malicious Flash to generate GET or POST requests with arbitrary HTTP request headers using CRLF Injection. Similar CRLF injection vulnerabilities in a client can be used to spoof the referrer of an HTTP request.

To prevent forgery of login requests, sites can use these CSRF countermeasures in the login process, even before the user is logged in.

Sites with especially strict security needs, like banks, often log users off after (for example) 15 minutes of inactivity.

Using the HTTP specified usage for GET and POST, in which GET requests never have a permanent effect, is good practice but is not sufficient to prevent CSRF. Attackers can write JavaScript or ActionScript that invisibly submits a POST form to the target domain. However, filtering out unexpected GETs prevents some particular attacks, such as cross-site attacks using malicious image URLs or link addresses and cross-site information leakage through <script> elements (JavaScript hijacking); it also prevents (non-security-related) problems with aggressive web crawlers and link prefetching.

Cross-site scripting (XSS) vulnerabilities (even in other applications running on the same domain) allow attackers to bypass CSRF preventions.

Like it ? Share it.

Penetration Testing with BackTrack (Lab Guide)v3.0

Type: E-Book

The following document contains the lab exercises for the course and should be attempted ONLY INSIDE OUR SECLUDED LAB. Please note that most of the attacks described in the lab guide would be considered ILLEGAL if attempted on machines which you do not have explicit permission to test and attack. Since the lab environment is secluded from the Internet, it is safe to perform the attacks INSIDE the labs ONLY. We assume no responsibility for any actions performed OUTSIDE the labs.
Please remember this basic guideline: With knowledge, comes responsibility.

Like it ? Share it.

How to Apply google adsense from blogger

If you are working hard in your blog you deserve some positive result from your blog. Google adsense gives you an opportunity to earn money with your blog. You just need to apply application for your google adsense approval.

Before going, let me tell you,Your blog must comply with all Google Adsense Program policy in order to get approved by adsense team.

 1. Login to your Blogger Account , Choose your Blog , which you would like to apply for adsense from the list( if you own more than one)  in the dashboard .

2. Click on Earnings

3. Click on Sign up for Adsense

(Click on image for large view)

4. Click on Yes, Proceed to google account sign in

5. Write your Password and Click on Sign in

6. Click on Continue

7. Select your county and Fill up your Personal Details. Payee Name should be according to your bank details and be careful while writing your street address you must need to write your house no. or street no. as well write an active mobile no. then Click on Submit my application

8. Click on Continue and Your are Done.

(Click on image for large view)

9. You will receive an email with 2 -7 days from Google Adsense regrading your google adsense approval. If everything fine in your blog your adsense will be approve and google will approach you the next step of approval. 

Like it ? Share it.

WoW64

WoW64 (Windows 32-bit on Windows 64-bit) is a subsystem of the Windows operating system capable of running 32-bit applications and is included on all 64-bit versions of Windows - including Windows XP Professional x64 Edition, IA-64 and x64 versions of Windows Server 2003, as well as 64-bit versions of Windows Vista, Windows Server 2008, Windows 7 and Windows 8. In Windows Server 2008 R2 Server Core, it is an optional component.
WoW64 is designed to take care of many of the differences between 32-bit Windows and 64-bit Windows, particularly involving structural changes to Windows itself.


Translation Libraries

The WoW64 subsystem comprises a lightweight compatibility layer that has similar interfaces on all 64-bit versions of Windows. It aims to create a 32-bit environment that provides the interfaces required to run unmodified 32-bit Windows applications on a 64-bit system. Technically, WoW64 is implemented using three dynamic-link libraries (DLLs):

1. Wow64.dll, the core interface to the Windows NT kernel that translates between 32-bit and 64-bit calls, including pointer and call stack manipulations
2. Wow64win.dll, which provides the appropriate entry-points for 32-bit applications
3. Wow64cpu.dll, which takes care of switching the processor from 32-bit to 64-bit mode

Registry and File System

The WoW64 subsystem also handles other key aspects of running 32-bit applications. It is involved in managing the interaction of 32-bit applications with the Windows components such as the Registry, which has distinct keys for 64-bit and 32-bit applications. For example HKEY_LOCAL_MACHINE\Software\Wow6432Node is the 32-bit equivalent of HKEY_LOCAL_MACHINE\Software (although 32-bit applications are not aware of this redirection). Some Registry keys are mapped from 64-bit to their 32-bit equivalents, while others have their contents mirrored, depending on the edition of Windows.

The operating system uses the %SystemRoot%\system32 directory for its 64-bit library and executable files. This is done for backward compatibility reasons, as many legacy applications are hardcoded to use that path. When executing 32-bit applications, WoW64 transparently redirects 32-bit DLLs to %SystemRoot%\SysWoW64, which contains 32-bit libraries and executables. 32-bit applications are generally not aware that they are running on a 64-bit operating system. 32-bit applications can access %SystemRoot%\System32 through the pseudo directory %SystemRoot%\sysnative.

There are two Program Files directories, both visible to both 32-bit and 64-bit applications. The directory that stores the 32 bit files is called Program Files (x86) to differentiate between the two, while the 64 bit maintains the traditional Program Files name without any additional qualifier.

Incompatible Applications

32-bit applications that include only 32-bit kernel-mode device drivers, or that plug into the process space of components that are implemented purely as 64-bit processes (e.g. Windows Explorer) cannot be executed on a 64-bit platform. Service applications are supported.
The SysWOW64 folder located in the Windows folder on the OS drive contains several applications to support 32-bit applications (e.g. cmd.exe, useful to register 32bit windows services, odbcad32.exe, to register ODBC connections for 32-bit applications). 16-bit legacy applications for MS-DOS and early versions of Windows are usually incompatible with 64-bit versions of Windows Vista, 7 and 8, but can be run on a 16-bit or 32-bit Windows OS via Microsoft Virtual PC or DOSBox. 32-bit versions of Windows XP, Vista, 7, and 8, on the other hand, can usually run 16-bit apps with few to no problems.
The component that makes this possible, Windows on Windows 32-bit, is replaced in 64-bit Windows OSs by WoW64, rendering nearly all 16-bit apps unexecutable.

Internet Explorer is implemented as both a 32-bit and a 64-bit application because of the large number of 32-bit ActiveX components on the Internet that would not be able to plug into the 64-bit version. The 32-bit version is used by default and the 64-bit version cannot be set to be the default browser.