Nytro

Version select versionnumber, version_timestamp from sysibm.sysversions; Comments select blah from foo; -- comment like this Current User select user from sysibm.sysdummy1; select session_user from sysibm.sysdummy1; select system_user from sysibm.sysdummy1; List Users N/A (I think DB2 uses OS-level user accounts for authentication.) Database authorities (like roles, I think) can be listed like this: select grantee from syscat.dbauth; List Password Hashes N/A (I think DB2 uses OS-level user accounts for authentication.) List Privileges select * from syscat.tabauth; -- privs on tables select * from syscat.dbauth where grantee = current user; select * from syscat.tabauth where grantee = current user; Current Database select current server from sysibm.sysdummy1; List Databases SELECT schemaname FROM syscat.schemata; List Columns select name, tbname, coltype from sysibm.syscolumns; List Tables select name from sysibm.systables; Select Nth Row select name from (SELECT name FROM sysibm.systables order by name fetch first N+M-1 rows only) sq order by name desc fetch first N rows only; Select Nth Char SELECT SUBSTR('abc',2,1) FROM sysibm.sysdummy1; -- returns b ASCII Value -> Char select chr(65) from sysibm.sysdummy1; -- returns 'A' Char -> ASCII Value select ascii('A') from sysibm.sysdummy1; -- returns 65 Casting SELECT cast('123' as integer) FROM sysibm.sysdummy1; SELECT cast(1 as char) FROM sysibm.sysdummy1; String Concatenation SELECT 'a' concat 'b' concat 'c' FROM sysibm.sysdummy1; -- returns 'abc' select 'a' || 'b' from sysibm.sysdummy1; -- returns 'ab'

Gasit din intamplare from RedDragon on IRC, handed to newbies... Are You a Hacker? Take a little quiz for me today. Tell me if you fit this description. You got your net account several months ago. You have been surfing the net, and you laugh at those media reports of the information superhighway. You have a red box, you don't have to pay for phone calls. You have crackerjack, and you have run it on the password file at a unix you got an account on. Everyone at your school is impressed by your computer knowledge, you are the one the teachers ask for help. Does this sound like you? You are not a hacker. There are thousands of you out there. You buy 2600 and you ask questions. You read phrack and you ask questions. You join #hack and you ask questions. You ask all of these questions, and you ask what is wrong with that? After all, to be a hacker is to question things, is it not? But, you do not want knowledge. You want answers. You do not want to learn how things work. You want answers. You do not want to explore. All you want to know is the answer to your damn questions. You are not a hacker. Hacking is not about answers. Hacking is about the path you take to find the answers. If you want help, don't ask for answers, ask for a pointer to the path you need to take to find out those answers for yourself. Because it is not the people with the answers that are the hackers, it is the people that are travelling along the path. -ReDragon So You Want To Be A Hacker? Subject: [uXu-453] So You Want To Be A Hacker? [ So You Want To Be A Hacker? ] [ By drazQ ] ____________________________________________________________________ ____________________________________________________________________ So you want to be a hacker? (I'm sorry, but this is your life) written by drazQ (drazq@hotmail.com) Hackers are evil, and powerful - they're the true action-heroes of cyber- space. Everyone wants to be a hacker, and everyone calls themselves hackers. It's all a media hype. It's all a cliche'. And it's all so pathetic. IRC is crowded by the people who love to refer to themselves as hackers. The Internet is polluted by their meanings, ideas, pathetic deeds and their interminable bragging. Cyberspace is polluted by their ignorance. They never stop, they never try to understand. They have no clue what it's all about. They got their first modem in the 90s and went straight on the Internet (Bulletin Board System? Say again?). Even if they try, they can't understand. They're influenced by the others - the others who are just like them. The others who just want to be hackers. The others who call themselves hackers. It's a never-ending circle, and it's so easy to get into it. It's dangerously easy, and once you're in - it's no way back. I know it sounds like a cliche', but it's the truth. That's what it's like. So, who are you? Where do you stand? Why do you want to be a hacker? Have you ever asked yourself those questions ... - and gotten an answer you were comfortable with. Are you sure? I think you're influenced. Influenced by the media hype no.1 of the 90s. Influenced by the ignorant people you associate with. Influenced by texts like this, in magazines like this. I KNOW you are influenced. You can read thousands of texts, discuss hacking with thousands of people - but you won't understand anything before you understand the real hackers. The people who don't even want to call themselves "hackers" anymore, because of what it has become. A pathetic, commercial cliche'. Used and abused. Am I different from you? Maybe, maybe not. I like to think so, but if I sit down and think - try to understand - I realize that I also am influenced by the ignorance. Maybe we're all the same, the "hackers" of the 90s. So what do I want with this text? I want you to think. Lean back, enjoy a Schweppers, and THiNK. --------------------------------------------------------------------------- uXu #453 Underground eXperts United 1998 uXu #453 Call KASTLEROCK -> +1-724-527-3749 --------------------------------------------------------------------------- http://www.packetstormsecurity.org/docs/hack/ethics/

Pfff, tampenie facuta cu Website Maker...

Am si eu un astfel de amic, numai ca el nu cred ca stie ce e ala scam. Keylogger i-am aratat ce e, am testat Digitalul meu. Se crede hacker, chiar daca i-am demonstrat de multe ori ca e ratat. A, Linux-ul pentru el e antivirus.

Elementary security for your Linux box. Author: Michael H. Warfield I'll say at the outset that I feel that the title "Securing Linux" is somewhat misleading. It implies that one can somehow go through a series of steps and emerge at the end with a secure Linux system or network. That isn't true. The real intent of this two-part series is to help you improve the security of your system and to get you to think securely. One without the other is unlikely to succeed. Security is a state of mind Ultimately, security isn't something that is achieved as an end goal; it isn't a state. Rather, it's a way of setting up, maintaining, and running an operating system, network, or environment. Security is a process and a mind-set as well as a condition. It depends on the day-to-day actions of the system or network's users and system administrators. It also depends on the system security not being so intrusive that it encourages users and administrators alike to work around it. But you have to start somewhere, and that somewhere is to improve the security of your system as much as possible while still meeting your operational needs. A system that isn't connected to any network or phone lines and is kept in a locked room is reasonably secure -- but it will meet few of your needs. From there we embark on a series of compromises between the best possible security and the least inconvenience and difficulty that will serve our purposes. Some of these tips are specific to Linux systems, but many are very general principles that apply to all systems and networks -- not just to Unix (or Unix-like) OSs. Less is more Applying the Principle of least privilege and the Principle of minimum access ensures that you open up your system to the least amount of risk. Users are allowed only enough privilege and access to do their work, and no more. Principle of least privilege Users, applications, and even systems should be granted the least amount of privilege required to accomplish their respective tasks. This approach reduces the opportunity for accidental compromise of the system. Ideally, security should not be a burden on your users. It should not get in the way of their ability to accomplish their tasks. Unfortunately, this isn't always the case. You must strike the right balance in terms of who is allowed to do what, and when. Principle of minimum access "That which is not explicitly permitted is denied." This is one of the basic mantras of firewall design. It applies equally well to security in general. In a secure system, you grant access by intent and deny everything else by default. Permission takes place by will or by action. This is a simple fail-safe principle. If you "fail" to take action, you end up failing into a "safe" state (access denied). Set up your basic security mechanisms to deny everything unless you explicitly configure it to be allowed. Set the /etc/hosts.allow file to allow localhost only, and set the /etc/hosts.deny file to deny everything else. With that as a starting point, you can decide who and what will be granted which access, and everything else will be blocked. The default should always be "No!" Do the same thing with your firewall rules, whether you're using a standalone box or a networked system. Firewall code is a useful feature, even if you aren't routing traffic between systems. The Linux kernel has firewall code built in. It just needs to be enabled and configured -- which is well worth the effort. Planning Plan ahead and plan to distribute services. Even before you begin an installation (and, ideally, before you purchase system software solutions), make a detailed plan of your intended security defenses. On paper. Some basic steps along the road Before you decide how to secure your systems, you must first decide how you intend for them to be used. Decide what services each box will use on the network and what services each box you administer will offer to the network. This helps form a security policy. That policy or plan can be simple for simple systems, or it can be a large book for large sites and networks. In either case, it helps to decide what you want to do before you do it. The creation of this policy is also the most frequently overlooked step in developing a secure system. Network layout and design considerations If your site or networks permit it, compartmentalize functions. While this may be impractical for the home user with a single box, one should put different functions on different systems whenever possible. Your DNS, FTP, Web, mail, and firewall should not all be on the same system. If they are, and one service is compromised, they all will be compromised. Placing functions on separate systems limits the damage potential of a successful attack. If you have a limited number of systems and must therefore combine functionality, your security issues are more complicated. You will have to depend on your authentication and authorization systems to provide the isolation that could have been provided by separate boxes. Installation A secure system starts with a secure install. This is one area where the various Linux distributions fail to do an adequate job. All of the distributions are guilty of making it too easy to set up insecure or misconfigured installations. Many of them enable services that the new user is unlikely to be aware of, or enable services before they are fully configured. Some vendors and consultants are now complaining that Linux is much too easy to install, because it allows users to unknowingly install poorly configured servers and shoot themselves in the foot. They are correct. Security starts with the installation Until the Linux distribution vendors wise up and start out with a secure configuration, it's up to the user to turn a basic installation into one with a reasonable shot at being secure. When you're installing your system, never install software unless you intend to use it! Resist the temptation to "just install everything." Some of the things you so casually install could come back to haunt you during a system attack. If your distribution permits it -- and not all do -- hold off on enabling services until you're familiar with them and have configured them. Some distributions assume that if you're installing a service, it should be enabled. If you aren't sure, don't install it! Secure services Internet and network services are among the most vulnerable parts of your system. Whether you're planning a new installation or reviewing security on an existing system, your file servers, e-mail services, Web servers, FTP, and other network services should be among the first things you check for security holes. Some services will obey the /etc/hosts.accept and /etc/hosts.deny configurations if they've been compiled with the TCP Wrapper library, but not all will. Use the firewall code along with the TCP Wrapper configurations to secure your services. Secure file serving If you're exporting any filesystems via NFS, SMB, Samba, or anything else, make sure your access permissions are carefully checked. Never run NFS, SMB, or NIS over the Internet. The risk is just too great. (NIS is jokingly referred to as "network intruder service" and some have referred to NFS as "no file security.") NFS in particular uses UDP and depends on peer addresses for authentication and authorization. But peer addresses are trivial to spoof for UDP! E-mail security If you're running POP or IMAP for remote downloading of e-mail, switch to an SSL-encrypted version. You can use stunnel or edssl to set up SSL-enabled mail servers. Several e-mail clients support SSL POP and/or SSL IMAP, including Netscape and Microsoft Outlook. SSL-enabled fetchmail is available from the North American Cryptographic Archives. If you aren't intending to run POP or IMAP, make sure you really aren't running them. Some distributions enable these by default. Some of the "bad guys" out on the Net are now engaged in massive parallel-port scanning for IMAP servers. If you leave the backdoor open for one of them to get your number, the next time a major root compromise is discovered in IMAP (for example) he or she could promptly come knocking. If you don't know you're running IMAP, you'll have no reason to know when security patches or updates to it become available. Without these upgrades, an intruder could be root on your system before you know what hit you. Secure Web services If you're running a Web server, check and recheck your CGI scripts. Do not allow other users to install arbitrary CGI scripts. Do not use unrestricted server-side includes (SSIs). IRC is one common example of a chat system -- many other chat systems also work with Web servers. If you have any kind of chat server running on your system, make sure common users can't insert arbitrary HTML (hostile JavaScript anyone?) into pages where your Web server can serve them up. Securing FTP If you're operating an anonymous FTP service, watch your permissions closely! Don't allow any directories to be both readable and writable by anonymous users. If you want to permit anonymous uploads to your system, provide a write-only directory and prohibit directory creation underneath it. If you permit a location to be both readable and writable, you not only allow your system to be a "warez" (pirateware) repository, but you also open up your system to being used for "FTP bounce" attacks against other systems. If you're not running anonymous FTP -- make sure you're not. A lot of distributions enable anonymous FTP by default. Disable telnet and finger If you're running telnet, rlogin, or rsh to access your system remotely -- Why?!?!? These are seriously insecure and allow passwords and userids to be "sniffed." For remote access, use secure shell (ssh) connections and disable all nonencrypted remote access to the server. The ssh package can be downloaded and installed very easily. ssh isn't available on any Linux distribution originating in the United States due to US export restrictions on cryptography. Some distributions from outside of the US do include cryptography modules and applications such as ssh and PGP in the base distributions and installations. finger is often configured and available on default installations. Unless you have a specific need for this service, disable it or restrict network access to it. finger provides far too much information about your users to would-be intruders. It is also instrumental in certain advanced forms of denial-of-service attacks such as "nisnuke" on large networks. Up and running Once your system is set up, be sure to keep track of the services you're running. Keep a close eye on services and applications by monitoring your UDP and TCP ports. Tracking down services Go through your system and make sure you're not running any services you don't intend to run, haven't configured, aren't using, or don't understand. I helped a Web site clean out an intruder who broke in using innd, even though the site wasn't running a news system. Installing services that users don't need or understand is a major strike against every Linux distribution -- and most other OSs -- out there. If you run it, they will come Examine /etc/inetd.conf and disable any service you don't want to be running or don't understand. If you do this simply by commenting out the services you don't want, you can easily reenable a service at a later date. But very few of us need echo, chargen, or discard. If you don't need a service, don't use it. And if you don't know what it is, don't run it until you find out. With a typical workstation configuration, it may be possible to turn off all services. For instance, if your machine isn't running any inetd services, you don't need to run the inetd at all. Find out who's listening to what Run nstat -a and look for any unusual ports or services. If you see a TCP port in the state of LISTEN and you can't identify the local port or service, track it down and decide if it's something you really want to be running. Do the same for any UDP ports you find. If it isn't something you specifically want, shut it down. If it's something you want locally but don't want outsiders to access, use the Linux firewall code to block outside access to it. If you have trouble determining what application is listening on a TCP port or opening a UDP port, use the lsof package to track it down. Keep up with the times Keep all software and distributions current with any updates released by the distributor. If the distributor doesn't have a mechanism in place for announcing updates or alerts, consider finding a different distributor. Install updates as soon as they become available. Far too many systems have been broken into because of out-of-date imapd servers, even when updates had been available for months. Password and authentication security Passwords can be the most underestimated security feature you have. Make sure that neither you nor your users are using transparent (easily guessed) passwords, and make sure that your passwords are safe from unauthorized intruders. Good passwords It is frankly stupefying to discover how lax some administrators are about secure passwords. Passwords should be at least five characters long, should mix letters with numbers or other atypical characters, and should be changed several times a year, at the least. Your users should know that password sharing isn't allowed, and former users should be deleted from systems after a reasonable amount of time has passed (i.e., former users should be allowed time to alert all correspondents of their new e-mail address). Ex-user accounts can usually be password-disabled immediately upon the employee's departure. Be aware that more attacks come from disgruntled employees than from any other source. If users are in the habit of sharing passwords, a disgruntled attacker could have access to your system even if you have disabled his or her account. Proceed with caution before implementing this next bit of advice: To ensure that you're not using transparent passwords, you can run the program crack on your own password system. Running crack on your personal system or any system on which you're the administrator is fine. But do not run this program on a system for which you do not have administrative privileges without the consent of the system's management! Warning! Some companies and ISPs take offense at users having "cracker tools" such as crack, or any of a variety of sniffing and scanning tools (described in the section called "Eternal Vigilance") on their systems. If you aren't an administrator on a system, make sure you have permission to possess these items and that the administrator is aware of them. Some people consider the possession of lockpicks to be no different than the possession of burglar tools. If you have tools for cracking passwords or breaking into systems, you may be setting yourself up to answer some very intense questions. Some ISPs don't even ask questions first. Providers have been known to cancel accounts merely for the possession of cracking tools. Don't take the chance. Don't even download these tools if you don't have your administrator's permission! Password handling Not only should you never share passwords or give your passwords out to anyone, you should never leave passwords written down where they can be read. Intruders known as dumpster divers periodically go through the trash looking for scraps of paper with passwords on them. Destroy all security information before discarding. Additional password security If you aren't running a distribution that supports PAM (Pluggable Authentication Modules), then get one. PAM makes it relatively simple to enable advanced password checking, encryption, and longer passwords. When you have it, enable it and use it. If you aren't in a network requiring single sign-on authentication (NIS, NIS+, Kerberos, etc.), enable shadow passwords and MD5 (Message Digest algorithm) hashing. This enables long passwords and makes them much tougher to crack with brute force, and much tougher to steal if you aren't the superuser. Security and the privileged user Never perform routine operations as root! Do your routine work as a nonprivileged user and step up to root only when needed. This is a common mistake of most newbies to Linux (and Unix in general). When you (or a user or a program) must run as root, take the proper security precautions. Don't run as root A couple of years ago we had a Linux "virus" running around. Actually, while some were sure "Bliss" was a virus, others thought it was merely a worm or a trojan. In hindsight, it's probably safe to say that it was something of a hybrid -- mixing a little bit of each. But the important thing is that it only propagated because people were running as root, allowing it to modify system binaries. This is very bad practice. This rule can't possibly be understated! If you routinely run as the root user, you might as well be running DOS -- you have just about that much security! By not running routinely as root, you also reduce the likelihood of "accidents." My son discovered that, if he was running as root, any changes he saved to his desktop were saved to the systemwide configurations. He found out what a bad idea this can be when he got part of the configuration wrong and was then unable to get any account to work right! This kind of accident could lead to unforeseen side-effects and security compromises. Never use a browser or chat program when running as root! While the chance of a hostile applet --- written in Java, ActiveX, or some other language -- is remote, it isn't worth the risk. The destructive capability of such applets is magnified manyfold if you're running as root. What you can do with sudo The program sudo is a useful tool to allow trusted users to perform certain functions as though they were root -- while at the same time limiting their ability to really function as the superuser. It also provides convenient access to those utilities that require root permission to run. By using sudo you avoid the overuse of suid. As with any security tool, sudo should be used with caution. While running a command under sudo, the user's permissions are elevated to root. This makes any potential bugs or security holes in the command or program you're running under sudo more serious than they would be if you were running them as a normal user. For instance, a shell escape out of a sudo-run command is a potential root backdoor. Even some programs that expect to be run only as root can become a security hole under sudo. If the program assumes that only root can run it, and if that program then permits the execution of external commands, there is the potential for the user calling sudo to execute arbitrary commands as root. For this reason, sudo should only be used by trusted users, and with great caution. Beware of software bearing trojans Watch out for trojans! There is a reason why root shouldn't normally have single dots (.) anywhere in his or her path. This helps avoid the danger of having a trojan program like ls sitting in a directory waiting for the superuser to come looking to see what's there. Some distributions still allow single dots in the superuser path. Some distributions have different paths for when you log in as root and when you su to superuser. If a single dot is in the path for either root login or for su to superuser, it should be removed. While its removal isn't a foolproof preventative against trojans, it does help reduce that danger. Trojans are also a serious concern for normal users when it comes to any application that prompts for a password, such as su (since ordinary users can su to any other username to which they have access). Programs that prompt for a password should only be executed as an absolute path to the binary. One way to encourage this is to insert alias su /bin/su into the files /etc/profile and /etc/bashrc so that bash users will automatically use the absolute path. Use the groups, Luke Often, jobs that need root access could be done just as well and more securely through the proper use of group ownerships and secondary group membership. It takes more time to set this up properly, but once it's done right, it more effectively protects system security while granting the access required by normal users. It's very easy and convenient when there are only one or two users on a system to simply perform all maintenance tasks by stepping up to root. But once you have a lot of users and wish to delegate the authority for various tasks to different users, it becomes impractical and dangerous to allow superuser access to everyone performing maintenance. It's well worth the effort to implement an effective group membership configuration when the system is simple, before you really need it -- or before it's too late. Cryptography and security Cryptography is a good thing. It can protect our files, our e-mail, and our communications. Widespread use of cryptography will improve and change the security landscape. Take advantage of cryptography wherever its use is appropriate. With any cryptographic system, the key is the key. The security of your cryptography depends on the security of your key. That can be a private key stored on a system, or a password, or a smart card key. If you decide on a crypto system to guard your security, your problems aren't solved, they've merely changed. Now, instead of guarding your front door, you must guard the keys to the lock on the door. Encrypted communications SSL began its career securing Web servers for e-commerce, and has since been applied to FTP and telnet, as well as to POP and IMAP e-mail services. In addition to simple remote shells and secure copying, ssh is capable of forwarding many services and even tunneling PPP to provide a form of VPN service. Several remote services, such as cvs, rsync, and rdist, can take advantage of ssh to secure their underlying communications. If you want to protect your e-mail, your open source choices are PGP and S/MIME (there are, additionally, several proprietary schemes). Both PGP and S/MIME have advantages and disadvantages, and both have interoperability problems and usability problems. When was the last time you checked the validity of a PGP signature? The "web of trust" model of PGP distributes well, but transitive trust (I trust Sue and Sue trusts Adam but do I trust Adam?) doesn't scale well. The "authority" model of S/MIME has its own scaling problems. Additionally, S/MIME has an annoying infrastructure (and some would say, tax) associated with it. Encrypted files If you want to protect the files on your system, there are several cryptographic filesystems available for Linux, including Matt Blaze's CFS (Crytographic File System). These help secure your files. But on a multiuser system, you still must watch out for trojan password traps and sniffers. Your filesystem encryption is only as secure as the passwords you use to access it. FreeS/WAN The FreeS/WAN project is developing IPSec for Linux. This is now available for both 2.0 kernels and 2.2 kernels, and it interoperates with many other IPSec implementations. For encrypting VPNs and private connections, this is the way to go. To connect gateways between two or more widely dispersed networks, this is the tool to use. Running host to host, however, it is very cumbersome and it will not operate over IP masquerading firewalls or gateways. Further, it isn't trivial to install, and you must guard your keys religiously. Don't be lulled into a false sense of (encrypted) security The tools mentioned here enhance the security of communications, but may or may not improve overall system security. If someone cracks a password by brute force, they're just as free to use the secure channels of access as are authorized users. A recently well-publicized break-in at RootShell was done through ssh. The problem wasn't a vulnerability of ssh -- the attackers had obtained the root password through other means and had simply connected in as if they belonged there. For these reasons, even IPSec isn't the end-all, be-all of security on the Internet. It may eliminate spoofing or certain types of passive sniffing attacks, but it won't stop brute force attacks or protocol attacks. Your e-mail may not be sniffable any longer, but it can still be read if someone compromises and gains access to your system. Your credit card number won't necessarily be sniffed while it's traveling along the wire on its way to an insecure Web server -- but most credit card theft is the result of intruder access to the insecure server itself, not sniffing. Eternal vigilance Once you've secured your installation and checked your basic security and services, your work isn't over. In fact, the job of keeping your system secure is never over. Even if with eternal vigilance, someone, sometime, is likely to get in. With or without the help of any one of a number of monitoring programs, you must keep a watchful eye on what is going on in your system. If you can't block 'em, catch 'em! Enable the firewalling code, even on single systems, and block everything that you don't understand or specifically want on your system. This can put a serious crimp in some rootkit backdoors. Watch out for unusual suid programs. find can be used to locate all of the suid binaries, which can then be tracked for changes or additions. Scan that system! Run a network security scanner on your system! SATAN is one such scanner. Nessus is an excellent open source scanner, as is Trinux. Trinux is a tiny distribution that can boot from floppy disks and scan your network. Internet Security Systems also produces a commercial security scanner. Internet Scanner is free to download and run against your local host. Even if you don't intend to purchase Internet Scanner, or can't afford it (it can be a bit expensive), I would encourage you to get the local host evaluation copy and run it on your system (it's fully functional). Burglar alarms Install an intrusion-detection system. These vary greatly from package to package, and there are commercial and open source versions of most types. Some are host-based systems, monitoring for unauthorized changes to files; others monitor the network or network interfaces for suspicious activities. Check out Tripwire. Tripwire can alert you to modified binaries and permissions. There are commercial variations of this application, including a commercially marketed and supported version of Tripwire itself. Some of the other systems are more extensive than Tripwire, some are not. There are log-monitoring packages available from several of the security sites listed in the Resources section at the end of this article. Log monitors trigger on suspicious activity, such as repeated failed login attempts in security logs. The application can send e-mail to the system administrator or even activate a pager to inform the administrator of an attack in progress. Some are capable of performing even more drastic action, as we'll see in Part 2 of this series. Stay informed New security holes and bugs are discovered and exploited constantly, and new techniques, patches, and fixes are created to counter the threat they present. The only way to safeguard the system you've worked so hard to secure is to stay on top of new information as it becomes available. Stay on top of software updates Subscribe to the mailing lists provided by the Linux distribution vendors to provide announcements of updates or alerts. Monitor the vendor Web sites for errata and updates. Know thine enemy Browse through the various "white hat hacker" sites and get a feel for some of the recent danger points. RootShell and L0pht (both listed in the Resources section) are good places to start. There are also some Linux security sites out there. Warning! Some companies and ISPs take offense at users having "cracker tools" such as crack, or any of a variety of sniffing and scanning tools (available from the various white hat hacker sites, among others) on their systems. These tools can be useful if you run them against your own system to find security holes before a potential intruder does. But f you aren't an administrator on a system, make sure you have permission to possess these items and that the administrator is aware of them. Some people consider the possession of lockpicks to be no different than the possession of burglar tools. If you have tools for cracking passwords or breaking into systems, you may be setting yourself up to answer some very intense questions. Some ISPs don't even ask questions first. Providers have been known to cancel accounts merely for the possession of cracking tools. Don't take the chance. Don't even download these tools if you don't have your administrator's permission! Additional resources: Where they are, what they're for Poke around the public databases. Internet Security Systems (where I work) has several, and we also link to outside sites. Get on some security mailing lists, such as Linux-security or BugTraq. You can find the addresses and subscription information -- and recommended sites for further reading -- in the Resources section. The enemy within is ignorance While advanced security can be difficult to implement, a great deal can be achieved by taking the simple steps of knowing what you're running and disabling services you aren't sure about. Even small sites and single Linux systems can take steps to reduce the risk and harden their security protection. Not all of these ideas are ideal for all circumstances. You have to understand and balance your security needs, your network design, your functionality needs, and your security policy (if you have one). In any case, knowledge is your best security tool and ignorance is your worst enemy. Use our comprehensive list of Resources for even more information, and to stay abreast of developments. About the author Mike Warfield is a senior security researcher on the Internet Security Systems X-Force. He is also a member of the Samba Development Team, a founding member of the Atlanta Linux Enthusiasts, and a long-standing guru with the Atlanta Unix Users Group. He has been involved in Unix systems for over 15 years and with computer security for over 25 years. Resources Read Michael Warfield's previous On the Ramparts columns in the LinuxWorld archives: http://linuxworld.com/linuxworld/archive/columnsbydate.html#ramparts Further reading and security resources (Most of the sites listed below feature additional security resources and links.) North American Cryptographic Archives: Welcome to Cryptography.org Trinux: http://www.trinux.org/ Nessus: Tenable Network Security Psionic Software / Abacus Sentry: We’re sorry this page is no longer available RootShell: www.rootshell.com L0pht Heavy Industries: L0pht Heavy Industries Deception Toolkit: Deception ToolKit "Securing Your Linux Box," Peter Vertes (Linux Gazette, Issue 34, November 199: Linux Journal | The Original Magazine of the Linux Community Wietse Venema's collected tools and papers: ftp://ftp.porcupine.org/pub/security/index.html Solar Designer's Secure-Linux Patch: http://freshmeat.net/appindex/1998/06/14/897822718.html StackGuard: http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ Internet Security Systems: IBM Internet Security Systems CERT Security Improvement modules: http://www.cert.org/security-improvement/ CIAC (Computer Incident Advisory Capability): http://ciac.llnl.gov/ciac/ BugTraq: bugtraq@securityfocus.com Linux-Security: linux-security@redhat.com Linux Administrator's Security Guide (LASG): https://www.seifried.org/lasg/

This article presents a systematic method to prepare your system for the Internet. Author: Lance Spitzner Organizations throughout the world are adopting Linux as their production platform. By connecting to the Internet to provide critical services, they also become targets of opportunity. To help protect these Linux systems, this article covers the basics of securing a Linux box. The examples provided here are based on Red Hat 6.0, but should apply to most Linux distributions. Installation The best place to start in armoring your system is at the beginning, OS installation. Since this is a production system, you cannot trust any previous installations. You want to start with a clean installation, where you can guarantee the system integrity. Place your system in an isolated network. At no time do you want to connect this box to an active network nor the Internet, exposing the system to a possible compromise. I personally witnessed a system hacked by a script kiddie within 15 minutes of connecting to the Internet. To get critical files and patches later, you will need a second box that acts as a go between. This second box will download files from the Internet, then connect to your isolated, configuration "network" to transfer critical files or burn the patches to a CDROM. Once you have placed your future Linux box in an isolated network, you are ready to begin. The first step is selecting what OS package to load. As of RH 6.0, you have three options, Workstation, Server, and Custom (default). I highly recommend Custom, as this allows you to choose what services are added and how the system is partitioned. The idea is to load the minimum packages, while maintaining maximum efficiency. The less software that resides on the box, the fewer potential security exploits or holes. This means if you do not need a News or Real Audio Server, don't install it. The nice thing about Linux is, if you change your mind, it is easy to add packages later. Regardless of which installation you choose, I would add the manual pages and HOWTO docs. I find the on-line man pages and docs to be a critical resource that add little risk to your system. If you selected Custom, you will be asked to partition your system. I always like to make root as big as possible and just throw everything in there, then you do not run out of room in the future. However, we do need several partitions to protect the root drive. If we were to fill the root partition with data, such as logging or email, we would cause a denial of service, potentially crashing the system. Therefore, I always recommend a separate partition for /var, this is where all the system logging and email goes. By isolating the /var partition, you protect your root partition from overfilling. I've found 400 MB to be more then enough for /var (increase this if your system will have alot of mail) . You may also consider making a separate partition for specific application purposes, especially applications that store extensive logging. If you are going to have users on your system you do not trust, you may also want to create a seperate /home directory, so malicious users cannot fille the / partition. For a standalone server, your partitions may look as follows: / - everything else /var - 400 MB swap - (I normally go with 256 MB) Once the system has rebooted after the installation, be sure to install the recommend security patches. For Red Hat, you can find these security patches at Red Hat's errata support site. Patches are critical to armoring a system and should always be updated. bugtraq@securityfocus.com or redhat-watch-list-request@redhat.com are excellent sources for following bugs and system patches. Without these patches, your system can be easily compromised. Be sure to use your go between box to get the patches, the Linux box should always remain on an isolated network. . For Red Hat, once you download the rpm, you can easily update your system using the following syntax. An excellent example of this is the security update for wu-ftpd rpm -Uvh wu-ftpd-2.6.0-14.6x.i386.rpm For systems that are already on-line, you can ftp the rpm and install it at the same time, using the following syntax. rpm -Uvh ftp://updates.redhat.com/6.1/i386/wu-ftpd-2.6.0-14.6x.i386.rpm As of RH 6.1, there is a new utility for patches called 'up2date'. I highly recommend you try this excellent utility. When ran on a local system, it determines which .rpm's need to be updated, gets those rpm's from Red Hats's web site, and then downloads and installs the updated files. This tool is highly customizable and easy to use. Eliminating Services Once you have loaded the installation package, patches, and rebooted, we are now ready to armor the operating system. Armoring consists mainly of turning off services, adding logging, tweaking several files, and configuring TCP Wrappers. First we will begin with turning off services. By default, Linux is a powerful operating system that executes many useful services. However, most of these services are unneeded and pose a potential security risk. The first place to start is /etc/inetd.conf. This file specifies which services the /usr/sbin/inetd daemon will listen for. By default, /etc/inetd.conf is configured for a variety of services, you most likely only need two, ftp and telnet. You eliminate the remaining unnecessary services by commenting them out (example A). This is critical, as many of the services run by inetd pose serious security threats, such as popd, imapd, and rsh. Confirm what you have commented out with the following command (this will show you all the services that were left uncommented) grep -v "^#" /etc/inetd.conf The next place to start are the .rc scripts, these scripts determine what services are started by the init process. For Red Hat, you will find these scripts in /etc/rc.d/rc3.d (or /etc/rc.d/rc5.d if you automatically boot to a GUI, such as Gnome or KDE). To stop a script from starting, replace the capital S with a small s. That way you can easily start the script again just by replacing the small s with a capital S. Or, if you prefer, Red Hat comes with a great utility for turning off these services. Just type "/usr/sbin/setup" at the command prompt, and select "System Services", from there you can select what scripts are started during the boot up process. Another option is chkconfig, which you will find on most distributions. The following startup scripts may be installed by default but are not critical to system functioning. If you don't need them, turn these scripts off. The numbers in the names determine the sequence of initialization, they may vary based on your distribution and version. Scripts that start with a capital K instead of a captial S are used to kill services that are already running. S05apmd (You only need this for laptops) S10xntpd (Network time protocol) S11portmap (Required if you have any rpc services, such as NIS or NFS) S15sound (Saves sound cared settings) S15netfs (This is the nfs client, used for mounting filesystems from a nfs server) S20rstatd (Try to avoid running any r services, they provide too much information to remote users) S20rusersd S20rwhod S20rwalld S20bootparamd (Used for diskless clients, you probably don't need this vulnerable service) S25squid (Proxy server) S34yppasswdd (Required if you are a NIS server, this is an extremely vulnerable service) S35ypserv (Required if you are a NIS server, this is an extremely vulnerable service) S35dhcpd (Starts dhcp server daemon) S40atd (Used for the at service, similar to cron, by not required by the system) S45pcmcia (You only need this script for laptops) S50snmpd (SNMP daemon, can give remote users detailed information about your system) S55named (DNS server. If you are setting up DNS, upgrade to the latest version of BIND, http://www.isc.org/bind.html) S55routed (RIP, don't run this unless you REALLY need it) S60lpd (Printing services) S60mars-nwe (Netware file and print server) S60nfs (Use for NFS server, do not run unless you absolutely have to). S72amd (AutoMount daemon, used to mount remote file systems) S75gated (used to run other routing protocols, such as OSPF) S80sendmail (You can still send email if you turn this script off, you just will not be able to receive or relay) S85httpd (Apache webserver, I recommend you upgrade to the latest version, http://www.apache.org) S87ypbind (Required if you are a NIS client) S90xfs (X font server) S95innd (News server) S99linuxconf (Used to remotely configure Linux systems via browser, every black-hat's dream To see how many services are running before you change the startup scripts, type ps aux | wc -l Once you are done with the installation and have turned off the startup scripts, type the command again and compare how the number of services have decreased. The fewer services running, the better. Also, confirm which are left running by executing the following command: netstat -na --ip Logging and Tweaking Once you have eliminated as many services as possible, we want to enable logging. All system logging occurs in /var/log. By default, Linux has excellent logging, except for ftp. You have two options for logging for ftp, configure /etc/ftpaccess file or edit /etc/inetd.conf. I prefer to edit /etc/inetd.conf, as it is simpler (i.e. harder to mess up . Edit /etc/inetd.conf as follows to ensure full logging of all FTP sessions. ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -L -i -o --- From the man pages --- If the -l option is specified, each ftp session is logged in the syslog If the -L flag is used, command logging will be on by default as soon as the ftp server is invoked. This will cause the server to log all USER commands, which if a user accidentally enters a password for that command instead of the username, will cause passwords to be logged via syslog. If the -i option is specified, files received by the ftpd( server will be logged to the xferlog(5). If the -o option is specified, files transmitted by the ftpd( server will be logged to the xferlog(5). --- snip snip --- Next comes tweaking. This involves various file administration. The first thing we want to do is secure our /etc/passwd file (this is the database file that holds your user accounts and passwords). First, we want to ensure our system is using /etc/shadow, this securely stores everyone's password as hashes in a file only root can access. This protects your passwords from being easily accessed and cracked (one of the first exploits a hacker looks for). The use of shadow passwords is default as of RH 6.0, however it never hurts to be sure. All you have to do is type the following command as root. This automatically converts your passwords to the /etc/shadow file. Of all the actions you can take to secure your system, I consider this to be one of the most important. pwconv The second step is to remove most of the default system accounts in /etc/passwd. Linux provides these accounts for various system activities which you may not need. If you do not need the accounts, remove them. The more accounts you have, the easier it is to access your system. An example is the "news" account. If you are not running nntp, a news group server, you do not need the account (be sure to update /etc/cron.hourly, as this looks for the user "news"). Also, make sure you remove the "ftp" account, as this is the account used for anonymous ftp. From the man pages. man ftpd: Ftpd authenticates users according to four rules. 4) If the user name is ``anonymous'' or ``ftp'', an anonymous ftp account must be pre-sent in the password file (user ``ftp''). In this case the user is allowed to log in by specifying any password (by convention this is given as the client host's name). For an example of my /etc/passwd file, check out example C. We also want to modify the file /etc/ftpusers (example D). Any account listed in this file cannot ftp to the system. This restricts common system accounts, such as root or bin, from attempting ftp sessions. Linux has the file by default. Ensure that root stays in this file, you never want root to be able to ftp to this system. Ensure that any accounts that need to ftp to the box are NOT in the file /etc/ftpusers. Also, ensure that root cannot telnet to the system. This forces users to login to the system as themselves and then su to root. The file /etc/securetty lists what ttys root can connect to. List only tty1, tty2, etc in this file, this restricts root logins to local access only. ttyp1, ttyp2, are pseudo terminals, they allow root to telnet to the system remotely (example E). Last, create the file /etc/issue. This file is an ASCII text banner that appears for all telnet logins (example B). This legal warning will appear whenever someone attempts to login to your system. If you want to continue using the same /etc/issue file, you will have to modify /etc/rc.d/init.d/S99local. By default, Linux creates a new /etc/issue file on every reboot. Connecting to your server For those of you who will be doing remote administration, it is critical that you develop a secured, controlled way to connect to the server. Often, you need remote access to your server for administration or the uploading of files, these communications need to be secured I will discuss two options here, ssh and TCP Wrappers. I prefer ssh, as it encrypts all communication between you and the firewall. TCP Wrappers will NOT protect your network traffic from sniffing. Users can still capture all of your keystrokes (including passwords) on the network. If you are concerned about users capturing communications to your firewall, I recommend you replace telnet/ftp with ssh. ssh will encrypt all communications to your server, allowing you both to upload files and administer the server in a secure manner. ssh is similar to TCP wrappers in that it has its own layer of logging, and can limit what systems can connect to it. For more information on ssh, you can find ssh here, including source for both ssh clients and server daemon. I recommend you use ssh version 1.2.x, as version 2.x has a limiting license. Another ssh option is Openssh. TCP Wrappers, while it does not encrypt, it does log and control who can access your system. It is a binary that wraps itself around inetd services, such as telnet or ftp. With TCP Wrappers, the system launches the wrapper for inetd connections, logs all attempts and then verifies the attempt against a access control list. If the connection is permitted, TCP Wrappers hands the connection to the proper binary, such as telnet. If the connection is rejected by the access control list, then the connection is dropped. Fortunately for us Linux users, TCP Wrappers is already installed, the only thing left for us to do is edit the /etc/hosts.allow and /etc/hosts.deny file. These files determine who can and cannot access our systems. Also, TCP Wrappers allows us to do fancy things, such as banners or spawn additional programs, such as safe_finger. The syntax is relatively simple. Put the IP address or networks in /etc/hosts.allow that you want to permit connections from. Put IP addresses or networks in /etc/hosts.deny that you do not want to permit access. By default, Linux allows connections from everyone, so you will need to modify these files. 2 recommendations when working with TCP Wrappers. Use IP addresses instead of system or domain names. Set up /etc/hosts.deny to deny everything (ALL), then permit only specific sites with /etc/hosts.allow. For examples on how to setup /etc/hosts.allow and /etc/hosts.deny, see example F. For more ideas on how to use TCPWrappers, check out Intrusion Detection. For the Truly Paranoid I consider the measures discussed above absolutely essential. By following these steps, you have greatly improved your system's security, congratulations! Unfortunately, your system is not 100% secure, nor will it ever be. So, for the truly paranoid, I have added some additional steps you can take. First we will create the wheel group. The wheel group is a group of select individuals that can execute powerful commands, such as /bin/su. By limiting the people that can access these commands, you enhance the system security. To create the group, vi the file /etc/group, create the group wheel, and add the system admins to the group. Then identify critical system binaries, such as /bin/su. Change the group ownership to wheel, and the permissions to owner and group executable only (be sure to maintain the suid or guid bit for specific binaries). For /bin/su, the commands would be: /bin/chgrp wheel /bin/su /bin/chmod 4750 /bin/su Second, we will lock down the files .rhosts, .netrc, and /etc/hosts.equiv. The r commands use these files to access systems. To lock them down, touch the files, then change the permissions to zero, locking them down. This way no one can create or alter the files. For example, /bin/touch /root/.rhosts /root/.netrc /etc/hosts.equiv /bin/chmod 0 /root/.rhosts /root/.netrc /etc/hosts.equiv Third, we configure /etc/shadow to use MD5 hashes instead of the crypt(3) function. This makes the encrypted password file far more difficult to crack. This is done by modifying the PAM modules. PAM (Pluggable Authentication Modules) is a suite of shared libraries that enable you to choose how applications authenticate users. To learn more about PAM, check out ftp://ftp.us.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html. In the old days, you had to manually modify the PAM modules to use MD5 hashes. However, with Red Hat 6.0 or greater, you can select MD5 hashes with the setup utility. Just type "setup" at the command prompt, then select "authentication configuration". From there, you can choose to use MD5 hashes. However, the MD5 hashes will not take effect until the user re-enters their password. For those of you who do not have the setup utility (or have Red Hat 5.2 or earlier), you can still modify the PAM modules manually (example G). For us bash users, I'm not a big fan of the .bash_history file. I do not want people (including root) to know my command history. So, in my .bash_profile, I export the following entry: HISTFILESIZE=0 This means that nothing will be logged to my .bash_history file. I will still have keystroke history and recall, the HISTSIZE env variable, but command history will not be written to the .bash_history file. Last thing we can do is protect our system from physical access. This mainly consists of setting up a password for our BIOS. Also, you can password protect your system during boot-up by configuring /etc/lilo.conf with a password (password=xxx) where xxx is your password. However, keep in mind, once someone has physical access to your system, there is no guaranteed way to protect it. IPChains No discussion about Linux security would be complete without covering IPChains. IPChains is packet filtering software that comes with the 2.2.x kernel and above. This means if you are running Red Hat 6.0 or later, you have it as part of your Linux installation kit. IPChains is similar to Cisco Access Control Lists, it can control what packets can come in and out of your Linux box. Primarly used as a firewall application, IPChains can also be used to armor your standalone Linux box. To armor a standalone system, I configure IPChains to allow only TCP connections I initiate. If anyone attempts to initate any TCP connections to me, the connection is denied. Since IPChains is not stateful, I do allow all UDP and ICMP connections. Last, I log all denied connections, this lets me know if someone out there is being naughty However, I drop but do not log all the broadcat/multicast traffic, as this would quickly fill up the system logs. A simple IPChains configuration to armor a standalone system would look something like this. bash# ipchains -L Chain input (policy DENY): target prot opt source destination ports DENY all ------ 0.0.0.0 anywhere n/a DENY all ------ anywhere 255.255.255.255 n/a DENY all ------ anywhere BASE-ADDRESS.MCAST.NET/8 n/a ACCEPT tcp !y---- anywhere anywhere any -> any ACCEPT udp ----l- anywhere anywhere any -> any ACCEPT icmp ----l- anywhere anywhere any -> any DENY all ----l- anywhere anywhere n/a Chain forward (policy ACCEPT): Chain output (policy ACCEPT): To see the config files for this, see example H. To learn more about using IPChains as a firewall or for a standalone system, check out the IPChains HOWTO. Conclusion We have covered some of the more basic steps involved in armoring a Linux box (Red Hat distribution). The key to a secure system is having the minimal software installed, with protection in layers, such as TCP Wrappers, IPChains, and shadowed passwords. There are many additional steps that can be taken, such as tripwire (monitor changes in system binaries) and swatch (automated log monitoring and alerts). I also recommend that new Linux users check out Bastille Linux, a PERL script that can automatically secure your new Linux system, step by step. Remember, no system is truly 100% secure. However, with the steps outlined above, you greatly reduce the security risks.

Not so good as Solaris Security FAQ, but this article has some interesting things. Author: Ido Dubrawsky Activity on the Net has grown phenomenally over the past several years. More and more companies and individuals are connecting to the Internet every day. Today, it is essential for any company to have some sort of presence on the Net. Whether it be a Web page or simply an email server, this presence could mean the difference between success and failure. Given that fact, more and more companies are setting up some sort of server to provide an Internet presence for themselves. These servers, however, are sometimes not installed with security in mind, thereby becoming tempting targets for system crackers. As evidenced recently with a sudden surge of distributed denial of service attacks (or DDOS), system crackers are finding these machines and using them for setting up their DDOS clients. Web sites, especially highly visible ones, are choice targets of attacks whether for profit or just plain vandalism. The tools for identifying machines have certainly improved. One of the most well-known tools for scanning a network, NMAP, is well written, easy to use, and (for anyone who has root access to a box) provides a great deal of information about a potential target. The best way to reduce the possibility of attack on a system is to provide the least amount of information about it. An attacker knowing that a system was running Solaris 2.6 or Solaris 7 back in December of 1999 might also know that rpc.sadmind could be running and is exploitable. By reducing the amount of information that can be gathered about a system, a systems administrator can reduce the likelihood of a successful attack. This article describes simple changes that can be made to make a Solaris system a harder target. While the techniques described here do not guarantee that an attacker will not find a way in, they do increase the difficulty for a successful attack. TCP Wrapper One of the first things to do after installing a Solaris, or any other UNIX, operating system, is to install Wietse Venema's TCP Wrapper. TCP Wrapper provides a measure of host-based access control. While not providing a great deal of extra security to a system, it provides better logging as well as some other customizable features such as reverse fingering of an unauthorized access attempt, or the displaying of banners in case of a failed access attempt. Take care when configuring some of the TCP wrapper capabilities. For example, using the reverse finger configuration, if the system also has TCP wrappers and is configured to perform a reverse finger, may cause the two systems to get into a loop that will eventually bog both systems down. Although a discussion of configuring and installing TCP Wrapper is beyond the scope of this article, the software is very much worth having and can be found at: ftp://ftp.porcupine.org:/pub/security/tcp_wrappers_7.6.tar.gz. RPCbind Remote Procedure Call (RPC) services are used in many network services including NIS, NIS+, NFS, Kerberos, sadmind, and others. Software utilizing RPC uses the rpcbind program to convert RPC program numbers into universal addresses. When a client makes an RPC call to a server, the client first contacts the rpcbind program to find out the address on which the server software is listening. Solaris has many daemons and services that utilize RPC. These include: sadmind • rquotad • rusersd • rsprayd • rwalld • rstatd • rexd • ufsd • kcms_server • rpc.cmsd • gssd • rpc.ttdbserverd • rpc.bootparamd cachefsd All of the above services, except for rpc.bootparamd, are started from inetd.conf. rpc.bootparamd is started from /etc/rc3.d/S15nfs.server and is only necessary if the system is also a boot server. Unless specifically required, the above services can all be commented out of inetd.conf to disable them. A further step to take regarding rpcbind is to replace the stock Solaris rpcbind program with Wietse Venema's rpcbind 2.1 program. Venema's version is designed to be a drop-in replacement for the stock Solaris rpcbind. This new rpcbind is based on the transport-independent RPC source distribution from Sun. The replacement rpcbind program provides for host access control similiar to that provided by TCP Wrapper. Furthermore, all requests that are forwarded by the rpcbind process are done through an unprivileged port, and all remote requests sent to high-numbered UDP ports are rejected. Unlike TCP Wrapper, the host access control code looks only at the IP address of the source. Overall, rpcbind 2.1 provides another layer of protection beyond the stock Solaris system. Wietse Venema's rpcbind 2.1 program can be found at: ftp.porcupine.org//pub/security/rpcbind Reducing Solaris' Footprint The first thing to do when reducing the footprint of a Solaris box is to remove any and all "announcements" sent out to the world. What are these announcements? When someone telnets to a box running Solaris, they are greeted with the response: $ telnet 10.16.17.205 Trying 10.16.17.205... Connected to 10.16.17.205. Escape character is '^]'. SunOS 5.7 login: This is a simple, quick, and effective way to find out what OS is running on that system. (The fact that telnet access should be restricted using either TCP Wrapper or replaced entirely with Secure Shell is another story.) To close this information leak, the file /etc/default/telnetd should be created with the following line in it: BANNER="" This effectively eliminates the SunOS 5.7 banner from telnet. $ telnet 10.16.17.205 Trying 10.16.17.205... Connected to 10.16.17.205. Escape character is '^]'. login: Similarly, in the file /etc/default/ftpd, the same BANNER="" command removes the SunOS 5.7 id tag from the ftpd prompt: $ ftp -i 10.16.17.205 Connected to 10.16.17.205. 220 nostromo FTP server () ready. Name (10.16.17.205:ido): If the system is running with a default installation of Solaris, Sendmail is running in daemon mode. This is another source of information that can easily be plugged with a little effort. If the machine is not a mail server, then there is no need to run Sendmail at all. (Another option is to have Sendmail run periodically out of cron to process the mail queue, or Sendmail can be set to run in non-daemon mode by removing the -bd flag from /etc/init.d/sendmail.) If the system needs to have Sendmail running in daemon mode and if it is not configured properly, then it is providing a potential attacker with vital information. By telneting to port 25, the attacker is greeted with the following information: $ telnet 10.16.17.205 25 Trying 10.16.17.205... Connected to 10.16.17.205. Escape character is '^]'. 220 nostromo.dubrawsky.org ESMTP Sendmail 8.9.1b+Sun/8.9.1; Fri, 18 Feb 2000 06:13:09 -0600 (CST) Not good. Not only does the attacker now know the name of the machine, but he or she also knows that it is running the stock Sendmail provided by Sun with Solaris 7. To eliminate this greeting, edit change the value of SmtpGreetingMessage in the sendmail.cf file (found in /etc under Solaris 2.6 and in /etc/mail in Solaris 7 and Solaris : # SMTP initial login message (old $e macro) #O SmtpGreetingMessage=$j Sendmail $v/$Z; $b O SmtpGreetingMessage= The Sendmail greeting is now: $ telnet 10.16.17.205 25 Trying 10.16.17.205... Connected to 10.16.17.205. Escape character is '^]'. 220 ESMTP inetdThe next step is to eliminate unsecure or unnecessary services from operation. The first place to start is /etc/inet/inetd.conf. This file contains the configuration for inetd, a system process that listens for incoming connections and then starts the requested service. Most of what is in inetd.conf comes from the days when the Internet was smaller and system break-ins less frequent. To prevent inetd from starting a service, the line in the configuration file for that service can either be commented out or deleted entirely. To provide a measure of logging, inetd's startup line in /etc/init.d/inetsvc should have the -t flag added as shown below: /usr/sbin/inetd -s -t &The -t flag causes inetd to trace incoming connections for TCP services. UDP services cannot be traced. The information is logging using the syslog facility level of daemon.notice. By default, this information would be logged to /var/adm/messages. If the system is running Secure Shell, then the r-* programs (e.g., rsh, rlogin, rexec, etc.) should be disabled. Listing 1 provides a list of services that should be removed from inetd.conf (excluding telnet and ftp). Unless an application is installed that requires the services of one of these inetd clients, it is best to disable them completely by either commenting them out of inetd.conf or deleting them and then sending the SIGNUP signal to the inetd process so that it will re-read its configuration file. telnet and ftp should also be disabled and replaced with secure shell even if the system is behind a firewall. All too often, the source of system compromise is not the hacker on the outside, but the hacker on the inside! Improving Solaris TCP Stack Strength Once unnecessary services have been disabled, the next step in hardening the Solaris host against attackers is to prevent them from using common scanning tools such as nmap to detect the operating system type. Generally, this is done by tweaking Solaris's TCP/IP stack so that nmap cannot identify it through TCP fingerprinting. Several kernel variables affect the ability of a scan's success. Consider a vanilla Solaris box, that has already been installed, but has had no changes made to the kernel parameters governing the network services. A sample scan of such a system is provided in Listing 2. The services that nmap identifies can be removed either by shutting off the service entirely (as in the case of X11) or removing the service from /etc/inet/inetd.conf. The information to focus on is the "TCP Sequence Prediction" and "Remote OS Guesses" that nmap provides. By identifying the target operating system, an attacker can narrow potential exploits. In the case of the system shown here, sadmind might be a good starting place to try an attack. An attacker might also wonder whether the secure shell daemon, sshd, was compiled with the rsaref2 library, recently shown to be vulnerable to a buffer overflow. Nmap classified the TCP Sequence Prediction for the example host as "random positive increments" with a difficulty on the order of 105 (i.e., a worthy challenge). If the attacker knows Solaris well enough, this tells them the host has a setting of TCP_STRONG_ISS=1 (as found in /etc/default/inetinit). This host may be susceptible to a TCP sequence attack, especially since it permits rsh. Fortunately, by tuning TCP/IP kernel parameters, OS fingerprinting can be made much more difficult. Solaris Kernel Tuning Solaris 2.5.1 and above provides for the ability to change certain kernel tuning parameters through the use of the program /usr/sbin/ndd. ndd gets and sets selected configuration parameters in kernel drivers that implement the TCP/IP protocol family. Changes made by ndd can be made at any time while the system is running. However, these changes do not survive across a system reboot and must be applied every time the system reboots in order to be permanent. One of the main problems of using ndd and writing scripts that depend on it is that the kernel parameters are not readily available from Sun's documentation. Also, these kernel parameters may change without notice from one version of Solaris to another. For that reason, it is important to proceed with caution. Changing some of these parameters may cause problems; however, the parameters discussed in this article have been altered in systems installed in a production environment and do not appear to cause any harm. Furthermore, the parameter names that are discussed here and that are adjusted by the included program, secureip, have not changed in the Solaris operating systems versions 2.5.1, 2.6, and 7. The following sections describe some possible kernel tuning options. You must decide whether these options are appropriate for your environment. TCP/IP Fingerprints Before discussing changes to the default Solaris TCP/IP stack parameters, I will discuss how TCP fingerprinting works as it relates to nmap. nmap and other scanning tools rely on certain unique elements in a TCP/IP stack to identify the operating system. nmap is good enough that it can reliably distinguish between a host running Solaris 2.4 vs. Solaris 2.5-2.51, and Solaris 2.6. The program does this with several techniques: 1. FIN probe -- A FIN packet is sent to an open port, and the response is evaluated. The correct response, defined by RFC 793, is not to respond at all. However, many stack implementations do not adhere to this and return an RST response. 2. TCP Initial Sequence Number (ISN) -- Determining the TCP ISN is crucial if an attacker wants to hijack a session with the target host. ISN generation can be broken down into three categories: 64-K increments, random increments, and truly random increments (RFC 1948 compliant). By default, Solaris installs using "random increments". Given sufficient time, an attacker can collate enough data to guess at the next ISN number that the system will use. 3. Don't Fragment (DF) bit -- Solaris sets this bit by default, regardless of whether it is needed. 4. TCP initial window -- Some operating systems, Solaris included, return a constant window size. 5. TCP Options -- These generally provide the most information. Since they are optional, not all hosts support them, however, if they do, then the host may echo back the options in the response. If the options are echoed back, the values set in the response can be used to identify the operating system. With the above information, it is possible to change some of Solaris's default TCP/IP stack settings, without harming performance and gaining the benefit of hiding the operating system identity from such tools. The first of these settings to consider is the TCP Maximum Segment Size (MSS). TCP MSS is used to set the largest amount of data that TCP will send to the receiving side. Whenever a connection is about to be established, the segment size used is set to the MTU of an outgoing interface or to the MSS announced by the peer. Each side announces its MSS and, if one end does not receive the other side's MSS option, it uses a default of 536. Both nmap and queso exploit this fact. The best solution is to change the default MSS value. Generally, the larger the MSS the better, until fragmentation occurs. To change the default MSS on Solaris: # ndd -set /dev/tcp tcp_mss_def 546 Another parameter that can leak out information is the path MTU discovery. If path MTU discovery is turned on, then all outgoing IP packets have the "Don't Fragment" bit set in the IP header. To turn this characteristic off: # ndd -set /dev/ip ip_path_mtu_discovery 0 It is not necessary to turn off the path MTU discovery. RFC 1191 recommends that the path MTU discovery occur approximately every 10 minutes. Solaris, however, does so every 30 seconds. To change this behavior: # ndd -set /dev/ip ip_ire_pathmtu_interval <time> where <time> is the number of milliseconds desired between path MTU discovery attempts. 300000 milliseconds is 5 minutes. To decrease the possibility of a TCP sequence attack (i.e., TCP hijacking), the kernel value tcp_strong_iss needs to be set to 2. This can be done either through ndd directly or by changing the value of TCP_STRONG_ISS in /etc/default/inetinit to 2. Doing so causes the TCP Initial Sequence Number generation by the kernel to be a random number rather than a predictable value. ARP and ARP attacks The Address Resolution Protocol (ARP) is used to map 32-bit IP addresses to Ethernet (or hardware addresses). Every network interface in a host has a unique hardware address. Sun SPARC systems have the capability to assign a single Ethernet address to all network interfaces. This capability is achieved by having the network interface acquire its address from the PROM. ARP works by sending out an address request, usually to a subnet broadcast address, and then collecting the responses to dynamically create an Ethernet-to-IP address map. The ARP packet contains the IP address of the desired host. The response to the ARP packet, the ARP reply, contains the IP address of the desired host as well as its Ethernet address. This reply is then stored in one of two tables in the Solaris kernel: the ARP cache, maintained by the data-link layer, and a host address mapping table maintained by the network layer. When resolving hardware addresses, the ARP cache is queried first by the network layer. If the information is not available in the ARP cache, then an ARP request is broadcast. There are two types of attacks possible with ARP: denial of service [DOS] and spoofing. A DOS attack prevents one system from exchanging packets with another on the same network, whereas spoofing allows one system to masquerade as another. Both of these attacks make use of ARP's dynamic nature. ARP information may be inserted by an attacker into the ARP cache either locally, through a root compromise, or by feeding invalid replies to a system making ARP requests. Since there is no authentication at this layer, all information provided to the ARP reply is inserted into the ARP cache. This type of attack is known as ARP cache poisoning. The spoofing attack is similiar to an IP spoofing attack and relies on the "trusted host" model of security. In this case, the attacker disables the peer of the victim host, host B, and uses IP spoofing to insert the attacker's Ethernet address into host A's ARP cache, by having his system masquerade as trusted host B. Countering such an attack requires one of two procedures: 1) disable ARP resolution on host A and use only static ARP entries, or 2) flush the ARP cache as well as the IP address map often. The first option is manageable only in a small environment. Option 2 then becomes the most reasonable way to counter ARP cache poisoning. ndd can be used to change the ARP cache flush interval, as well as the IP routing table flush interval, as follows: # ndd -set /dev/arp arp_cleanup_interval <time> # ndd -set /dev/ip ip_ire_cleanup_interval <time> In this example, <time> is the interval specified in milliseconds. Although this will not eliminate these types of attacks, it may slow the attacker down. Securing IP IP is the protocol that provides connectionless and unreliable delivery of data from one machine to another. Solaris provides many kernel parameters that can be adjusted to provide a more secure system. The default Solaris installation permits IP forwarding whether the system has two or more interfaces or not. The following command can be used to disable this feature while the system is running: # ndd -set /dev/ip ip_forwarding 0 To ensure that forwarding upon subsequent reboot is disabled, this command may be used in a initialization script, or the file /etc/notrouter must exist. Another problem with multihomed systems is that an attacker may try to spoof packets coming in from one interface so that they appear to have originated from a different interface. If the system is multihomed and non-forwarding, the attacker may try to send packets to an interface with a destination address in a network attached to a different interface. The following command prevents this problem by requiring all packets entering an interface to have originated from a network attached to that interface: # ndd -set /dev/ip ip_strict_dst_multihoming 1 Solaris has many more TCP/IP stack parameters that can be configured to provide more security. Many of these parameters are covered in the included secureip shell program. ipfilter Although reducing the possibility that an attacker can use a TCP stack fingerprint to identify the operating system is a step in the right direction, another option to use is the freely available packer filter program ipfilter. ipfilter runs on Solaris 2.5.1, 2.6, 7, and 8. There is even a 64-bit version of ipfilter for those systems installed with 64-bit Solaris. Compiling ipfilter for Solaris is easy, and it installs as a Solaris package. To compile and install ipfilter: #cd ip_fil3.4.3 #make solaris #make package Configuring ipfilter is fairly straightforward and has been covered in Michael Lucas' article "FreeBSD Firewall Tools and Techniques" in the June issue of Sys Admin. A sample ipfilter configuration file is provided in Listing 3. In this configuration, the machine is providing inbound secure shell services as well as a secure Web server. Allowed UDP traffic includes syslog messages as well as SNMP traps, and SNMP information from external devices. The only ICMP traffic permitted is echo-reply, destination-unreachable, and ttl-exceeded. This configuration provides a simple starting framework when using ipfilter to protect a Solaris host. PortSentry Another useful tool to use with ipfilter (or on its own) is PortSentry. This program monitors probes to a defined subset of ports on a system. If enough probes occur to trigger a response, PortSentry blocks the source of the portscan by installing a static route into the system routing table, which sends all future packets from that source to a routing "dead end". If used in conjunction with ipfilter, PortSentry can add a blocking rule to the ipfilter ruleset. PortSentry is configurable to the extent that it can be made to work with various firewall systems including Gauntlet and Checkpoint. For PortSentry to work with ipfilter, a shell program is needed to add the new deny rule to the ruleset in the proper place. The source to the shell program is given in Listing 4. PortSentry can be downloaded from: We’re sorry this page is no longer available Logs An aspect to consider when securing a system is the logs produced by syslog. Unfortunately, by default Solaris tends to lump many things into /var/adm/messages and /var/log/syslog -- so much so that it becomes difficult, if not impossible, to easily determine what is going on in a system. The first step is to separate much of the information that is logged through syslog. One way to achieve this goal is to reconfigure syslog to log messages to separate files based on syslog facility. All kernel messages would be written to a logfile called /var/log/kernel.log; all daemon messages would be written to a file called /var/log/daemon.log, etc. Furthermore, when installing sudo or tcpd, the LOCAL[0-7] facilities can be used to categorize the logs from those programs as well. A simple, improved syslog.conf might look something like Listing 5. By breaking up the logging information as much as possible, it becomes easier to discover potential problems sooner. However, even by breaking up the logs this way, the amount of information to be processed is still very great. To ease the management of the log system, the program Logcheck can be used. Logcheck parses through a user-defined set of system logs and maintains an accounting of where it last read the logs. This way, after the initial run, the systems administrator only gets a "differential" report since the last time the logs were inspected. Logcheck can be configured to ignore key phrases in a file so that certain messages are ignored. Also, it can be set to focus on various phrases such as expn or vrfy in logs from Sendmail. The main benefit of Logcheck is that it provides the systems administrator with differential reports from the various logfiles rather than long streams of log data. This makes it easier to identify a potential problem. Logcheck can be downloaded from: We’re sorry this page is no longer available Conclusion Every operating system has some unique parameters that can be used by a scanning tool, such as nmap or queso, to identify the operating system. By changing these parameters, it becomes harder for an attacker to use such scanners to identify potential targets. Furthermore, simple steps, such as removing the identity "tags" from telnetd, ftpd, and Sendmail, help reduce the amount of information provided. Without knowledge of what type of operating system is running on a target, an attacker may be less willing to try to break in and may move on to easier targets. While the solutions covered in this article are by no means exhaustive, they do provide a good starting point for securing Solaris Systems. References Noordergraaf, Alex and Keith Watson, "Solaris Operating Environment Security", Sun Blueprints. Noordergraaf, Alex and Keith Watson, "Solaris Operating Environment Network Settings for Security Security", Sun Blueprints On-Line, December 1999. Noordergraaf, Alex and Keith Watson, "Solaris Operating Environment Minimization for Security: A Simple, Reproducible and Secure Applicable Installation", Sun Blueprints. "Creating Login Banners", CIAC Information Bulletin J-043f, June 19, 1999. Spoon, Kelly, "What You Can do with tcpd", Linux Gazette, Issue 15, March 1997. IdoDubrawsky has been working with various UNIX systems since 1992, including SunOS, Solaris, HP-UX, AIX, Linux, OpenBSD, and Ultrix. He currently works as the team lead of UNIX and Network Systems at Globeset, Inc. When not working on UNIX systems, switches, or routers, he spends his spare time with his wife and 3-year-old son. He can be contacted at: ido@globeset.com.

Salut, ti-am scos avatarul, era prea mare. Bine ai venit.

Cand vine vorba de RST, nu am familie. Daca mama ar face offtopic pe forum, i-as da warn, desigur. PS: Glumeam. ( Am spus asta ca sa se prinda toti, unii se prind mai greu ).

Installing Ubuntu 9.10 Step-by-step installation tutorial with screenshots By Marius Nestor, Linux Editor 6th of November 2009, 17:38 GMT Ubuntu 9.10, also known as the Karmic Koala, arrived exactly on October 29, 2009 and is the eleventh release of Ubuntu OS. We've created the following tutorial to teach Linux newcomers how to install the Ubuntu 9.10 operating system on their personal computer. Therefore, it is addressed to people who have just heard about Ubuntu, those who have never installed Ubuntu before and want to test it, but don't know how. The tutorial will make things very simple for you, but if you get stuck somewhere in the middle of the installation and you need help, do not hesitate to use our commenting system at the end of the article! Requirements: You will need the Ubuntu 9.10 Desktop ISO image that corresponds to your hardware architecture (i386 or amd64), and which can be downloaded from here. When the download is over, burn the ISO image with your favorite CD/DVD burning application (Nero, CDBurnerXP, Roxio) on a blank CD at 8x speed. Reinsert or leave the CD in your CD/DVD-ROM device and reboot the computer in order to boot from the CD. Hit the F8, F11 or F12 key (depending on your BIOS) to select the CD/DVD-ROM as the boot device. Select your language when asked... Select the second option "Install Ubuntu," and hit the "Enter" key... Wait for the CD to load into RAM... You will see the wallpaper for a few seconds. When the installer appears, you will be able to select your native language for the entire installation process. Click the "Forward" button to continue... Where are you? The second screen will feature a map of the Earth. Upon the selection of your current location, the time for the final system will adjust accordingly. You can also select your current location from the drop down list situated at the bottom of the window. Click the "Forward" button after you have selected your desired location... Test your keyboard On the third screen, you will be able to choose a desired keyboard layout. But the default automatic selection should work for most of you. Click the "Forward" button when you have finished with the keyboard configuration... Hard disk partitioning You have four options here: 1. If you have another operating system (e.g. Windows XP) and you want a dual boot system, select the first option: "Install them side by side, choosing between them at each startup." Editor's Note: This option will ONLY appear if you have another operating system installed, such as Microsoft Windows. Remember that, after the installation, the Windows boot loader will be overwritten by the Ubuntu boot loader! 2. If you want to delete your existing operating system, or the hard drive is already empty and you want to let the installer automatically partition the hard drive for you, select the second option, "Use the entire disk." Editor's Note: This option is recommended for most users who do not have another operating system installed or who want to erase an existing one, for example Windows OS. 3. The third choice is "Use the largest continuous free space" and it will install Ubuntu 9.10 in the unpartitioned space on the selected hard drive. 4. The fourth choice is "Specify partitions manually" and it is recommended ONLY for advanced users, to create special partitions or format the hard drive with other filesystems than the default one. But it can also be used to create a /home partition, which is very useful in case of reinstalling the whole system. Here's how you do a manual partitioning with /home: - Select the "Specify partitions manually (advanced) and click the "Forward" button; - Make sure that the selected hard drive is the right one. /dev/sda is the first physical hard drive. /dev/sdb is the second hard drive in your machine. So, make sure that you know which is the one you want to format! Otherwise, you will lose ALL YOUR DATA on that hard drive; - Let's say that the selected drive is empty (no other operating system or important data on it), but it has some partitions on it. Select each one of those partitions and click the "Delete" button. After a few seconds, it will say "free space". Do this with the other partitions from the selected hard drive, until they're all deleted and you have a single "free space" line; - With the "free space" line selected, click on the "Add" button. In the new window, type 2000 in the "New partition size in megabytes" field and select the "swap area" option from the "Use as:" drop down list. Click the OK button and, in a few seconds, you'll notice a "swap" line with the specified size; - With the "free space" line selected, click on the "Add" button. In the new window, select the "Primary" option, type a value between 10,000 and 50,000 in the "New partition size in megabytes" field and select / as the "Mount point". Click the OK button and in a few seconds, you'll notice an "ext4 /" line with the specified size; - With the "free space" line selected, click on the "Add" button. In the new window, select the "Primary" option, type a value between 30,000 and 50,000 (or whatever space you have left on the drive) in the "New partition size in megabytes" field and select /home as the "Mount point." Click the OK button and, in a few seconds, you'll notice an "ext4 /home" line with the specified size. This is how your partition table should look like. If so, click the "Forward" button to continue with the installation... WARNING: Be aware that all the data on the selected hard drive or partition will be ERASED and IRRECOVERABLE. Click the "Forward" button to continue with the installation... Who are you? On this screen, you must do exactly what the title says. Fill in the fields with your real name, the name you want to use to log in on your Ubuntu OS (also known as the "username," which will be required to log in to the system), the password and the name of the computer (automatically generated, but can be overwritten). Also at this step, there's an option called "Log in automatically." If you check the box on this option, you will automatically be logged in to the Ubuntu desktop. Click the "Forward" button to continue... Are you really ready for Ubuntu? This is the final step of the installation. Here, you can select to install the boot loader on another partition or hard drive than the default one, but it is only recommended for advanced users. If someone is installing to a USB memory stick, as if it was a USB hard drive, then they should know that the installer will mess with their computer's hard disk drive MBR (thanks to Donald for the info on this one!). Therefore, click the "Advanced" button and select the correct drive (the USB stick in this case)... Click the "Install" button to start the installation process... The Ubuntu 9.10 (Karmic Koala) operating system will be installed... After approximately 10 to 18 minutes (depending on your computer's specs), a pop-up window will appear, notifying you that the installation is complete, and you'll need to restart the computer in order to use the newly installed Ubuntu operating system. Click the "Restart Now" button... The CD will be ejected; remove it and press the "Enter" key to reboot. The computer will be restarted and, in a few seconds, you will see the Ubuntu boot splash and Xsplash... At the login screen, click on your username and input your password. Click Log In or hit Enter... Have fun using Ubuntu 9.10!

Inna - Amazing . Nu numai Salam. Place Inna la mine.

Incep o noua lista, cea de deasupra s-a cam umplut. User : lamisto Nr. warn : 1 Topic : http://rstcenter.com/forum/17915-teztour-ro-semi-deface-xss.rst Post : "nu esti newbie ma , esti 1337 " Motiv : Offtopic. User : 1337 Nr. warn : 1 Topic : http://rstcenter.com/forum/17915-teztour-ro-semi-deface-xss.rst Post : "=))) " Motiv : Offtopic. User : benny_loppa Nr. warn : 1 Topic : http://rstcenter.com/forum/17915-teztour-ro-semi-deface-xss.rst Post : "1337, mda, daca si asta e deface iti tai pl" Motiv : Injurii. User : dRuNNNk Nr. warn : 3 ( Ban permanent ) Topic : http://rstcenter.com/forum/17915-teztour-ro-semi-deface-xss.rst Post : "=)) =)) " Motiv : Offtopic. User : 1337 Nr. warn : 2 Topic : http://rstcenter.com/forum/17915-teztour-ro-semi-deface-xss.rst Post : "Taimi-o daca poti ^^ " Motiv : Offtopic. User : benny_loppa Nr. warn : 2 Topic : http://rstcenter.com/forum/17911-xss-defacement.rst Post : "ce MORTII MASI E ASA DE GREU" Motiv : Limbaj inadecvat. User : DeDu Nr. warn : 1 Topic : http://rstcenter.com/forum/2996-assembly-hijacking-un-super-tutorial-despre-sql-injection-tr.rst Post : "ReUpload Plz " Motiv : "Inviat" topic vechi. User : qbert Nr. warn : 1 Topic : http://rstcenter.com/forum/17923-http-www-hack-test-com.rst Post : "prea multi 1337 pe aici " Motiv : Offtopic. User : Flubber Nr. warn : 2 Topic : http://rstcenter.com/forum/17978-py-script-helps-please.rst Post : "esti idiot?" Motiv : Injurii. User : Gwci Nr. warn : 1 Topic : http://rstcenter.com/forum/18029-ajutor-baza-de-date.rst Post : "Unde-s alea 10 posturi pt a putea face o cerere?" Motiv : Offtopic. User : eNNiLLI Nr. warn : 1 Topic : http://rstcenter.com/forum/17984-erori-internet.rst Post : "ma ajuta cineva va rog ? " Motiv : Post dublu. User : immun3 Nr. warn : 1 Topic : http://rstcenter.com/forum/18048-eroare-steam.rst Post : "C:\DOCUME~1\hitman\LOCALS~1\Temp\..." Motiv : Post dublu. User : SympleBoy22 Nr. warn : 2 Topic : http://rstcenter.com/forum/18060-shopix-ro-magazin-online.rst Post : "In semnatura scrie FAKE 1337.Tu esti autentic. " Motiv : Offtopic. User : SympleBoy22 Nr. warn : 2 Topic : http://rstcenter.com/forum/18060-shopix-ro-magazin-online.rst Post : "In semnatura scrie FAKE 1337.Tu esti autentic." Motiv : Offtopic. User : Kabron Nr. warn : 4 ( Ban permanent ) Topic : http://rstcenter.com/forum/18025-vrei-sa-fii-admin-fara-nici-o-parola.rst Post : "wow,inteligent baiat xD ( sper ca intelegi ...) " Motiv : Offtopic. User : nosferatu Nr. warn : 5 ( Ban permanent ) Topic : http://rstcenter.com/forum/18025-vrei-sa-fii-admin-fara-nici-o-parola.rst Post : "Bine ca iti permiti sa ironizezi lumea, fara sa iei ban " Motiv : Offtopic. User : GaByoo7 Nr. warn : 1 Topic : http://rstcenter.com/forum/11349-rst-chat.rst Post : "S-a imbolnavit" Motiv : Offtopic. User : SympleBoy22 Nr. warn : 3 ( Ban permanent ) Topic : http://rstcenter.com/forum/11349-rst-chat.rst Post : "Ce dracu mai postati ma aici" Motiv : Offtopic. User : Zolder Nr. warn : 1 Topic : http://rstcenter.com/forum/11349-rst-chat.rst Post : "Ma scuzati si pe mine pentru offtopic " Motiv : Offtopic. User : p3tru Nr. warn : 1 Topic : http://rstcenter.com/forum/18075-putin-ajutor-please.rst Post : "careva un mic raspuns plz... " Motiv : Post dublu. User : sosetutza Nr. warn : 1 Topic : http://rstcenter.com/forum/18096-decriptare-parola.rst Post : "Unde sunt cele 10 posturi?" Motiv : Offtopic. User : Tazor Nr. warn : 1 Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "Xenon, mars in mm de copil sarac. " Motiv : Injurii. User : Gwci Nr. warn : 2 Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "si totusi cei cu atata off topic? " Motiv : Offtopic. User : betamaster Nr. warn : 1 Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "dar vad ca dai cu gura ca prostul " Motiv : Injurii. User : benny_loppa Nr. warn : 3 ( Ban ) Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "offtopic:wtf e cu semnatura ta" Motiv : Offtopic. User : M4T3! Nr. warn : 1 Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "=)) ))))" Motiv : Offtopic. User : Marian Nr. warn : 1 Topic : http://rstcenter.com/forum/18121-http-cstoolz-info.rst Post : "Scz pt off..." Motiv : Offtopic. User : RoMeO Nr. warn : 1 Topic : http://rstcenter.com/forum/18166-sqli-http-www-gamebot-gr.rst Post : "Esti cumva ratat! :|" Motiv : Injurii. User : Crisis Nr. warn : 1 Topic : http://rstcenter.com/forum/18166-sqli-http-www-gamebot-gr.rst Post : "Este ratat , adica ii trebe ochelari." Motiv : Injurii. User : ActionBoy Nr. warn : 1 Topic : http://rstcenter.com/forum/1081-yahoo-messenger-file-transfer-extension-spoof.rst Post : "mai verifica inca o data. " Motiv : "Inviat" topic vechi. User : ActionBoy Nr. warn : 2 Topic : http://rstcenter.com/forum/5039-wep-wap-wireless-cracking-tool-needed.rst Post : "cain & abel - a dat gres" Motiv : Post dublu. User : Zatarra Nr. warn : 2 Topic : http://rstcenter.com/forum/18165-erori-vulnerabilitati-etc.rst Post : "Tare rau asta =))" Motiv : Offtopic. User : Drace Nr. warn : 1 Topic : http://rstcenter.com/forum/stuff-tools/6245-droguri-care-se-i-au-prin-ultrasunete-5.html Post : "imi bag p" Motiv : Limbaj inadecvat. User : Fitty Nr. warn : 3 ( Ban ) Topic : http://rstcenter.com/forum/18259-psihoteste-online.rst Post : "Credeam ca ai postat niste teste, nu tot XSS... " Motiv : Offtopic. User : Ne0h Nr. warn : 1 Motiv : Reclama la semnatura. User : Ne0h Nr. warn : 2 Topic : http://rstcenter.com/forum/18294-politia-romana.rst Post : "Nu vrei sa iti zic si cand m-am nascut?" Motiv : Offtopic. User : Ne0h Nr. warn : 2 Topic : http://rstcenter.com/forum/18294-politia-romana.rst Post : "Nu vrei sa iti zic si cand m-am nascut?" Motiv : Offtopic. User : black_death_c4t Nr. warn : 4 ( Ban ) Topic : http://rstcenter.com/forum/18295-talesofmagic-computergames-ro.rst Post : "Ce trist suna , stii cum ? " Motiv : Offtopic. User : RoMeO Nr. warn : 2 Topic : http://rstcenter.com/forum/18301-sympleboy22.rst Post : "omg, ai trait in jungla pana sa apara HB?" Motiv : Offtopic. User : SympleBoy22 Nr. warn : 4 ( Ban ) Topic : http://rstcenter.com/forum/18301-sympleboy22.rst Post : "Ioinel nu se scrie Ionel?" Motiv : Offtopic. User : dRuNNNkz0r Nr. warn : 1 Topic : http://rstcenter.com/forum/18294-politia-romana.rst Post : "ce treaba ai tu daca a folosit soft? " Motiv : Offtopic. User : vini4p Nr. warn : 1 Topic : http://rstcenter.com/forum/18294-politia-romana.rst Post : "TinKode stieee ;" Motiv : Offtopic. User : m350 Nr. warn : 1 Topic : http://rstcenter.com/forum/18312-ntldr-missing.rst Post : "multumesc virusz " Motiv : Post dublu. User : DeDu Nr. warn : 1 Topic : http://rstcenter.com/forum/18333-website-photoshop.rst Post : "nime nimic sau ati plecat la artificii " Motiv : Post dublu.

Vesnica mea intrebare adresata expertilor in SQL Injection: "Ce face acel ALL?" Daca nu sti, macar nu te mai lauda ca sti SQL Injection. Hai, treci pe Google, citeste ce e ALL-ul ala si date mare ca sti. Nu stiu de ce am o banuiala ca nu o sa stie mai nimeni, pentru ca nimeni nu invata practic MySQL, toti citesc doua tutoriale prost scrise si mai deloc explicate, in care, ca si in acest tutorial banuiesc scrie: "Pai plm, puneti la URL 'union all select' si va apare aia". Dar nu spune nici unde cum se modifica query-ul, cum arata el la inceput si ce se intampla practic. PS: Nu am citit tutorialul, dar nici nu cred ca o sa il citesc, am o banuiala ca nu o sa imi placa. Insa sincere felicitari, macar se mai ocupa cineva de ceva, mai scrie cate ceva. Mai toti doar intra pe forumuri, si se opresc la topicurile stupide, nimeni nu mai invata nimic dar toti sunt 1337 si nu ii poate contesta nimeni.

Hmm, nu cred ca e vreo problema. PE Bundle cred ca se foloseste pentru DLL-uri, ca sa nu primiti acele mesaje de eroare la rulare: "lalala.ocx sau lalala.dll not found". Deci nu cred ca e infectat.

Florin Salam - Sunt motor cu reactor

Voi va luati dupa puskin? PS: 04-20-2008

Din partea mea, a facut un lucru bun. Eu mi-am scanat singur Digital Keylogger, la putin timp dupa publicare. Consider folosirea acestor programe furt informational si nu sunt de acord cu ele.

madalin94: "Deci" ban. demon_zone: Nu am de ce sa iti dau ban, dar imi pare bine ca am bagat frica in voi.

Ieri mergea linkul, poate e de la serverul opensc, poate isi revine. Oricum, acolo e sursa de la care a fost inceput acest RAT.

TinKode, SympleBoy22, sa nu va mai certati, v-am schimbat eu semnaturile la amandoi. Dieliric: Bine ai venit.

Nu l-am incercat, nu stiu daca este infectat, il testati pe riscul vostru. Remote Penetration v2.2 FIX (Released: 19/8/2009) New Features: * All PHP problems have been fixed + a new theme has been implemented! * Updated Firefox Recovery * Added Internet Download Manager Recovery * Added Yahoo Messenger 8.x,9.x Recovery * Builders dark theme removed Recovery: * Trillian * Pidgin and Gaim * PaltalkScene * Digsby * Live Messenger * MSN Messenger * Yahoo Messenger 8.x,9.x (NEW) * AIM 6.xx (Private Version only) * Miranda (Private Version only) * Google Talk (Private Version only) * Firefox 2.xx - 3.xx (Updated) * IE6 * IE7 - 8 * Internet Download Manager (NEW) * Filezilla * Smart FTP * FlashFXP * CoreFTP * NO-IP * DynDNS * Outlook * CamFrog * Custom CD-Key Grabber (Input own path to key you want to grab) Icon Options: * Replace Default Icon: * Icon Hunter Main Features: * Stub / Builder made in VB6 * FUD Scantime + Runtime * All strings are encrypted, all your inputted data, (PHP url) is encrypted, and all API's that can be encrypted/called dynamically are encrypted. * No 3rd party applications used * UAC Bypass * Send info via PHP (MySQL setup)(NEW) * Output.exe requires NO dependencies. (Builder does though) * Ability to import FUD stubs * Anti-Generic Sandbox * Anti-Virtual PC, VMWare, VirtualBox * Installation options (You get the option to pick where the file drops to / where in the registry to add the startup key.) * Pick the dropped files attributes (Hidden, Read only, or System) * Option to compress with UPX * Scramble the UPX header * Added File Version Info Cloner * Fake error message * Change the Date of the outputted executable's date * Increase the files size (Add NOP bytes to the file) * Load and Save your sessions! Private Version * All of the listed features above + a unique stub that no one else has. * AIM 6.xx recovery * Miranda recovery * Google Talk recovery * Melt * Option on builder to delete, output.exe, icon. (save kbs) * No set number of CD-Key Paths (You can add as many keys as you want grabbed) PHP Login/Logs Screenshot: Download: Removed

Nu l-am incercat, nu stiu daca e infectat, il testati pe riscul vostru. Deeper 1.0 Beta5 Compiled at October 20, 2009 Dedicated To Lanny Barbie! binaryEvil Hack Hound Coded in Egypt by binaryEvil MailTo:binaryEvil@hotmail.com [screenshots] [Features] * Main: [-] DB Memory execution [-] Encrypted connection [-] All traffics are through one port [-] Multithreaded [-] User filtration [-] Broadcasting [-] Sound events * Spy: [-] Information [-] Unicode Key Logger -> OFF Keys [-] CAM Capture [-] Screen Capture [-] Clipboard Monitor [-] Password Recovery * Manage: [-] Process Manager [-] Service Manager -> Install Service -> Edit Service [-] Window Manager [-] File Manager -> File Search -> Multiple File Transfer [-] Registry Manager -> Registry Search * Tools: [-] Shell Execute [-] CMD Shell [-] Multiple Downloader [-] Power Manager [] Please report any bugs in the HackHound official support forum. Your bug reports are vital for making Deeper a robust and capable application. It is an important goal that each Deeper release be stable, crash-free, and behave itself well. "Many Eyes Make Bugs Shallow" Download: http://www.speedyshare.com/438836864.html

Nu l-am incercat, nu stiu daca este infectat, il folositi pe riscul vostru. Autor: DarkCoderSc: "Hello HH Coders and Members, i present you my Last RAT called Unremote NAT Aka SynRAT 5.0 , i will try my best to explain it in english it is a full RAT multi server ( you can control unlimited server in same time ) but not yet multi transfer files ( i will do it soon using the full Socket API to use the last socket possibility and multi thread the transfer ) that mean you need to download file 1 by 1 i put several security to prevent bug if you try to do many thing in same time but somtimes it dont work then read this carefully dont try to make several things in same time with the Sockets in the last update the only multi thread thing is the FTP Uploader . I think its the most complete RAT actualy the only bad point are the size of the Server ( tempory like i said i will totaly recode it using API for socket etc ) and that he is pure coded with ScktComp.pas then to use Multitransfer it still very buggy :s. This version publish are the old version of Unremote NAT dont forget to run the update to have the latest version ! if you have bugs dont forget to notice me in the correct threads then i will try my best to help you and fix all bugs you found . dont esit for the sugestion ! Actualy for the last update i am coding a full MSN controler i think the most complete and best control one all status blocked/online/busy/blockedOnline etc are checked and display correctly in each contact display , you will be able to block/add/remove contacts , to saw several information about the current connected MSN change status and saw personnal info . Just wait the futur updates . /!\ Thing you absolutly need to know about unremote nat is that for updates i use an automatic updater who try to connect to my web-sites ( Unrem0te or SynSecurity V 5.0 ) then dont worry if your firewall ask to open the 80 ( http ) port to autorise this connection for checking and downloading updates for more information contact me . Last thing about updates when you will download this version in HackHound.org you will get a totaly buggy version you need to update it in update manager to get the latest available version . ------------------- Author : DarkCoderSc From : France E-Mail : DarkCoderSc@unremote.org For More info about me check in the About ! ------- Client Coded in Delphi using CodeGear 2009 RAD and some inline Batch command . Server Coded in Delphi/ASM using CodeGear 2009 RAD and using some Inline batch and PHP for trace route ( for example ) ------- Heres some screeny and the download i will post the opensc screens you will see the beta 1 / beta 2 / last beta and this release screens then you will see some changes enter screens some times ( cause some are old but then you can see 90% of the whole RAT ) This RAT is powered for Windows Vista ( using some cool API specialy for vista and seven ( just few yet ) ) Working and tested on Windows 2000 , XP SP1/SP2/SP3 , Vista and Seven ! Tested and work perfectly ( server and client ) on Linux using Wine emulator no bug all working well . Test and work good on MAC OS ( the server doesnt work ) but the client work pretty well ! ( on the last MAC OS ). Anyway have fun and respect the chart about this RAT i am French in france law isnt the same of your contrys then it is publish as a legal program for education prupose and to to control your LAN network or help as team viewer your frends arroung the world its why you have a form in the server part then i am sure you will not Hack anybody =) [i know it already exists a patch to crack this security use it as your own risk and i will not be responsable of the damage you will cause!] This is only 20% of the ability of this RAT for more screens type in google Unremote NAT and browse in the google image you will see all screens about this rat theese are them the latest sreens Last thing Unremote NAT last udpate have a FTP Client in it for FTP File upload you can do several things in it , it is beta and work in Unix and Linux servers " Download: http://www.speedyshare.com/457827391.html

Nu l-am incercat, nu stiu daca este infectat, incercati pe riscul vostru. Apocalypse RAT, which is based on Institiution 2004, was recoded mostly and many Bugs were fixed. The Authors, from which some Functions were used, were named in the Credits Window. Special Thanks Goes To Aphex - Institution 2004 0.2.4 Source Very Very Big Thanks Kill3r7 - Very Very Big Thanks Shapeless Funguskid Steve10120 - Big Thanks Gareth - Big Thanks Carb0n Syntax_err 2sly SqUeEzEr DarkCoderSc - Big Thanks Snify - for Beta Test - Big Thanks Rob33n CoyoTe Bunnn Spy-Net - Help and Support - Big Thanks Counterstrikewi ErazerZ Skyweb Slayer616 Thanks. Abhe Mark James For FamFamFam Silk Icons Apocalypse Institution 2004 0.2.6 Source BASED RAT http://www.opensc.ws/rat-source/2373-institution-2004-0-2-6-source.html Download: http://www.speedyshare.com/408599651.html

Closed, revin cu warnurile daca e cazul, dar mai incolo, mi-e lene acum.