Re: Ping: stingray



stingray@xxxxxxxxxxxxxxxx wrote:

Borked Pseudo Mailed wrote:
stingray@xxxxxxxxxxxxxxxx wrote:


well, you can try to setup for example ftp on some remote box, or ask a
friend, make it listen on port 80. Then you try to ftp from your own box
to that ftp on port 80. If it works then most likely the filtering is
only done on ports and not on the contents/protocols.


This would be a very poor test at best. FTP typically requires two ports
to function, and would very likely fail in this scenario, giving false
results if simple port filtering is being used. FTP is absolutely the
worst suggestion you could have made as far as protocols go.

A better test would be to have someone set up a telnet or other type of
daemon to listen on port 80, then using raw telnet to test it. Or even
using any of the various free HTTP proxies to do similar "tunneling"
tests. Or, have someone set up a lightweight web server like thttpd on a
port you believe is blocked, and try to browse to that (an even better
test in my opinion).

FWIW, situations where protocols themselves are filtered are very rare.
It's rather hard to do that sort of "content" filtering reliably. 99.99%
of the time it's nothing more than ports, or ranges of ports that are
blocked. And if you do happen to run into this sort of filtering the
"HTTP to odd ports" test will tell you that's what you're dealing with
instantly.


Well, i disagree there, although it's only one of the many things he can

You may disagree all you like, but you'll still be wrong. It's pretty
common knowledge among informed people that FTP is *not* the tool to use
when testing things like this. I don't know if you don't quite grasp how
FTP works, or (more likely) how this sort of filtering is basically white
listing of ports, but for whatever reason you're again offering up
erroneous information and trying to defend it after it's been pointed out
to you why you're in error.

Once again, the correct way to "map out" blocked ports is to use known
acceptable protocols on various ports and try to make the most basic
connection you can. This will almost always be either telnet, or in some
cases simple SYN/ACK/RST connection negotiations with a tool like nmap or
netcat.

FTP is an absolutely horrible tool to use for this sort of testing. It
adds an additional and prominent set of failure conditions. It's just not
going to be reliable enough to be at all useful. Simple as that.











.



Relevant Pages

  • Re: Newbie question about ports.
    ... Can you do a CVSup to update your ports via http? ... Cvsup does not support http, but neither does it use ftp (see man cvsup, ... openable through your firewall. ...
    (freebsd-questions)
  • RE: FTP Server on SBS 2003
    ... When I access the ftp site ... In the properties the ftp is set to "all assigned ports" should this ... > You connect the SBS to a third party Router and forward port 21 to the SBS ... The network administrator of the server network can consult the ...
    (microsoft.public.windows.server.sbs)
  • RE: Passive FTP
    ... Some FTP servers are able to set the passive ports he can use, ... Onderwerp: Passive FTP ... Dit E-mail bericht is slechts bestemd voor de persoon aan wie het is ...
    (Security-Basics)
  • Re: Ideas on solving the file transfer problem
    ... out of the range of easy solution for the vast majority of users? ... Port 21 may be the default port for FTP, ... Given the two channel nature of FTP, NAT is a bigger problem than ... Firewalls can be configured by the end-user to open the necessary ports. ...
    (comp.programming)
  • Re: FTP server behind a PF firewall (including NAT)
    ... Philip> have exactly the same problem. ... Philip> huge range of high ports, and I can't find any information ... IPFW is a real pain compared to most modern firewall software. ... address-translate) the FTP data transfers. ...
    (comp.unix.bsd.freebsd.misc)