Archive

Posts Tagged ‘ssh tunneling’

Koneksi SSH melalui SOCKS Proxy

Misalkan Anda mempunyai sebuah server di internet, katakanlah Host A, yang menjalankan servis SSH server pada port standar 22. Pada kondisi normal, Anda bisa bebas melakukan koneksi SSH ke Host A, tapi suatu ketika Anda sampai pada suatu keadaan dimana koneksi SSH tidak diperbolehkan dalam suatu jaringan tertentu (katakanlah di kampus), sang admin hanya memperbolehkan koneksi melalui HTTP Proxy dan beberapa servis lain (seperti SMTP, POP3, dan IMAP). Tapi disini saya tidak akan membahas koneksi SSH melalui HTTP Proxy (sudah banyak artikel yang membahas hal ini).

Sebelumnya saya sudah mencoba koneksi SSH melalui HTTP Proxy, tapi sepertinya sang admin tidak memperbolehkan method CONNECT yang dibutuhkan untuk membuat koneksi TCP. Kejam sekali adminnya, tapi saya belum menyerah πŸ˜€

Yang akan kita bahas adalah bagaimana melakukan koneksi SSH melalui SOCKS Proxy. Tapi sebelumnya apa itu SOCKS Proxy?

Dari Wikipedia:

SOCKS is an Internet protocol that facilitates the routing of network packets between client–server applications via a proxy server. SOCKS performs at Layer 5 of the OSI modelβ€”the session layer (an intermediate layer between the presentation layer and the transport layer). Port 1080 is the registered port designated for the SOCKS server.

Disitu juga diberikan contoh kasus:

Bill wishes to communicate with Jane over the internet, but a firewall exists on his network between them and Bill is not authorized to communicate through it himself. Therefore, he connects to the SOCKS proxy on his network and sends to it information about the connection he wishes to make to Jane. The SOCKS proxy opens a connection through the firewall and facilitates the communication between Bill and Jane. For more information on the technical specifics of the SOCKS protocol, see the sections below.

Yang kurang lebih maksudnya adalah kita menggunakan perantara untuk melakukan koneksi, karena koneksi langsung tidak diperbolehkan. Misal: A dan B sebagai host client dan server yang ingin melakukan koneksi, dan C adalah SOCKS proxy. Tapi koneksi dari A ke B tidak diperbolehkan, sedangkan koneksi C ke B diperbolehkan. Nah, kita bisa menumpang koneksi dari C ke B, sehingga A bisa terhubung ke B.

OK, langsung saja kita praktekkan. Pertama-tama kita melakukan koneksi dari A ke C, dalam hal ini kita akan membuat SOCKS proxy menggunakan openSSH.

$ ssh -p993 -D localhost:4321 -l user hostC

Dalam hai ini saya melakukan SSH ke Host C melalui port 993, bukan port standar 22 karena memang di blok oleh admin, port 993 sebenarnya adalah servis IMAP, yang diperbolehkan oleh admin, jadi sebelumnya pastikan SSH server di Host C berjalan di port 993 atau bisa dual port 22 dan 993. Sebenarnya ini hanya akal-akalan saya untuk mengelabui admin saja πŸ˜€

Sekarang kita mempunyai SOCKS Proxy di localhost port 4321. Tapi tunggu dulu, kenapa localhost? Bukankah SOCKS Proxy adalah Host C? Ya, lagi-lagi ini adalah akal-akalan saya, Anda tentu saja bisa menggunakan koneksi langsung ke Host C, tanpa melakukan binding/tunnel SSH terlebih dahulu, tapi yang menjadi masalah disini adalah saya juga tidak bisa melakukan koneksi SOCKS dari A ke C, lihat di atas, SOCKS Proxy menggunakan port 1080, yang tentu saja di blok oleh admin.

Selanjutnya tinggal menggunakan SOCKS Proxy tersebut untuk melakukan koneksi ke Host B. Tapi, untuk melakukan koneksi SSH melalui SOCKS Proxy kita membutuhkan bantuan program lain. Dalam hal ini yang sudah saya cobakan adalah nc dan connect, alternatif lain adalah connect-proxy, corkscrew tidak bisa digunakan karena belum/tidak mendukung SOCKS Proxy, hanya HTTP(s) Proxy.

$ ssh -o “ProxyCommand /usr/bin/nc -x localhost:4321 %h %p” -l user hostB

atau jika menggunakan program connect:

$ ssh -o “ProxyCommand /usr/bin/connect -S localhost:4321 %h %p” -l user hostB

Selamat ber-SSH ria πŸ˜€

.

Referensi:

SSH tunneling dengan putty dan iSSH

February 25, 2011 1 comment

Kalau di postingan ini dan ini saya menggunakan command line untuk melakukan ssh tunneling (baca: “pencurian” bandwidth :P), tapi koq lama-lama capek juga ya karena yang diketikkan cukup panjang dan dilakukan berulang-ulang:

$ ssh -D localhost:4321 -p 993 support@hostname

Akhirnya nyari-nyari ssh client yang memiliki GUI dan bisa melakukan tunneling.

Dan, ternyata gw harus kembali bernostalgia dengan putty, tools yang pertama kali kenal pas jaman kuliah D3 πŸ˜€
Tapi ternyata config-nya ga segampang yang dibayangkan, dan agan Rasyid-lah jadi saksinya, ribet kan gan? Apa gw yg bego ya πŸ˜›

Akhirnya ngoprek-ngoprek lagi di rumah, dan akhirnya ketemu πŸ™‚

Seperti biasa, isi dulu Hostname/IP address tujuan dan portnya, Connection type yang digunakan tentu saja SSH.

Lanjut ke menu Connection –> SSH –> Tunnels

Masukin Source portnya localhost:4321, jangan centang Dynamic dan IPv4 (kalau Auto malah nanti kepilihnya IPv6).

Udah, gitu doang πŸ˜€ Jangan lupa di Save biar nanti ga capek-capek setting lagi.

 

Oiya, ternyata ada yang lebih mudah lagi, yaitu iSSH. Berhubung putty tidak berjalan secara native di Mac OS, jadinya gw milih iSSH aja, dan putty memang lebih “ribet” karena menunya lebih banyak (tidak hanya SSH), sedangkan iSSH khusus untuk SSH jadi lebih simpel πŸ˜€

Semuanya di satu halaman, dan memang sudah ada templatenya πŸ˜€

Kalo begini kan tunneling jadi lebih lancar *digeplak admin πŸ˜€

Categories: Tips 'n trick Tags: , , ,

Tak perlu login ke captive portal part 2

December 17, 2010 6 comments

Kemaren, waktu pengen donlot (dasar penjahat bandwidth) di kampus, alangkah terkejutnya gw (lebay) karena teknik ssh tunneling seperti yang gw posting sebelumnya tidak bisa dipakai lagi alias sudah di patch sama adminnya :(. Mungkin sang admin merasa aneh karena paket yang melalui ssh (port 22) sangat tinggi atau mungkin ada yang membocorkan teknik ini :P. Alhasil gw tidak bisa “mencuri bandwidth” lagi deh :(.

Tapi tunggu dulu, gw tidak menyerah sampai disini :D. Iseng-iseng cek jaringan lagi.
Pertama-tama, gw coba connect lewat ssh seperti biasa, dan inilah pesannya

Hmmm, gw mikir kayanya kalau connect ssh lewat proxy harusnya bisa, karena kita sudah melakukan authentikasi, alhasil gw nyobain pake corkscrew. Tapi hasilnya nihil, access forbidden oleh proxy server.

Kesimpulan sementara, layanan ssh dimatikan secara total, meskipun kita telah login ke captive portal, *kejaaaaaam 😦

Selanjutnya, port scanning dengan nmap πŸ˜€

Wow, ternyata layanan tertentu masih diperbolehkan tanpa harus login terlebih dahulu ke captive portal, seperti DNS (port 53), ICMP/Ping, SMTP, POP3, IMAP dan beberapa layanan lainnya.

Dari sini saya mencoba menjalankan SSH di server remote untuk listen di port selain 22 (karena di blok), saya coba ganti ke port 1000. Ternyata masih terblok, kesimpulan sementara, port-port tertentu saja yang diperbolehkan akses tanpa login. Dari hasil nmap di atas, kalau dilihat port-port yg terbuka antara lain 25, 110, 143, dan 993. Nah, sekarang saya ganti port SSH untuk listen di port 993, tapi konsekuensinya saya harus mematikan service imap-ssl karena memakai port yang sama. Dan ternyata, IT WORKS!!! πŸ˜€

Lagi-lagi dengan magic command ini:

ssh -p 993 -D localhost:4321 username@ipserver

Saya berhasil melakukan tunneling, dan berikutnya tinggal ganti proxy socks 5 di browser ke localhost port 4321.
Dan, voillaa…

Pelajaran lainnya, memblok port standar suatu layanan (seperti SSH dengan port 22) kurang efektif karena kita dapat dengan mudah mengganti port standar tersebut ke port lainnya. Mungkin sang admin harus mempertimbangkan rule “Block everything, allow what necessary” πŸ˜€

Categories: Others Tags: ,

Tak perlu login ke captive portal

October 23, 2010 4 comments

Di kampus saya, akses internet hanya bisa dilakukan setelah kita login ke captive portal, jadi ketika kita akan mengakses website tertentu, maka otomatis akan di cek terlebih dahulu apakah sesi login kita sudah valid atau belum, jika belum maka kita akan di-redirect ke halaman login.

Nah, kemaren pas lagi praktikum, iseng-iseng nge-cek jaringan, dalam keadaan belum login ke captive portal, hal pertama yang saya lakukan adalah dengan melakukan pengecekan terhadap DNS.

Hmmm, akses lewat port 53 (DNS) diperbolehkan, sama seperti dulu, sebenarnya dari sini kita sudah menemukan celah, yang dikenal dengan DNS Tunneling, dulu saya menggunakan OzymanDNS yang dibuat oleh Dan Kaminsky yang sempat heboh dengan penemuannya tentang DNS cache poisoning a.k.a The Kaminsky Bug. Tapi dengan DNS Tunneling, koneksi yang saya dapat tidak reliable karena DNS menggunakan UDP.

Lanjut ke pengecekan kedua, ping.

Ternyata diperbolehkan melakukan ping tanpa harus login, dari sini kita sebenarnya sudah bisa melakukan ICMP Tunneling. Tapi saya masih penasaran dan melakukan port scanning dengan nmap.

Wow, ternyata semua akses diperbolehkan! πŸ˜€ Tapi tunggu dulu, kemana port 80?

Jelas sudah, semua koneksi diperbolehkan kecuali ke port 80, berbeda dengan konfigurasi jaringan terdahulu yaitu tidak memperbolehkan semua koneksi kecuali port 53 πŸ˜€

Yup, kalau sudah begini kita hanya perlu melakukan Tunneling untuk mem-bypass halaman login, dalam hal ini saya menggunakan cara yang paling gampang, yaitu SSH Tunneling πŸ˜€

Dengan satu perintah ajaib ini:

ssh -D localhost:4321 username@ipserver

artinya kita melakukan koneksi ssh ke host yang berada di internet, dan membinding koneksi tersebut ke localhost port 4321, pemilihan port bebas asal tidak bentrok dengan port lain.

Nah, terakhir set proxy di browser menggunakan port binding tersebut, jangan lupa tipe proxy adalah SOCKS.

Dan, VOILAAAA!!! πŸ˜€

Koneksi lokal (IIX) bisa mencapai 2MB atau sekitar 16Mbps.

Dan, koneksi internasional sekitar 500KBps atau sekitar 4Mbps.

 

Sekian dulu dari saya, mungkin sedikit pelajaran bagi kita semua, bahwa bandwidth tidak hanya melalui port 80 (HTTP) saja, tapi berlaku untuk semua jenis koneksi πŸ˜€

Mudah-mudah sang administrator bisa segera memperbaikinnya…