Leaderboard

Duke Nukem Forever Hail to the King baby.

crysis 2 ...

Zatarra = Vim fan Nu vreau sa fac reclama multa dar sus?in totu?i ca e unul dintre cele mai bune Il voi chema "The Editor" Probabil majoritatea îl ur?sc deoarece nu reu?esc sa îl închid? odat? ce îl deschid sau probabil nici m?car sa scrie , oricum ambele modalit??i "Command mode " si "Insert mode" au rolul lor Confirm Din punct de vedere tehnic ,informatic + Titlu de ScriptKiddie De obicei nu prea atac pe nimeni pe forum ,oricum modul prezentat se conclude in urm?torul profil : "ScriptKiddie hunting the shell , trying to survive with the linux command"

Protecting Linux Against DoS/DDoS Attacks Tuesday, June 28, 2011 Contributed By: Jamie Adams When I first heard ridiculous-sounding terms like smurf attack, fraggle attack, Tribal Flood Network (TFN), Trinoo, TFN2K, and stacheldraht, I didn't take them too seriously for a couple of reasons — I worked mainly on non-Internet facing systems, and I was never a victim. I thought it was primarily a network or application administrator's problem. I am not too proud to admit that I was completely wrong. The truth is that I only had a grasp of the impact of such attacks but I didn't know anything about the methods and the things that can and should be done at the operating system level. I have been neck-deep in completing documentation for our product's Common Criteria for Information Technology Security Evaluation (ISO/IEC 15408) submission so I hadn't had much time to think about topics for a blog post. Besides, how can I compete with all of these eye-catching,dramatic headlines about LulzSec, Anonymous, and Ryan Cleary? A co-worker asked me how our Security Blanket operating system lock down tool could help against denial-of-service (DoS) attacks. So began my research and I quickly had the epiphany that I barely knew anything about DoS attacks. Of course this topic is far too broad and complex to cover in one blog post but I am going to highlight some of my findings. First of all, I strongly recommend visiting the SANS Institute InfoSec Reading Room and reading “A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a Service Provider Environment.” Secondly, read the W3C's “The World Wide Web Security FAQ - Securing against Denial of Service attacks.” In “HACKING the art of exploitation”1, Erikson describes two general forms of DoS attacks: those that crash services and those that flood services. Wikipedia goes on to describe five basic types of attacks: 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. The W3C defines DoS as “an attack designed to render a computer or network incapable of providing normal services. The most common DoS attacks will target the computer's network bandwidth or connectivity. Bandwidth attacks flood the network with such a high volume of traffic, that all available network resources are consumed and legitimate user requests can not get through. Connectivity attacks flood a computer with such a high volume of connection requests, that all available operating system resources are consumed, and the computer can no longer process legitimate user requests.” The W3C differentiates a DoS attack from a Distributed Denial of Service (DDoS) attack. The DDoS “attack uses many computers to launch a coordinated DoS attack against one or more targets. Using client/server technology, the perpetrator is able to multiply the effectiveness of the Denial of Service significantly by harnessing the resources of multiple unwitting accomplice computers which serve as attack platforms.” In the case of smurf and fraggle attacks, one method of prevention is to configure the router to block broadcast packets that did not originate from that network. On Linux systems, you can configure the kernel to disregard ICMP ECHO and TIMESTAMP requests that were sent to broadcast or multicast addresses by setting the kernel parameter net.ipv4.icmp_echo_ignore_broadcasts to one. When it comes to “SYN flood” DoS form of attacks, you can configure Linux to send out requests (syncookies) to remote hosts if they are flooding your system’s backlog queue with SYN packets; to enable this set the kernel parameter net.ipv4.tcp_syncookies to one. These requests check whether or not the inbound SYN packets are legitimate. In cases where these inbound SYN packets are not legitimate, your system might be experiencing a “SYN flood” DoS attack. Enabling this option on a system under normal load is useful. If your system is under high load it will make new connections but without advanced features such as explicit congestion notification (ECN) or selective acknowledgment (SACK). All of the normal hardening procedures for the operating system will of course help. Namely, it will help reduce the likelihood your system will become compromised and become the platform for which attacks will be launched. Additionally, it is critical to know what software is present on your system. One technique to monitor this is to baseline (or fingerprint) your system to include the use of cryptographic hashes where possible. Then periodically, perform another baseline and compare it to the previous one. The use of host-based firewalls (e.g., iptables) is strongly encouraged as well as disabling of unnecessary server services. System minimization has been a topic in many of my posts before and I believe it is one of the easiest but most effective techniques because it reduces your “attack surface.” The W3C FAQ also says, “assume a service should be turned off, unless it is absolutely required.” And I would take it one step further by removing the software packages associated with those unused services. Safeguarding and monitoring operating systems against DoS and DDoS are areas which I continue to learn about and develop techniques. Please, share your knowledge and techniques so we all might learn. Sursa: https://www.infosecisland.com/blogview/14788-Protecting-Linux-Against-DoSDDoS-Attacks.html

This (e-)book is for Linux enthusiasts who want to know how the Linux kernel works. It is not an internals manual. Rather it describes the principles and mechanisms that Linux uses; how and why the Linux kernel works the way that it does. Linux is a moving target; this (e-)book is based upon the current, stable, 2.0.33 sources as those are what most individuals and companies are now using. The Linux Kernel Preface Table of Contents / The Linux Kernel 1st chapter: http://en.tldp.org/LDP/tlk/basics/hw.html File(s) translated from TEX by TTH, version 1.0. Ei bine, have fun! In aditie sursa kernel-ului (STABLE) 2.6.35.13: http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.35/linux-2.6.35.13.tar.bz2 Changelog: http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.35/ChangeLog-2.6.35.13 (pentru cei interesati) In caz doriti mailing list-ul la care participa si Torvalds: http://lkml.org/ (aici gasiti si o lista cu sursele kernelelor Linux -- in coltul din dreapta sus) / https://lkml.org/lkml/2011 + RSS Feed: http://lkml.org/rss.php

Va recomand pentru reverse si nu numai acest tool: API Monitor 2.0 (32-bit/64-bit) API Monitor is a software that lets you monitor and control API calls made by applications and services. Its a powerful tool for seeing how Windows and other applications work or tracking down problems that you have in your own applications. 32-bit and 64-bit Alpha Versions are now available for download. API Monitor: Spy on API Calls and COM Interfaces (Freeware 32-bit and 64-bit Versions!) | rohitab.com