Kami akan menyebarkan aplikasi baru ke Server dan aplikasi akan mendengarkan pada port 8443. Kami telah meminta tim Network untuk membuka firewall untuk port 8443 di server itu sebelum menyebarkan aplikasi. Tidak ada aplikasi yang sedang mendengarkan port tertentu di server.
Adakah di sana saya dapat memastikan firewall dibuka untuk port 8443
OS: Linux / Windows
Jawaban:
Jika Anda ingin melihat apakah Anda dapat membentuk koneksi TCP dari mesin jarak jauh, instal OpenCSW pada itu dan mesin target, dan instal netcat pada keduanya. Ini adalah sintaks untuk menggunakan netcat untuk menguji koneksi TCP:
nc -vz targetServer portNum
Misalnya untuk memeriksa SSH pada "homeServer1":
nc -vz homeserver1 22
Itu memungkinkan Anda untuk menguji konektivitas tingkat TCP dari sistem jarak jauh. Netcat juga dapat dikonfigurasi untuk mendengarkan pada port daripada bertindak sebagai klien. Untuk membuatnya mendengarkan di TCP / 8443:
Di server yang akan menampung aplikasi: nc -l homeserver1 8443
Pada mesin yang berada di luar firewall: nc -vz homeserver.fqdn 8443
Ini adalah contoh dari eksekusi yang sukses:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
Connection to ditirlns01.ncat.edu 8443 port [tcp/pcsync-https] succeeded!
Eksekusi yang gagal:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
nc: connect to ditirlns01.ncat.edu port 8443 (tcp) failed: Connection refused
Firewall harus membalas dengan pesan ICMP ketika mereka memblokir permintaan. Namun, ini belum tentu demikian (Anda akan tertarik pada artikel yang bagus ini ).
Anda dapat menguji dari luar untuk melihat apakah port dapat diakses melalui firewall dan, jika demikian, apakah ada sesuatu yang mendengarkannya. Berikut tiga skenario berbeda yang melibatkan permintaan tcp yang dapat Anda amati wireshark, atau beberapa paket sniffer, dan apa yang akan Anda lihat:
1) Firewall menolak permintaan
Anda mendapatkan pesan ICMP kembali, dan alat yang membuat permintaan harus segera memberi tahu Anda sesuatu tentang efek ini ("tidak dapat dijangkau, admin dilarang" dll). Yang saya maksud dengan "alat" adalah klien yang Anda gunakan untuk mengirim permintaan (saya menggunakan telnet). Rincian pesan 1 tergantung pada bagaimana firewall dikonfigurasi, tetapi "port unreachable" mungkin yang paling umum.
"No route to host" mungkin mengindikasikan hal ini, tetapi mungkin juga mengindikasikan masalah perutean yang lebih halus.
2) Firewall menjatuhkan paket
Tidak ada jawaban, jadi alat menunggu sampai waktunya habis atau Anda bosan.
3) Firewall memungkinkan paket (atau tidak ada firewall), tetapi tidak ada yang mendengarkan di port.
Anda mendapatkan pesan TCP RST / ACK kembali. Saya kira protokol TCP memerlukan ini. Dengan kata lain, jika tidak ada yang mendengarkan di port, OS itu sendiri mengirimkan balasan ini. Mungkin sulit untuk membedakan ini dari # 1 hanya berdasarkan apa yang dilaporkan alat, karena itu mungkin mengatakan hal yang sama dalam kedua kasus (namun, kemungkinan besar memang membedakan ini sebagai "koneksi ditolak" vs # 1, "jaringan tidak terjangkau" ). Diamati dalam sniffer paket pada mesin klien, skenario # 1 (pesan penolakan ICMP) dan # 3 (pesan TCP RST / ACK) jelas berbeda.
Satu-satunya opsi lain di sini adalah bahwa paket diizinkan melalui firewall dan ada sesuatu yang mendengarkan, sehingga Anda mendapatkan koneksi yang sukses.
Dengan kata lain: menganggap jaringan Anda secara umum berfungsi dengan baik, jika Anda mendapatkan # 1 atau # 2, itu berarti firewall secara aktif mencegah akses ke port. # 3 akan terjadi jika server Anda tidak berjalan tetapi port dapat diakses, dan tentu saja (implisit) # 4 adalah koneksi yang berhasil.
Anda bisa menggunakan perintah netstat untuk melihat apakah port terbuka dan mendengarkan.
$ netstat -anp | less
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:41716 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:17500 0.0.0.0:* LISTEN 3034/dropbox
tcp 0 0 0.0.0.0:17501 0.0.0.0:* LISTEN 3033/dropbox
tcp 0 0 127.0.0.1:2143 0.0.0.0:* LISTEN 3191/ssh
tcp 0 0 127.0.0.1:2025 0.0.0.0:* LISTEN 3191/ssh
Output menunjukkan proses (kolom terjauh ke kanan) yang mendengarkan pada port TCP. Nomor port adalah nomor yang mengikuti titik dua setelah alamat IP (0.0.0.0:111 akan menjadi port 111 misalnya).
Alamat IP menunjukkan Alamat Lokal dan Asing . Lokal akan menjadi sistem Anda sementara Asing akan menjadi alamat yang menghubungkan ke port TCP Anda atau Anda menghubungkan ke salah satu port TCP mereka.
Jadi dalam kasus port 22, itulah daemon ssh yang berjalan pada sistem saya, itu MENDENGARKAN koneksi. Setelah seseorang mencoba untuk terhubung ke sshdaemon, ia mencopy salinannya sendiri dan mendorong koneksi itu ke port lain, menjaga port TCP 22 terbuka untuk koneksi tambahan saat mereka masuk.
netstat -a -P tcp -f inet | awk '/LISTEN$/ {print $0}'
Konfigurasi dan status konfigurasi firewall adalah firewall / OS khusus.
Yang dapat Anda lakukan adalah mencobanya dari server2:
nmap server1
Baru-baru ini saya mendapat permintaan yang sama dan datang ke utas. Saya dapat memindai port terbuka di FW dengan perintah nc, seperti ini saat saya menanyakan hasilnya:
nc -v -w 1 -z -s *srcIP destIP port* 2>&1 | grep timed > /dev/null && echo closed || echo open
Pada dasarnya, jika saya mendapatkan 'timed out' itu berarti port tidak terbuka di FW.
ncmelaporkan "Sambungan ditolak" ketika port dapat diakses, tetapi tidak ada pendengar, dan "Jaringan tidak dapat dijangkau" ketika permintaan telah dipantulkan oleh firewall melalui icmp (artinya mungkin ada atau mungkin tidak ada layanan pada port tersebut. ). Jika firewall menjatuhkan paket alih-alih menolaknya,nchanya akan bertahan sebentar.