ok - vec smo konstatovali na vise mesta da svako stiti sebe onoliko koliko smatra da treba ;)
Citat:
Skype nije zavistan od nekih podešavanja zaštitnog zida.
Pa sta ti ovo prakticno znaci? :)
Cik da vidim da ce Skype da ostvari konekcije kada zabranis
outgoing UDP i TCP na koje se on ustvari oslanja za "punching holes" u firewall-u ;)
I zasto bi tu "foru" morao da koristi samo Skajp? Pa bilo ko drugi moze da
napise aplikaciju koja ce na istu "foru" da ostvaruje konekciju, ako FW dozvoljava
UDP i TCP izlaz ;)
A to za BIOS nisam cuo :) - mislim, sto da ga salje sa mog kompa, kada imaju
BIOS da skinu sa sajta proizvodjaca moje ploce? :D
Relevantan deo:
Citat:
Use of the procedure described above is not limited to Skype and is known as "UDP hole punching". Other network services such as the Hamachi gaming VPN application, which relies on peer-to-peer communication between computers behind firewalls, use similar procedures. A more developed form has even made it to the rank of a standard - RFC 3489 "Simple Traversal of UDP through NAT" (STUN) describes a protocol which with two STUN clients can get around the restrictions of NAT with the help of a STUN server in many cases. The draft Traversal Using Relay NAT (TURN) protocol describes a possible standard for relay servers.
DIY hole punching
With a few small utilities, you can try out UDP hole punching for yourself. The tools required, hping2 and netcat, can be found in most Linux distributions. Local is a computer behind a Linux firewall (local-fw) with a stateful firewall which only permits outgoing (UDP) connections. For simplicity, in our test the test computer remote was connected directly to the internet with no firewall.
Firstly start a UDP listener on UDP port 14141 on the local/1 console behind the firewall:
local/1# nc -u -l -p 14141
An external computer "remote" then attempts to contact it.
remote# echo "hello" | nc -p 53 -u local-fw 14141
However, as expected nothing is received on local/1 and, thanks to the firewall, nothing is returned to remote. Now on a second console, local/2, hping2, our universal tool for generating IP packets, punches a hole in the firewall:
local/2# hping2 -c 1 -2 -s 14141 -p 53 remote
As long as remote is behaving itself, it will send back a "port unreachable" response via ICMP - however this is of no consequence. On the second attempt
remote# echo "hello" | nc -p 53 -u local-fw 14141
the netcat listener on console local/1 then coughs up a "hello" - the UDP packet from outside has passed through the firewall and arrived at the computer behind it.
Network administrators who do not appreciate this sort of hole in their firewall and are worried about abuse, are left with only one option - they have to block outgoing UDP traffic, or limit it to essential individual cases. UDP is not required for normal internet communication anyway - the web, e-mail and suchlike all use TCP. Streaming protocols may, however, encounter problems, as they often use UDP because of the reduced overhead.
Astonishingly, hole punching also works with TCP. After an outgoing SYN packet the firewall / NAT router will forward incoming packets with suitable IP addresses and ports to the LAN even if they fail to confirm, or confirm the wrong sequence number (ACK). Linux firewalls at least, clearly fail to evaluate this information consistently. Establishing a TCP connection in this way is, however, not quite so simple, because Alice does not have the sequence number sent in Bob's first packet. The packet containing this information was discarded by her firewall. (ju)
Koje bre portove Skajp koristi? ;)
