In 2005 I wrote a book on Linux security. 8 years later and the publisher has gone out of business. Now that I'm free from restrictions on reproducing material from the book, I have decided to make the entire book available online. Linux security has changed a lot since 2005; please bear in mind that some of the information may be dated, or rather thin (back in those days, topics such as SELinux and WiFi security were in their infancy, and MD5 was still considered reasonably strong). That said, you'll hopefully still find a lot of useful and relevant information. 1.1 INTRODUCING THE ENEMY In a bedroom somewhere in suburbia, a teenager sits at his computer, watching data slowly scroll by on the screen.

The data in question is the output of a port scanner, working its way through some 64,000 IP (Internet Protocol) addresses in the hope of finding a machine running version 1.2.27 of SSH Communications Security's SSH (Secure Shell) server. It might seem like long odds—indeed, it's already the early hours of the morning—but he's in no hurry. Eventually his patience pays off: Interesting ports on 192.168.0.1: PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 1.2.27 (protocol 1.5) The next step is to launch the x2 exploit, freshly downloaded from a 'hacking' Web site. He has little understanding of how the exploit works (apparently it's 'something to do with buffer overflows'), and doesn't really care either.

May 25, 2015 pleasee help me, how to cracked lazy ssh 1.7, pleaseee. Click to expand. Download tfc (because lazy SSH is in tfc folder).

All that matters is that it's free and it works. He begins typing $./x2 -t1 192.168.0.1 and the attack is underway (shown in ). If ever there was a time to be nervous, this is it. Until now, nothing illegal has happened: port scanning is against many ISP's acceptable user policies, but in most countries it's not a crime. Exploits are a different matter.

If port scanning is analogous to walking past people's houses and checking if their front doors are locked, running exploits can be thought of as entering the house through an open door. If he gains access to the machine, it's simple enough to remove all traces of the attack; but what if it's a honeypot (a system set up to lure attackers), or what if the exploit doesn't work—when the owner returns to his machine, he'll surely see evidence of the attack in his logs. Figure 1.1: An active attack against SSH. With these thoughts circulating in his mind, the attacker watches on anxiously.

After 15 minutes of automated attack, the system is finally compromised: the SSH daemon, which runs with root privileges, has been the victim of a buffer overflow, allowing the attacker to execute arbitrary code on the system. In the case of the x2 tool, a root shell is launched, giving the attacker pretty much complete control over the system. Once on the system, he may proceed to destroy or steal data, or use it as a springboard from which to launch attacks on other networks. The Hacker Myth If you're new to the world of Linux security, the preceding example might not mean much to you.

You're not alone: a large percentage of the people who run the exploit have little idea of how it works either! Welcome to the world of the script kiddie, where knowledge is an optional extra. The media, and indeed hackers themselves, perpetuate the myth that hacking (a very misused term, as you'll see later) is some form of computer black magic, practiced by an elite few.

The truth is somewhat different. The previous scenario used the famous 'SSH deattack' exploit, which surfaced in early 2001, and affected a huge number of UNIX� and Linux machines running certain versions of SSH and OpenSSH.

Undoubtedly, the author of the exploit knew his stuff; but with the source code freely available on the Internet, it was inevitable that thousands of bored teenagers, looking for a new toy, would download and execute the exploit for fun. No knowledge of how the attack works is required—all that is needed is a Unix machine, a C compiler, a little common sense, and a disregard for the law. Don't get your hopes up just yet—there are still plenty of 'real' hackers out there; and just because a person is clueless, it doesn't make him any less dangerous. 1.2 JUST WHO IS AT RISK? The short answer, unfortunately, is 'everybody.'

Regardless of whether you administer a top-secret military research network or own a small home LAN, you are a potential victim. The attacker's motives may vary depending on the nature of your network, but they will still attack. A common response is to say, 'but I have nothing that would be of interest to a hacker' (because people with this view invariably misuse the term 'hacker'). This is to misunderstand the many types of 'hacker' out there, and the motivation that drives each of them. With some, it's financial; with others, it's just for the fun of it, so what the network is used for is entirely irrelevant. In '1.3 The Implications of a Compromise,' we'll look at the different types of attacker that are out there.

Common motives include the following: Financial: Credit card numbers may be stolen and used to buy goods or services online. Bandwidth: Leased lines offer plenty of bandwidth for trading attacking tools and pirated software, or for launching DoS (Denial of Service) attacks. Processing power: Why should a hacker waste his own CPU cycles cracking password files when he can use your processing power?

Curiosity: For a techie, exploring somebody else's network is a fascinating prospect. Most of us confine ourselves to networks we legitimately have access to, though. Ego trip: The more famous the target, the more kudos the hacker receives from his peers. Political/religious: Following September 11th, there was a dramatic rise in defacements of Middle Eastern Web sites by attackers who used it as a means of justifying their actions. They might think they are using their skills to combat terrorism; in fact, they just use it to excuse their cyber vandalism.

Revenge: A disgruntled ex-employee perhaps, or somebody you have insulted on the Internet might try to exact revenge through your network. In the latter case, the attacker might be trying to prove that he's smarter than you. Revenge used to be the main motive that drove crackers; today the remote attacker is far more likely to be a stranger. Anonymity: Using your network as a proxy helps the cracker maintain anonymity while he is surfing the Web, using IRC (Internet Relay Chat), or attacking other networks. These are just a handful of the most common reasons; there are probably as many reasons as there are crackers. Since 1998, the Computer Emergency Response Team (CERT) has been monitoring trends in Internet security. The reports CERT publishes do not make comfortable reading: automation is increasing the speed at which portscans of entire netblocks can be performed, while the exploits used by attackers are growing more and more sophisticated.

A CERT report from 2002[Attack Trends02] cited attacks against DNS (Domain Name System) and DoS attacks as particular cause for concern, claiming that more than 80% of nameservers handling Top Level Domains (TLDs) (such as.com and.uk) were currently vulnerable to some form of attack. More recently, Symantec's sixth Internet Security Threat Report [Symantec04] (which details trends in the first half of 2004) has shown similar findings, with DoS attacks appearing to still be rising, and exploits becoming easier to use. Similar to CERT, the SANS Institute () monitors and researches Internet security, and provides many useful guidelines for administrators. The most famous publication by SANS is undoubtedly its list of the top 20 vulnerabilities affecting Internet-connected systems, which is used as a starting point by security-conscious administrators the world over. Currently in its fourth version, the list details the 10 biggest vulnerabilities for Windows and Unix; all 10 of the Unix vulnerabilities (including much more) are discussed at length in this book.

The popular saying on the Internet, 'the only way to achieve complete security is to unplug your machine from the network,' is not only impractical, but also untrue. Physical access to a machine can also be a big threat, especially in a public environment where not everybody can be trusted. In, ',' we'll look at physical security; in the rest of the book, we'll attempt to take you as close as possible to 'absolute' security. Assessing the Damage Naturally, the system administrator's first concern after learning of a compromise is to evaluate the extent of the damage. Have any files been tampered with? Is there sensitive data stored on the machine that may have been stolen or modified?

It may be tempting to search the filesystem and remove any suspicious files— after all, pressure is on you to get the machine back online as soon as possible—but can you really be sure you've removed or readded everything? Ironically, the more you understand about computers and security, the less likely you would be to answer 'yes' to that question. So the only safe thing to do is scrub the hard disk, reinstall the operating system, and use the backups you keep. On UNIX and Linux machines, the file /etc/shadow is high up on the attacker's agenda—in fact, he probably has a copy of it saved on his own machine—and given enough time, all the passwords in that file will be cracked. If any of these passwords are being used to access other machines, they need to be changed quickly.

In addition, the attacker may have been running a keylogger or sniffer, so it must be assumed that he potentially knows every key typed at the console since the attack, and the contents of every packet that has traveled through the machine. If you've used the compromised machine to log in to an account on another system, that remote system is now at risk too. The problem of sniffing is slightly more subtle. Protocols such as SSH or HTTPS encrypt traffic, making it extremely difficult to construe anything from captured packets; but any service using a plain text protocol (such as Telnet, or POP3) is easily viewable. Later in this book, you'll learn about some of the secure alternatives to the plain text protocols, as well as tunneling connections through encrypted channels using SSH. Things have just gotten a whole lot worse. What started out as a compromise of one machine is now potentially a compromise of the whole network, and we are back to our original question: can you really be sure that you've removed everything?

One backdoor account (a login account created by the attacker to facilitate reentry) or network daemon modified by the attacker is all it takes to bring your network down again. The Cost of Downtime On the corporate LAN, downtime must be kept to a minimum, and preferably scheduled outside of peak hours; but in the event of a compromise, you won't have such luxuries. With the prospect of potentially having to reinstall every machine and restoring data from archives, downtime could be significant. You should already have a strategy for dealing with downtime (such as redundant servers) and for backing up important data (including most of the files in the/ etc directory, not just user data). If not, now is the time to start thinking about one. Incremental backups will be covered later in this book.

Legal Consequences If your network houses sensitive information (such as customer details), or you discover that your network has been used by the intruder to launch attacks on others, a whole new world of potential legal problems open up. Although this is still a fairly new (and gray) area of the law, it all seems to boil down to a favorite puzzle among law students: if you slip on a banana skin in your local supermarket, is the storeowner liable? The answer is 'maybe.' If the skin is still yellow, it has presumably only recently fallen to the ground. The storeowner cannot reasonably be expected to constantly be checking the floor for skins, so he is deemed non-liable.

However, if the banana skin is brown, it has clearly been lying there some time, and the storeowner has been neglecting his duties. The crux of this story is that it isn't the fact that you slipped on the banana skin or the extent of your injuries that governs whether you win or not; it's whether the storeowner was negligent or not. The same logic is being applied to computer crime. Achieving absolute security is an impossible goal (but one which most of us nevertheless strive for). Even the big names of the computing industry have fallen victim to compromise, usually as a result of a fresh vulnerability appearing before they have had time to upgrade.

This isn't a sign of laziness, because the time from a vulnerability being discovered, to an exploit circulating in the wild, can be a matter of hours. So as long as you have made a reasonable attempt to secure yourself, and protect your customer's data, you should [] have a solid case for your defense. Aside from the threat of sensitive information being disclosed, there is also the strong possibility that an intruder will use your network as a base from which to scan and crack others (this is pretty standard practice because scanning from his own machine is too easily traced). Again, unless it can be shown that you neglected your duties as security administrator, the chances of a successful lawsuit against your company are reduced. However, it's better to be on your guard than caught in a legal surprise. Negative Publicity As already mentioned, even the big names can be hit by opportunist crackers, so a compromise does not necessarily reflect badly on the security of a network. Unfortunately, the public doesn't see it that way.

Would you shop online at a company whose customer's credit card details had recently been stolen in a highprofile attack? Before you hush up a security breech, however, you might want to consider that news of this sort has a nasty habit of leaking out, and organizations that attempt to hide it will likely be viewed much less favorably by consumers than those who come clean. If you intend to take any sort of legal action against the attacker(s), news of the compromise will become public knowledge. Surveys have shown [] this to be a very strong reason for companies not to take legal action. In some countries, laws exist to protect the victim from negative exposure in these circumstances; in other countries, the law works to the opposite effect, placing a legal requirement on companies to inform their customers should a security breech lead to the disclosure of customers' confidential information held on the system.

Many people don't take security seriously until they are the victims of an attack—so in a strange twist of irony, those companies who have suffered break-ins in the past are now some of the most secure. To restore customer confidence, often the employee in charge of security is identified as the one who failed to do his job. Hackers Eric S Raymond, in version 4.4.7 of his Jargon File [Raymond03], defines a hacker as: • A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. RFC1392, the Internet Users' Glossary, usefully amplifies this as: a person who delights in having an intimate understanding of the internal workings of a system, computers, and computer networks in particular. • One who programs enthusiastically (even obsessively) or who enjoys programming rather than just theorizing about programming. • A person capable of appreciating hack value.

• A person who is good at programming quickly. • An expert at a particular program, or one who frequently does work using it or on it, as in 'a UNIX hacker.' • An expert or enthusiast of any kind.

One might be an astronomy hacker, for example. • One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations. Note that nowhere in this definition is there any mention of criminal or destructive behavior. In fact, being described as a hacker under this definition is one of the highest accolades a computer enthusiast can receive. Sadly, while Raymond's definition is the one most commonly used throughout the computing industry, it isn't the meaning used by the media. Instead, the media uses 'hacker' to refer to a computer criminal of any shape or form; this is the meaning that has stuck in the public's conscience. Because of these widely contrasting definitions, we'll rarely use the term 'hacker' in this book; but when we do, it should be clear from the context which meaning we intend (for example, 'kernel hacker,' 'threat posed by hackers').

Usually, we mean Raymond's definition. So who are these hackers we've been so pedantic to define correctly? It is no exaggeration to say that hackers build the Internet. Ever since the 1960s, hackers have worked—often in their spare time, and unpaid—on advancing computing technology.

Without hackers, there would be no World Wide Web, no DNS, no Usenet, and certainly no Linux. If there's one thing that annoys hackers, it's being mistaken for the computer criminals who called themselves hackers []. The following sections review various alternative titles that have been assigned to this group of computer criminals, although none of them have fully caught on. Crackers A cracker is a hacker who chooses to use his knowledge for destructive or illegal purposes.

Some choose to think of the word as a contraction of 'criminal hacker.' In his definition of 'hacker' [], Raymond notes: • [deprecated] A malicious meddler who tries to discover sensitive information by poking around. Hence, password hacker, network hacker. The correct term for this sense is cracker.

Crazy Talk 6 Crack Torrent. Unfortunately, this clashes with another commonly used meaning of the word cracker: one who circumvents copyright protection on software. There is no easy way to reconcile these two different meanings, leading many to prefer the phrase 'black hat' for a criminal hacker instead. This book has very little to do with the cracking of software copyrights, so we use the term to mean a criminal hacker. The motivations of the cracker are varied.

With many, it's curiosity or the prospect of a challenge that drives them to gain access to systems illegally. This type of cracker is often nondestructive; they consider their only crime to be that of curiosity. Indeed many will proceed to secure the system they have compromised; then, after they have finished exploring it, leave a message for the admin, explaining how to stop similar break-ins from occurring. One of the distinguishing features of crackers is that they maintain a low profile. Once in, they will remove all evidence of an attack, while at the same time configuring the system to allow them to easily and silently gain access in the future.

Script Kiddies At the bottom of the pile is the script kiddy—a would-be cracker of limited knowledge who can, nevertheless, cause significant damage to a network. The name comes from the fact that most script kiddies are in the 16–25 age group and have limited technical knowledge, preferring to use exploits created by more skilled crackers, often without understanding how they work. Whereas the cracker practices cunning and stealth, the script kiddy has very little subtlety. Respect from their peers is what drives these users (presumably they believe that others will be suitably impressed by their abilities to download and run other people's programs). Most script kiddies can be found on IRC, boasting about how many boxes (systems) they 'own' and threatening other users with DoS attacks. Typical script kiddy behavior includes Web site defacement, DoS, or simply reformatting your hard disk.

Warez D00dz A subset of the script kiddy, warez d00dz (also known as warez kiddiez) compromise systems in an effort to help distribute copyrighted software, movies, or music. Behavior is very similar to that of the script kiddy, with autorooters being used to compromise as many machines as possible. On the Internet, warez are big business, with a huge amount of kudos being attached to obtaining the last blockbuster movie before anyone else.

Unexplained missing disk space coupled with high bandwidth usage is a good sign that a warez d00d has compromised your system.