How to bypass web filters

There are several occasions where you will be at a public to bypass web filters require access to a particular website that is blocked for some reason or another. How to bypass these restrictions is a very common question, and will be covered here.

Lets pretend for a moment that the Internet is made up of 26 websites, A-Z. The web filter blocks your browser from accessing sites X-Z, but not sites A-W. Simply make the browser think youre going to A-
W. There are a variety of ways to do this:


Proxy Servers: 
This is a list of http proxies. These sites may not be up forever, so you may need to search for free http proxy or public proxy servers or other similar terms.

Proxy server lists:

• http://www.aliveproxy.com
• http://www.multiproxy.org
• http://www.publicproxyservers.com/index.html
• http://www.tehbox.com/proxy
• http://www.proxz.com
• http://www.proxy4free.com/index.html
• http://free-proxies.com

Now that you have a list of proxies, you would open IE (internet explorer) and click on Tools > Internet Options > Connections > LAN Settings > Advanced. Enter the address and port of one of the servers from the list in the proper area (http) and make sure the “use a proxy server for your LAN option is selected. Remember to replace the proxy and port at your terminal to the original when you're done.

*Note: Some proxies listed may not work, and this method may decrease your surfing speed. By trying various entries, you’ll find one that works, or works faster.

The infamous translation trick:
Go to a web page translation site and use their services to “translate a page to English thus accessing the blocked page through their trusted site.

You'll notice that several translation sites are blocked, but by using less popular ones, this method can still be effective. Here is a list of some translation services. Again, these sites may not be up forever, so you may need to search for them.

• http://babelfish.altavista.com
• http://world.altavista.com
• http://translation.langenberg.com
• http://freetranslation.com/web.thm

Url Scripting:


Url scripting is the easiest method. It works on a select few web filters and is based on the same principal as the translation trick. By typing and address like “www.yahoo.com@www.restricted_site.com the filter will not go into effect as it recognizes the trusted site (in this case yahoo.com)

Other tricks:
Simply open the command prompt and type:
Ping restricted.com ? restricted.com obviously being the restricted site
At this point you can take down the IP address (ex. 216.109.124.73) and enter it into the browser. If access to the command prompt is also restricted, see “How to bypass restrictions to get to the command prompt.” If this article has been taken from information leak, then know that it involves anything from opening the browser, selecting view > source, then saving it as X.bat and opening it to opening a folder or browser and typing in the location of cmd.exe depending on the OS. I will not go into further, as this a completely different topic.

Use https://restrictedsite.com as referring to it as a secured site may confuse the filter.

Note: These are ancient methods that many new filters defend against, but still may be applicable in your situation. If not, a little history never hurt anyone.

Web based Proxies:
Another one of the easier, yet effective methods include web based proxies. These are simple in the fact that you just enter the restricted address and surf! Some of these have some restrictions, like daily usage limits, etc but you can also use another proxy (perhaps one that sucks, like a text only) to bypass their restrictions as well. Here is a list of some:

• http://proxify.com
• http://www.anonymizer.com/index.cgi
• http://www.guardster.com/
• http://anonymouse.ws/anonwww.html
• http://www.the-cloak.com/login.html
• https://www.megaproxy.com/freesurf
• http://www.anonymizer.ru
• https://nadaily.com/cgi-bin/nph-proxyb.cgi
• http://www.userbeam.de/cgi-bin/nph-userbeam.cgi
• http://www.free2.surffreedom.com/nph-free.cgi

Proxy Programs:
There are many proxy programs that allow you to surf anonymously that are more or less based on the same topics we’ve covered here. I’ve added them just to cover the topic thoroughly:

• 
  
• http://www.hotscripts.com/Detailed/28480.html
• http://www.inetprivacy.com/a4proxy/anonymous-grc.htm
• http://www.orangatango.com/home/index.ie.html
• http://www.steganos.com
• http://www.anonymization.net ? toolbar that requires admin rights to install

Making your own CGI proxy server:

Making your own proxy server may come in handy, but I personally find that simply uploading a txt file/w a list of proxies to a free host makes for a much easier and headache free solution. If you don't know PERL, there is code out there to help you set it up. Check out these sites for more info:

http://httpbridge.sourceforge.net
http://www.jmarshall.com/tools/cgiproxy]http://www.jmarshall.com/tools/cgiproxy
http://www.manageability.org/blog/stuff/open-source-personal-proxy-servers-written-in-java/view]http://www.manageability.org/blog/stuff/op...en-in-java/view



Admin Access:
When all else fails, you can simply take over the PC and alter or delete the damn filter. This method varies according to the OS (operating system) you are dealing with. Please see Hacking Windows NT for more information. If this tutorial has been taken from information leak, then I will go as far as to say it involves booting the PC in another OS, copying the SAM file and cracking it using a program like saminside or LC5 rather than start a whole new topic within one.

About game networking

From the outside game networking seems magical: two or more players sharing a consistent experience across the network like they actually exist together in the same virtual world. But as programmers we know the truth of what is actually going on underneath is quite different from what you see. It turns out that it’s all an illusion. A massive sleight-of-hand. What you perceive as a shared reality is only an approximation unique to your own point of view and place in time.

Peer-to-Peer Lockstep

In the beginning games were networked peer-to-peer, with each each computer exchanging information with each other in a star topology. You can still see this model alive today in RTS games, and interestingly for some reason, perhaps because it was the first way – it’s still how most people think that game networking works.

The basic idea is to abstract the game into a series of turns and a set of command messages when processed at the beginning of each turn direct the evolution of the game state. For example: move unit, attack unit, construct building. All that is needed to network this is to run exactly the same set of commands and turns on each player’s machine starting from a common initial state.

Of course this is an overly simplistic explanation and glosses over many subtle points, but it gets across the basic idea of how networking for RTS games work. You can read more about this networking model here: 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond.

It seems so simple and elegant, but unfortunately there are several limitations:

First, it’s exceptionally difficult to ensure that a game is completely deterministic; that each turn plays out identically on each machine. For example, one unit could take slightly a different path on two machines, arriving sooner to a battle and saving the day on one machine, while arriving later on the other and erm. not saving the day. Like a butterfly flapping it’s wings and causing a hurricane on the other side of the world, one tiny difference results in complete desynchronization over time.

The next limitation is that in order to ensure that the game plays out identically on all machines it is necessary to wait until all player’s commands for that turn are received before simulating that turn. This means that each player in the game has latency equal to the most lagged player. RTS games typically hide this by providing audio feedback immediately and/or playing cosmetic animation, but ultimately any truly game affecting action may occur only after this delay has passed.

The final limitation occurs because of the way the game synchronizes by sending just the command messages which change the state. In order for this to work it is necessary for all players to start from the same initial state. Typically this means that each player must join up in a lobby before commencing play, although it is technically possible to support late join, this is not common due to the difficulty of capturing and transmitting a completely deterministic starting point in the middle of a live game.

Despite these limitations this model naturally suits RTS games and it still lives on today in games like “Command and Conquer”, “Age of Empires” and “Starcraft”. The reason being that in RTS games the game state consists of many thousands of units and is simply too large to exchange between players. These games have no choice but to exchange the commands which drive the evolution of the game state.

But for other genres, the state of the art has moved on. So that’s it for the deterministic peer-to-peer lockstep networking model. Now lets look at the evolution of action games starting with Doom, Quake and Unreal.

Client/Server

In the era of action games, the limitations of peer-to-peer lockstep became apparent in Doom, which despite playing well over the LAN played terribly over the internet for typical users:

Although it is possible to connect two DOOM machines together across the Internet using a modem link, the resulting game will be slow, ranging from the unplayable (e.g. a 14.4Kbps PPP connection) to the marginally playable (e.g. a 28.8Kbps modem running a Compressed SLIP driver). Since these sorts of connections are of only marginal utility, this document will focus only on direct net connections.

The problem of course was that Doom was designed for networking over LAN only, and used the peer-to-peer lockstep model described previously for RTS games. Each turn player inputs (key presses etc.) were exchanged with other peers, and before any player could simulate a frame all other player’s key presses needed to be received.

In other words, before you could turn, move or shoot you had to wait for the inputs from the most lagged modem player. Just imagine the wailing and gnashing of teeth that this would have resulted in for the sort of folks who wrote above that “these sorts of connections are of only marginal utility”.

In order to move beyond the LAN and the well connected elite at university networks and large companies, it was necessary to change the model. And in 1996, that’s exactly what John Carmack did when he released Quake using client/server instead of peer-to-peer.

Now instead of each player running the same game code and communicating directly with each other, each player was now a “client” and they all communicated with just one computer called the “server”. There was no longer any need for the game to be deterministic across all machines, because the game really only existed on the server. Each client effectively acted as a dumb terminal showing an approximation of the game as it played out on the server.

In a pure client/server model you run no game code locally, instead sending your inputs such as key presses, mouse movement, clicks to the server. In response the server updates the state of your character in the world and replies with a packet containing the state of your character and other players near you. All the client has to do is interpolate between these updates to provide the illusion of smooth movement and *BAM* you have a networked client/server game.

This was a great step forward. The quality of the game experience now depended on the connection between the client and the server instead of the most lagged peer in the game. It also became possible for players to come and go in the middle of the game, and the number of players increased as client/server reduced the bandwidth required on average per-player.

But there were still problems with the pure client/server model:

While I can remember and justify all of my decisions about networking from DOOM through Quake, the bottom line is that I was working with the wrong basic assumptions for doing a good internet game. My original design was targeted at < 200ms connection latencies. People that have a digital connection to the internet through a good provider get a pretty good game experience. Unfortunately, 99% of the world gets on with a slip or ppp connection over a modem, often through a crappy overcrowded ISP. This gives 300+ ms latencies, minimum. Client. User's modem. ISP's modem. Server. ISP's modem. User's modem. Client. God, that sucks.

Ok, I made a bad call. I have a T1 to my house, so I just wasn't familliar with PPP life. I'm addressing it now.

The problem was of course latency.

What John did next when he released QuakeWorld would change the industry forever.

Client-Side Prediction

In the original Quake you felt the latency between your computer and the server. Press forward and you’d wait however long it took for packets to travel to the server and back to you before you’d actually start moving. Press fire and you wait for that same delay before shooting.

If you’ve played any modern FPS like Call of Duty: Modern Warfare, you know this is no longer what happens. So how exactly do modern FPS games seem to remove the latency on your own actions in multiplayer?

This problem was historically solved in two parts. The first part was client-side prediction of movement developed by John Carmack for QuakeWorld, and later incorporated as part of Unreal’s networking model by Tim Sweeney. The second part was latency compensation developed by Yahn Bernier at Valve for Counterstrike. In this section we’ll focus on that first part – hiding the latency on player movement.

When writing about his plans for the soon to be released QuakeWorld, John Carmack said:

I am now allowing the client to guess at the results of the users movement until the authoritative response from the server comes through. This is a biiiig architectural change. The client now needs to know about solidity of objects, friction, gravity, etc. I am sad to see the elegant client-as-terminal setup go away, but I am practical above idealistic.

So now in order to remove the latency, the client runs more code than it previously did. It is no longer a dumb terminal sending inputs to the server and interpolating between state sent back. Instead it is able to predict the movement of your character locally and immediately in response to your input, running a subset of the game code for your player character on the client machine.

Now as soon as you press forward, there is no wait for a round trip between client and server – your character start moving forward right away.

The difficulty of this approach is not in the prediction, for the prediction works just as normal game code does – evolving the state of the game character forward in time according to the player’s input. The difficulty is in applying the correction back from the server to resolve cases when the client and server disagree about where the player character should be and what it is doing.

Now at this point you might wonder. Hey, if you are running code on the client – why not just make the client authoritative over their player character? The client could run the simulation code for their own character and simply tell the server where they are each time they send a packet. The problem with this is that if each player were able to simply tell the server “here is my current position” it would be trivially easy to hack the client such that a cheater could instantly dodge the RPG about to hit them, or teleport instantly behind you to shoot you in the back.

So in FPS games it is absolutely necessary that the server is the authoritative over the state of each player character, in-spite of the fact that each player is locally predicting the motion of their own character to hide latency. As Tim Sweeney writes in The Unreal Networking Architecture: “The Server Is The Man”.

Here is where it gets interesting. If the client and the server disagree, the client must accept the update for the position from the server, but due to latency between the client and server this correction is necessarily in the past. For example, if it takes 100ms from client to server and 100ms back, then any server correction for the player character position will appear to be 200ms in the past, relative to the time up to which the client has predicted their own movement.

If the client were to simply apply this server correction update verbatim, it would yank the client back in time such that the client would completely undo any client-side prediction. How then to solve this while still allowing the client to predict ahead?

The solution is to keep a circular buffer of past character state and input for the local player on the client, then when the client receives a correction from the server, it first discards any buffered state older than the corrected state from the server, and replays the state starting from the corrected state back to the present “predicted” time on the client using player inputs stored in the circular buffer. In effect the client invisibly “rewinds and replays” the last n frames of local player character movement while holding the rest of the world fixed.

This way the player appears to control their own character without any latency, and provided that the client and server character simulation code is deterministic – giving exactly the same result for the same inputs on the client and server – it is rarely corrected. It is as Tim Sweeney describes:

… the best of both worlds: In all cases, the server remains completely authoritative. Nearly all the time, the client movement simulation exactly mirrors the client movement carried out by the server, so the client’s position is seldom corrected. Only in the rare case, such as a player getting hit by a rocket, or bumping into an enemy, will the client’s location need to be corrected.

In other words, only when the player’s character is affected by something external to the local player’s input, which cannot possibly be predicted on the client, will the player’s position need to be corrected. That and of course, if that player is attempting to cheat

Configuring Bulletproof FTP Server

Configuring your Bulletproof FTP Server Tutorial

I thought that perhaps this tutorial might be pretty helpful for those interested in knowing how to configure their Bulletproof FTP Server that don't already know how... Here's how to get started…

This is for the Bulletproof FTP Server 2.10. However, It should work fine on most following versions as well.

I'm assuming you have it installed and cracked.

Basics
1. Start the program.
2. Click on Setup > Main > General from the pull-down menu.
3. Enter your server name into the 'Server Name' box. Under Connection set the “Max number of users" to any number. This is the limit as to how many users can be on your sever at any time.
4. Click on the 'options' tab of that same panel (on the side)
5. Look at the bottom, under IP Options. Put a check in the box “Refuse Multiple Connections from the same IP”. This will prevent one person from blocking your FTP to others.
6. Also put a check in the 'Blocked Banned IP (instead of notifying client). VERY IMPORTANT! If somebody decides to 'Hammer' (attempt to login numerous times VERY quickly) your server/computer may CRASH if you don't enable this.
7. Click on the 'advanced' tab
8. At the bottom again look at the 'hammering area'
9. Enable 'anti-hammer' and 'do not reply to people hammering' Set it for the following: Block IP 120 min if 5 connections in 60 sec. You can set this at whatever you want to but that is pretty much a standard Click 'OK'

Adding Users
11. Setup > User accounts form pull-down.
12. Right click in the empty 'User Accounts' area on the right: choose 'Add'
13. Enter account name. (ie: logon name)
14. In the 'Access rights' box right click: choose ‘Add’.
15. Browse until you find the directory (folder) you want to share. In the right column you will see a bunch of checkboxes. Put a check in the following ones: Read, Write, Append, Make, List, and +Subdirs. Press 'select'.
16. Enter a password for your new FTP account.
17. Click on 'Miscellaneous' in the left column. Make sure 'Enable Account' is selected. Enable 'Max Number of Users' set it at a number other than zero. 1 for a personal account and more that one for a group account. Enable 'Max. no. of connects per IP' set it at 1

18. Under 'Files' enable 'show relative path' this is a security issue. A FTP client will now not be able to see the ENTIRE path of the FTP. It will only see the path from the main directory. Hide hidden flies as well.
Put a tick in both of these.

Advanced:
You don't need to do any of this stuff, but It will help tweak your server and help you maintain order on it. All of the following will be broken down into small little areas that will tell you how to do one thing at a time.

Changing the Port
The default port is always 21, but you can change this. Many ISPs will routinely do a scan of its own users to find a ftp server, also when people scan for pubs they may scan your IP, thus finding your ftp server. If you do decide to change it many suggest that you make the port over 10,000.
1. Setup > Main > General
2. In the 'Connection' Area is a setting labeled 'Listen on Port Number:'
3. Make it any number you want. That will be your port number.
4. Click 'OK'

Making an 'Upload Only' or 'Download Only' ftp server.
This is for the entire SERVER, not just a user.
1. Setup > Main > Advanced
2. In the advanced window you will have the following options: uploads and downloads, downloads only, and uploads only. By default upload and download will be checked. Change it to whatever you want.
3. Click 'OK’


While you are running your server, usually you will end up spending more time at your computer than you normally do. Don't be afraid to ban IP's. Remember, on your FTP you do as you want.

When you are online you must also select the open server button next to the on-line button which is the on-line Button

You also have to use the actual Numbered ip Address ie: 66.250.216.67

Or even Better yet, get a no-ip.com address

Leave your comments for better review

Setting Up A Ftp

 Setting Up A Ftp

Well, since many of us have always wondered this, here it is. Long and drawn out. Also, before attempting this, realize one thing; You will have to give up your time, effort, bandwidth, and security to have a quality ftp server.

That being said, here it goes. First of all, find out if your IP (Internet Protocol) is static (not changing) or dynamic (changes everytime you log on). To do this, first consider the fact if you have a dial up modem. If you do, chances are about 999 999 out of 1 000 000 that your IP is dynamic. To make it static, just go to a place like h*tp://www.myftp.org/ to register for a static ip address.

You'll then need to get your IP. This can be done by doing this:

Going to Start -> Run -> winipcfg or www.ask.com and asking 'What is my IP?'

After doing so, you'll need to download an FTP server client. Personally, I'd recommend G6 FTP Server, Serv-U FTPor Bullitproof v2.15 all three of which are extremely reliable, and the norm of the ftp world.

You can download them on this site: h*tp://www.liaokai.com/softw_en/d_index.htm

First, you'll have to set up your ftp. For this guide, I will use step-by-step instructions for G6. First, you'll have to go into 'Setup -> General'. From here, type in your port # (default is 21). I recommend something unique, or something a bit larger (ex: 3069). If you want to, check the number of max users (this sets the amount of simultaneous maximum users on your server at once performing actions - The more on at once, the slower the connection and vice versa).

The below options are then chooseable:

-Launch with windows

-Activate FTP Server on Start-up

-Put into tray on startup

-Allow multiple instances

-Show "Loading..." status at startup

-Scan drive(s) at startup

-Confirm exit

You can do what you want with these, as they are pretty self explanatory. The scan drive feature is nice, as is the 2nd and the last option. From here, click the 'options' text on the left column.

To protect your server, you should check 'login check' and 'password check', 'Show relative path (a must!)', and any other options you feel you'll need. After doing so, click the 'advanced' text in the left column. You should then leave the buffer size on the default (unless of course you know what you're doing ), and then allow the type of ftp you want.

Uploading and downloading is usually good, but it's up to you if you want to allow uploads and/or downloads. For the server priority, that will determine how much conventional memory will be used and how much 'effort' will go into making your server run smoothly.

Anti-hammering is also good, as it prevents people from slowing down your speed. From here, click 'Log Options' from the left column. If you would like to see and record every single command and clutter up your screen, leave the defaults.

But, if you would like to see what is going on with the lowest possible space taken, click 'Screen' in the top column. You should then check off 'Log successful logins', and all of the options in the client directry, except 'Log directory changes'. After doing so, click 'Ok' in the bottom left corner.

You will then have to go into 'Setup -> User Accounts' (or ctrl & u). From here, you should click on the right most column, and right click. Choose 'Add', and choose the username(s) you would like people to have access to.

After giving a name (ex: themoonlanding), you will have to give them a set password in the bottom column (ex: wasfaked). For the 'Home IP' directory, (if you registered with a static server, check 'All IP Homes'. If your IP is static by default, choose your IP from the list. You will then have to right click in the very center column, and choose 'Add'.

From here, you will have to set the directory you want the people to have access to. After choosing the directory, I suggest you choose the options 'Read', 'List', and 'Subdirs', unless of course you know what you're doing . After doing so, make an 'upload' folder in the directory, and choose to 'add' this folder seperately to the center column. Choose 'write', 'append', 'make', 'list', and 'subdirs'. This will allow them to upload only to specific folders (your upload folder).

Now click on 'Miscellaneous' from the left column. Choose 'enable account', your time-out (how long it takes for people to remain idle before you automatically kick them off), the maximum number of users for this name, the maximum number of connections allowed simultaneously for one ip address, show relative path (a must!), and any other things at the bottom you'd like to have. Now click 'Ok'.

**Requested**

From this main menu, click the little boxing glove icon in the top corner, and right click and unchoose the hit-o-meter for both uploads and downloads (with this you can monitor IP activity). Now click the lightning bolt, and your server is now up and running.

Post your ftp info, like this:

213.10.93.141 (or something else, such as: 'f*p://example.getmyip.com')

User: *** (The username of the client)

Pass: *** (The password)

Port: *** (The port number you chose)

So make a FTP and join the FTP section

Listing The Contents Of A Ftp:

Listing the content of a FTP is very simple.

You will need FTP Content Maker, which can be downloaded from here:

ht*p://www.etplanet.com/download/application/FTP%20Content%20Maker%201.02.zip

1. Put in the IP of the server. Do not put "ftp://" or a "/" because it will not work if you do so.

2. Put in the port. If the port is the default number, 21, you do not have to enter it.

3. Put in the username and password in the appropriate fields. If the login is anonymous, you do not have to enter it.

4. If you want to list a specific directory of the FTP, place it in the directory field. Otherwise, do not enter anything in the directory field.

5. Click "Take the List!"

6. After the list has been taken, click the UBB output tab, and copy and paste to wherever you want it.

If FTP Content Maker is not working, it is probably because the server does not utilize Serv-U Software.

If you get this error message:

StatusCode = 550

LastResponse was : 'Unable to open local file test-ftp'

Error = 550 (Unable to open local file test-ftp)

Error = Unable to open local file test-ftp = 550

Close and restart FTP Content Maker, then try again.

error messages:

110 Restart marker reply. In this case, the text is exact and not left to the particular implementation; it must read: MARK yyyy = mmmm Where yyyy is User-process data stream marker, and mmmm server's equivalent marker (note the spaces between markers and "=").

120 Service ready in nnn minutes.

125 Data connection already open; transfer starting.

150 File status okay; about to open data connection.

200 Command okay.

202 Command not implemented, superfluous at this site.

211 System status, or system help reply.

212 Directory status.

213 File status.

214 Help message. On how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user.

215 NAME system type. Where NAME is an official system name from the list in the Assigned Numbers document.

220 Service ready for new user.

221 Service closing control connection. Logged out if appropriate.

225 Data connection open; no transfer in progress.

226 Closing data connection. Requested file action successful (for example, file transfer or file abort).

227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).

230 User logged in, proceed.

250 Requested file action okay, completed.

257 "PATHNAME" created.

331 User name okay, need password.

332 Need account for login.

350 Requested file action pending further information.

421 Too many users logged to the same account

425 Can't open data connection.

426 Connection closed; transfer aborted.

450 Requested file action not taken. File unavailable (e.g., file busy).

451 Requested action aborted: local error in processing.

452 Requested action not taken. Insufficient storage space in system.

500 Syntax error, command unrecognized. This may include errors such as command line too long.

501 Syntax error in parameters or arguments.

502 Command not implemented.

503 Bad sequence of commands.

504 Command not implemented for that parameter.

530 Not logged in.

532 Need account for storing files.

550 Requested action not taken. File unavailable (e.g., file not found, no access).

551 Requested action aborted: page type unknown.

552 Requested file action aborted. Exceeded storage allocation (for current directory or dataset).

553 Requested action not taken. File name not allowed.

 Active FTP vs. Passive FTP, a Definitive Explanation

Introduction

One of the most commonly seen questions when dealing with firewalls and other Internet connectivity issues is the difference between active and passive FTP and how best to support either or both of them. Hopefully the following text will help to clear up some of the confusion over how to support FTP in a firewalled environment.

This may not be the definitive explanation, as the title claims, however, I've heard enough good feedback and seen this document linked in enough places to know that quite a few people have found it to be useful. I am always looking for ways to improve things though, and if you find something that is not quite clear or needs more explanation, please let me know! Recent additions to this document include the examples of both active and passive command line FTP sessions. These session examples should help make things a bit clearer. They also provide a nice picture into what goes on behind the scenes during an FTP session. Now, on to the information...

The Basics

FTP is a TCP based service exclusively. There is no UDP component to FTP. FTP is an unusual service in that it utilizes two ports, a 'data' port and a 'command' port (also known as the control port). Traditionally these are port 21 for the command port and port 20 for the data port. The confusion begins however, when we find that depending on the mode, the data port is not always on port 20.

Active FTP

In active mode FTP the client connects from a random unprivileged port (N > 1024) to the FTP server's command port, port 21. Then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server will then connect back to the client's specified data port from its local data port, which is port 20.

From the server-side firewall's standpoint, to support active mode FTP the following communication channels need to be opened:

FTP server's port 21 from anywhere (Client initiates connection)

FTP server's port 21 to ports > 1024 (Server responds to client's control port)

FTP server's port 20 to ports > 1024 (Server initiates data connection to client's data port)

FTP server's port 20 from ports > 1024 (Client sends ACKs to server's data port)

In step 1, the client's command port contacts the server's command port and sends the command PORT 1027. The server then sends an ACK back to the client's command port in step 2. In step 3 the server initiates a connection on its local data port to the data port the client specified earlier. Finally, the client sends an ACK back as shown in step 4.

The main problem with active mode FTP actually falls on the client side. The FTP client doesn't make the actual connection to the data port of the server--it simply tells the server what port it is listening on and the server connects back to the specified port on the client. From the client side firewall this appears to be an outside system initiating a connection to an internal client--something that is usually blocked.

Active FTP Example

Below is an actual example of an active FTP session. The only things that have been changed are the server names, IP addresses, and user names. In this example an FTP session is initiated from testbox1.slacksite.com (192.168.150.80), a linux box running the standard FTP command line client, to testbox2.slacksite.com (192.168.150.90), a linux box running ProFTPd 1.2.2RC2. The debugging (-d) flag is used with the FTP client to show what is going on behind the scenes. Everything in red is the debugging output which shows the actual FTP commands being sent to the server and the responses generated from those commands. Normal server output is shown in black, and user input is in bold.

There are a few interesting things to consider about this dialog. Notice that when the PORT command is issued, it specifies a port on the client (192.168.150.80) system, rather than the server. We will see the opposite behavior when we use passive FTP. While we are on the subject, a quick note about the format of the PORT command. As you can see in the example below it is formatted as a series of six numbers separated by commas. The first four octets are the IP address while the second two octets comprise the port that will be used for the data connection. To find the actual port multiply the fifth octet by 256 and then add the sixth octet to the total. Thus in the example below the port number is ( (14*256) + 178), or 3762. A quick check with netstat should confirm this information.

testbox1: {/home/p-t/slacker/public_html} % ftp -d testbox2

Connected to testbox2.slacksite.com.

220 testbox2.slacksite.com FTP server ready.

Name (testbox2:slacker): slacker

---> USER slacker

331 Password required for slacker.

Password: TmpPass

---> PASS XXXX

230 User slacker logged in.

---> SYST

215 UNIX Type: L8

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> ls

ftp: setsockopt (ignored): Permission denied

---> PORT 192,168,150,80,14,178

200 PORT command successful.

---> LIST

150 Opening ASCII mode data connection for file list.

drwx------ 3 slacker users 104 Jul 27 01:45 public_html

226 Transfer complete.

ftp> quit

---> QUIT

221 Goodbye.

Passive FTP

In order to resolve the issue of the server initiating the connection to the client a different method for FTP connections was developed. This was known as passive mode, or PASV, after the command used by the client to tell the server it is in passive mode.

In passive mode FTP the client initiates both connections to the server, solving the problem of firewalls filtering the incoming data port connection to the client from the server. When opening an FTP connection, the client opens two random unprivileged ports locally (N > 1024 and N+1). The first port contacts the server on port 21, but instead of then issuing a PORT command and allowing the server to connect back to its data port, the client will issue the PASV command. The result of this is that the server then opens a random unprivileged port (P > 1024) and sends the PORT P command back to the client. The client then initiates the connection from port N+1 to port P on the server to transfer data.

From the server-side firewall's standpoint, to support passive mode FTP the following communication channels need to be opened:

FTP server's port 21 from anywhere (Client initiates connection)

FTP server's port 21 to ports > 1024 (Server responds to client's control port)

FTP server's ports > 1024 from anywhere (Client initiates data connection to random port specified by server)

FTP server's ports > 1024 to remote ports > 1024 (Server sends ACKs (and data) to client's data port)

In step 1, the client contacts the server on the command port and issues the PASV command. The server then replies in step 2 with PORT 2024, telling the client which port it is listening to for the data connection. In step 3 the client then initiates the data connection from its data port to the specified server data port. Finally, the server sends back an ACK in step 4 to the client's data port.

While passive mode FTP solves many of the problems from the client side, it opens up a whole range of problems on the server side. The biggest issue is the need to allow any remote connection to high numbered ports on the server. Fortunately, many FTP daemons, including the popular WU-FTPD allow the administrator to specify a range of ports which the FTP server will use. See Appendix 1 for more information.

The second issue involves supporting and troubleshooting clients which do (or do not) support passive mode. As an example, the command line FTP utility provided with Solaris does not support passive mode, necessitating a third-party FTP client, such as ncftp.

With the massive popularity of the World Wide Web, many people prefer to use their web browser as an FTP client. Most browsers only support passive mode when accessing ftp:// URLs. This can either be good or bad depending on what the servers and firewalls are configured to support.

Passive FTP Example

Below is an actual example of a passive FTP session. The only things that have been changed are the server names, IP addresses, and user names. In this example an FTP session is initiated from testbox1.slacksite.com (192.168.150.80), a linux box running the standard FTP command line client, to testbox2.slacksite.com (192.168.150.90), a linux box running ProFTPd 1.2.2RC2. The debugging (-d) flag is used with the FTP client to show what is going on behind the scenes. Everything in red is the debugging output which shows the actual FTP commands being sent to the server and the responses generated from those commands. Normal server output is shown in black, and user input is in bold.

Notice the difference in the PORT command in this example as opposed to the active FTP example. Here, we see a port being opened on the server (192.168.150.90) system, rather than the client. See the discussion about the format of the PORT command above, in the Active FTP Example section.

testbox1: {/home/p-t/slacker/public_html} % ftp -d testbox2

Connected to testbox2.slacksite.com.

220 testbox2.slacksite.com FTP server ready.

Name (testbox2:slacker): slacker

---> USER slacker

331 Password required for slacker.

Password: TmpPass

---> PASS XXXX

230 User slacker logged in.

---> SYST

215 UNIX Type: L8

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> passive

Passive mode on.

ftp> ls

ftp: setsockopt (ignored): Permission denied

---> PASV

227 Entering Passive Mode (192,168,150,90,195,149).

---> LIST

150 Opening ASCII mode data connection for file list

drwx------ 3 slacker users 104 Jul 27 01:45 public_html

226 Transfer complete.

ftp> quit

---> QUIT

221 Goodbye.

Summary

The following chart should help admins remember how each FTP mode works:

Active FTP :

command : client >1024 -> server 21

data : client >1024 <- server 20

Passive FTP :

command : client >1024 -> server 21

data : client >1024 -> server >1024

A quick summary of the pros and cons of active vs. passive FTP is also in order:

Active FTP is beneficial to the FTP server admin, but detrimental to the client side admin. The FTP server attempts to make connections to random high ports on the client, which would almost certainly be blocked by a firewall on the client side. Passive FTP is beneficial to the client, but detrimental to the FTP server admin. The client will make both connections to the server, but one of them will be to a random high port, which would almost certainly be blocked by a firewall on the server side.

Luckily, there is somewhat of a compromise. Since admins running FTP servers will need to make their servers accessible to the greatest number of clients, they will almost certainly need to support passive FTP. The exposure of high level ports on the server can be minimized by specifying a limited port range for the FTP server to use. Thus, everything except for this range of ports can be firewalled on the server side. While this doesn't eliminate all risk to the server, it decreases it tremendously.

Create Your Own Online Proxy Server

How To Create Your Own Online Proxy Server In Minutes

I had quite a lot of trouble last week with a company’s browsing restrictions. It used an extensive directory of ‘forbidden websites’ that kept out all but a few popular sites. In effect, no games sites, no personal email, and no MakeUseOf.
None of the conventional proxy servers worked, and even Google Translate failed. My hopes were down until, yesterday, I discovered that one of my personal domains could be accessed.
Back on my home computer, in a matter of minutes, I had set up my own functioning proxy server. With the instructions below, so can you.

Prerequisites
If we want to pull this off there are a few things you need.

Web Host
In theory, any webhost will do, if they comply with the other requirements; an old computer in your basement, or even a free online webhost.

PHP5 or greater and cURL
Look for this on the website of your webhost. If it’s paid hosting, you can almost count on it. Especially cURL is a feature that’ll be disabled on most free webservers.

Permission
That’s right. Some webhosts will explicitly forbid you to create a proxy server (or a chat room, for that matter) in their terms of content. And you can expect them to find out.

1. Download and Install GlypeProxy

GlypeProxy is a free, standalone PHP script. That means it’s lightweight and incredibly easy to configure. You can download it from their website.
Next, upload the files to a sub directory on your webserver. If you see a folder called ‘www’, or called after your domain name (e.g. domain.com) create the sub folder in there. You need to avoid using the word ‘proxy’, because some companies pick up on it. Instead, use ‘web’ or ‘surf’.
There are a few different ways to upload your files. If you already know this, skip to the next paragraph. Here they are arranged from the least to the most effort.
Upload and unpack ZIP
Look in the filemanager for an ‘unpack’ or ‘extract’ option. You can then upload it in one take. This is not always supported.
FTP access
Use an FTP application to access your webhost, and let it transfer the files while you fetch some more coffee. Most often supported.
Manual upload
You really don’t want to do this – are you sure the previous two alternatives are blanked out? Your last resolve will be to manually upload all the files and folder structures. Or start looking for a different host – it might not be such a bad idea.

2. Ready For Use

There’s no real set-up needed. Just point your browser to the directory where you put all those files (ex. domain.com/surf) and GlypeProxy will pop up. If you don’t like the logo, you’ll have to replace it manually. But if you want a proxy server for personal use, some little branding won’t matter.
Users can enter any URL and, after expanding the options, choose to encode the URL, the page, allow cookies, scripts and objects. Encoding the page can help you access some sites that are still being picked up and intercepted, but might give you a corrupt webpage at times.

3. Admin Preferences

Although Glype is a powerful proxy script, the admin tools are obviously the backing power. You might not know this, but a lot of online proxy tools are powered by Glype, just like the one you just set up. The admin preferences leave room not only for customization, but for improvement. You can assign site-specific code for trouble-giving websites, and change user-agent and proxy lists.
Most useful to novice users will be the caching tools (pictured above), logs, and blacklists. The caching tools can help you improve the browsing speed by storing some files from all, or some of the already visited websites. Logs are off by default, but might have legal importance in the future, depending on who uses your proxy server. Always explicitly mention you’re keeping these logs. Finally, the blacklists will allow you to block (all but) a few sites, or users.
To access your admin panel, point your browser to admin.php on your webserver (e.g. domain.com/surf/admin.php).
Are you setting up your own personal proxy server? Do you have any other tips or experiences on the issue? Let us know in the comments below!

Why You Should Make Your Own Server

Why You Should Make Your Own Server

You’ve probably heard at some point that servers aren’t only for those that have a lot of money. In fact, anyone who has a spare box sitting around somewhere in their house can have their very own server, slaving away at whatever whims you may have. Although it sounds very cool, it does take some effort and a little know-how to get it all set up.

So, before you get all sad and throw that spare box in the dump, here are five reasons why you should take the effort into making your own server.

1. You Control Your Data

If you’re an avid user of the Web, you probably have all kinds of information spread out over multiple servers and websites. For example, chances are you use Dropbox. Although it’s extremely convenient, your files are ultimately stored on their servers, so that means they control your data. You can protect yourself through different methods of encryption, but the storage location stays the same. You can change that by setting up your own server to hold your data. That way, what’s yours stays yours, and it will stay that way as long as you run your own server. With good security, other prying eyes won’t be able to see what you’re storing on your own server, so privacy is included.

2. You Build Your Own Services

With your own server, you can do whatever you want with it. Run an email server to handle all your email (although saying goodbye to Gmail would probably be the hardest thing known to a geek), a proxy, FTP server, and many other combinations. You could even run your own version of Dropbox with enough help, or create your very own services that you may be in need of. The possibilities are endless, and you get to choose.

3. No Surprises

Since you’re in control (this is pretty much the main idea), there won’t (or at least shouldn’t) be any surprises when it comes to your server. Aside from the small possibility of hardware failure, nothing in terms of the services that your server offers should suddenly change without you doing anything. While third party services may change the way their services or products work, yours won’t. You configure it to exactly how you want it, and then it stays that way until you change it again to meet your needs.

4. Have Fun With Your Server

In the spirit of control and adding whatever you please, why not install some game servers in the meantime? There are so many different games such as Minecraft and Urban Terror that have software for servers that you can run to host your very own games. These games can have their own rules and customizations, making it even more fun for you and all your friends. Again, the possibilities are endless, and you can run as many different game servers as your RAM will hold and your CPU can handle.

5. It’s Pretty Inexpensive

The costs of running a server are actually pretty insignificant, especially when you don’t need it at all times of the day. Your server will more than likely need to be connected to the Internet, but unless your regular Internet connection has major limitations that can’t let you successfully run your server on that connection, you can use the Internet connection that you’re using for your desktop or laptop right now. You can also get a free DNS name from a few different places like DynDNS if you don’t have a lot of needs for your server so that you can connect to your server without having to remember an IP address that might change occasionally.
The software should be free in most cases, and the operating system will more than likely be Linux (it’s recommended, anyways), so no costs will appear there. In the end, it’s really just the cost of electricity, which can be managed if say the server doesn’t have to be on while you’re asleep.
Conclusion
Running your own server brings many advantages that could make your life a lot easier and less stressful. After all the work in getting it set up, you can pride yourself in the fact that you have your very own server that you can do whatever you want with. In the end, it should be well worth it, with a spare box well used. If not, you can always check out this MakeUseOf guide to giving that old box new life.