Menghosting ASP.NET Core di Linux dengan Nginx

Oleh Sourabh Shirhatti

Catatan

Ini bukan versi terbaru dari artikel ini. Untuk rilis saat ini, lihat versi .NET 8 dari artikel ini.

Penting

Informasi ini berkaitan dengan produk pra-rilis yang mungkin dimodifikasi secara substansial sebelum dirilis secara komersial. Microsoft tidak memberikan jaminan, tersirat maupun tersurat, sehubungan dengan informasi yang diberikan di sini.

Untuk rilis saat ini, lihat versi .NET 8 dari artikel ini.

Panduan ini menjelaskan penyiapan lingkungan ASP.NET Core siap produksi untuk Ubuntu, Red Hat Enterprise (RHEL), dan SUSE Linux Enterprise Server.

Untuk informasi tentang distribusi Linux lain yang didukung oleh ASP.NET Core, lihat Prasyarat untuk .NET Core di Linux.

Panduan ini:

  • Menempatkan aplikasi ASP.NET Core yang ada di belakang server proksi terbalik.
  • Menyiapkan server proksi terbalik untuk meneruskan permintaan ke Kestrel server web.
  • Memastikan aplikasi web berjalan pada startup sebagai daemon.
  • Mengonfigurasi alat manajemen proses untuk membantu memulai ulang aplikasi web.

Prasyarat

  • Akses ke Ubuntu 20.04 dengan akun pengguna standar dengan hak istimewa sudo.
  • Runtime .NET stabil terbaru yang diinstal pada server.
  • Aplikasi ASP.NET Core yang ada.

Kapan saja di masa mendatang setelah meningkatkan kerangka kerja bersama, mulai ulang aplikasi ASP.NET Core yang dihosting oleh server.

Menerbitkan dan menyalin melalui aplikasi

Konfigurasikan aplikasi untuk penyebaran yang bergantung pada kerangka kerja.

Jika aplikasi dijalankan secara lokal di lingkungan Pengembangan dan tidak dikonfigurasi oleh server untuk membuat koneksi HTTPS yang aman, adopsi salah satu pendekatan berikut:

  • Konfigurasikan aplikasi untuk menangani koneksi lokal yang aman. Untuk informasi selengkapnya, lihat bagian konfigurasi HTTPS.

  • Konfigurasikan aplikasi untuk dijalankan di titik akhir yang tidak aman:

    • Nonaktifkan Middleware Pengalihan HTTPS di lingkungan Pengembangan (Program.cs):

      if (!app.Environment.IsDevelopment())
      {
          app.UseHttpsRedirection();
      }
      

      Untuk informasi lebih lanjut, lihat Menggunakan beberapa lingkungan di ASP.NET Core.

    • Hapus https://localhost:5001 (jika ada) dari applicationUrl properti dalam Properties/launchSettings.json file.

Untuk informasi selengkapnya tentang konfigurasi menurut lingkungan, lihat Menggunakan beberapa lingkungan di ASP.NET Core.

Jalankan penerbitan dotnet dari lingkungan pengembangan untuk mengemas aplikasi ke dalam direktori (misalnya, bin/Release/{TARGET FRAMEWORK MONIKER}/publish, di mana {TARGET FRAMEWORK MONIKER} tempat penampung adalah Target Framework Moniker (TFM)) yang dapat berjalan di server:

dotnet publish --configuration Release

Aplikasi ini juga dapat diterbitkan sebagai penyebaran mandiri jika Anda lebih suka tidak mempertahankan runtime .NET Core di server.

Salin aplikasi ASP.NET Core ke server menggunakan alat yang terintegrasi ke dalam alur kerja organisasi (misalnya, SCP, SFTP). Adalah umum untuk menemukan aplikasi web di var bawah direktori (misalnya, var/www/helloapp).

Catatan

Di bawah skenario penyebaran produksi, alur kerja integrasi berkelanjutan melakukan pekerjaan menerbitkan aplikasi dan menyalin aset ke server.

Uji aplikasi:

  1. Dari baris perintah, jalankan aplikasi: dotnet <app_assembly>.dll.
  2. Di browser, buka untuk http://<serveraddress>:<port> memverifikasi bahwa aplikasi berfungsi di Linux secara lokal.

Mengonfigurasi server proksi terbalik

Proksi terbalik adalah penyiapan umum untuk melayani aplikasi web dinamis. Proksi terbalik mengakhiri permintaan HTTP dan meneruskannya ke aplikasi ASP.NET Core.

Menggunakan server proksi terbalik

Kestrel sangat bagus untuk menyajikan konten dinamis dari ASP.NET Core. Namun, kemampuan penyajian web tidak kaya fitur seperti server seperti IIS, Apache, atau Nginx. Server proksi terbalik dapat membongkar pekerjaan seperti menyajikan konten statis, permintaan penembolokan, permintaan pemadatan, dan penghentian HTTPS dari server HTTP. Server proksi terbalik dapat berada di komputer khusus atau dapat disebarkan bersama server HTTP.

Untuk tujuan panduan ini, satu instans Nginx digunakan. Ini berjalan pada server yang sama, bersama dengan server HTTP. Berdasarkan persyaratan, pengaturan yang berbeda dapat dipilih.

Karena permintaan diteruskan oleh proksi terbalik, gunakan Middleware Header yang Diteruskan dari Microsoft.AspNetCore.HttpOverrides paket, yang secara otomatis disertakan dalam aplikasi ASP.NET Core melalui metapackage kerangka kerja Microsoft.AspNetCore.App bersama. Middleware memperbarui Request.Scheme, menggunakan X-Forwarded-Proto header, sehingga URI pengalihan dan kebijakan keamanan lainnya berfungsi dengan benar.

Middleware Header yang Diteruskan harus dijalankan sebelum middleware lainnya. Urutan ini memastikan bahwa middleware yang mengandalkan informasi header yang diteruskan dapat menggunakan nilai header untuk pemrosesan. Untuk menjalankan Middleware Header yang Diteruskan setelah middleware diagnostik dan penanganan kesalahan, lihat Urutan Middleware Header yang Diteruskan.

Panggil UseForwardedHeaders metode sebelum memanggil middleware lainnya. Konfigurasikan middleware untuk meneruskan X-Forwarded-For header dan X-Forwarded-Proto :

using Microsoft.AspNetCore.HttpOverrides;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication();

var app = builder.Build();

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

app.MapGet("/", () => "Hello ForwardedHeadersOptions!");

app.Run();

Jika tidak ForwardedHeadersOptions ditentukan ke middleware, header default yang akan diteruskan adalah None.

Proksi yang berjalan pada alamat loopback (127.0.0.0/8, [::1]), termasuk alamat localhost standar (127.0.0.1), dipercaya secara default. Jika proksi atau jaringan tepercaya lainnya dalam organisasi menangani permintaan antara internet dan server web, tambahkan ke daftar KnownProxies atau KnownNetworks dengan ForwardedHeadersOptions. Contoh berikut menambahkan server proksi tepercaya di alamat 10.0.0.100 IP ke Middleware KnownProxiesHeader yang Diteruskan :

using Microsoft.AspNetCore.HttpOverrides;
using System.Net;

var builder = WebApplication.CreateBuilder(args);

// Configure forwarded headers
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

builder.Services.AddAuthentication();

var app = builder.Build();

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

app.MapGet("/", () => "10.0.0.100");

app.Run();

Untuk informasi selengkapnya, lihat Mengonfigurasi ASP.NET Core untuk bekerja dengan server proxy dan memuat penyeimbang.

Menginstal Nginx

Gunakan apt-get untuk menginstal Nginx. Alat penginstal systemd membuat skrip init yang menjalankan Nginx sebagai daemon pada startup sistem. Ikuti petunjuk penginstalan untuk Ubuntu di Nginx: Paket Resmi Debian/Ubuntu.

Catatan

Jika modul Nginx opsional diperlukan, membangun Nginx dari sumber mungkin diperlukan.

Karena Nginx diinstal untuk pertama kalinya, secara eksplisit memulainya dengan menjalankan:

sudo service nginx start

Verifikasi browser menampilkan halaman arahan default untuk Nginx. Halaman arahan dapat dijangkau di http://<server_IP_address>/index.nginx-debian.html.

Mengonfigurasi Nginx

Untuk mengonfigurasi Nginx sebagai proksi terbalik untuk meneruskan permintaan HTTP ke aplikasi ASP.NET Core, ubah /etc/nginx/sites-available/default dan buat ulang symlink. Setelah membuat /etc/nginx/sites-available/default file, gunakan perintah berikut untuk membuat symlink:

sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default

Buka /etc/nginx/sites-available/default di editor teks, dan ganti konten dengan cuplikan berikut:

http {
  map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
  }

  server {
    listen        80;
    server_name   example.com *.example.com;
    location / {
        proxy_pass         http://127.0.0.1:5000/;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
  }
}

Jika aplikasi adalah SignalR aplikasi atauBlazor Server, lihat hosting produksi ASP.NET Core SignalR dan penskalaan dan Host dan sebarkan aplikasi sisi Blazor server ASP.NET Core masing-masing untuk informasi selengkapnya.

Ketika tidak ada server_name kecocokan, Nginx menggunakan server default. Jika tidak ada server default yang ditentukan, server pertama dalam file konfigurasi adalah server default. Sebagai praktik terbaik, tambahkan server default tertentu yang mengembalikan kode status 444 dalam file konfigurasi Anda. Contoh konfigurasi server default adalah:

server {
    listen   80 default_server;
    # listen [::]:80 default_server deferred;
    return   444;
}

Dengan file konfigurasi sebelumnya dan server default, Nginx menerima lalu lintas publik pada port 80 dengan header example.com host atau *.example.com. Permintaan yang tidak cocok dengan host ini tidak akan diteruskan ke Kestrel. Nginx meneruskan permintaan yang cocok ke Kestrel di http://127.0.0.1:5000/. Untuk informasi selengkapnya, lihat Cara nginx memproses permintaan. Untuk mengubah KestrelIP/port, lihat Kestrel: Konfigurasi titik akhir.

Peringatan

Kegagalan untuk menentukan arahan server_name yang tepat mengekspos aplikasi Anda terhadap kerentanan keamanan. Pengikatan wildcard subdomain (misalnya, *.example.com) tidak menimbulkan risiko keamanan ini jika Anda mengontrol seluruh domain induk ( *.comdibandingkan dengan , yang rentan). Untuk informasi selengkapnya, lihat RFC 9110: Semantik HTTP (Bagian 7.2: Host dan :authority).

Setelah konfigurasi Nginx dibuat, jalankan sudo nginx -t untuk memverifikasi sintaks file konfigurasi. Jika pengujian file konfigurasi berhasil, paksa Nginx untuk mengambil perubahan dengan menjalankan sudo nginx -s reload.

Untuk langsung menjalankan aplikasi di server:

  1. Navigasi ke direktori aplikasi.
  2. Jalankan aplikasi: dotnet <app_assembly.dll>, di mana app_assembly.dll adalah nama file rakitan aplikasi.

Jika aplikasi berjalan di server tetapi gagal merespons melalui internet, periksa firewall server dan konfirmasi port 80 terbuka. Jika menggunakan Azure Ubuntu VM, tambahkan aturan Network Security Group (NSG) yang memungkinkan lalu lintas port masuk 80. Tidak perlu mengaktifkan aturan port keluar 80, karena lalu lintas keluar secara otomatis diberikan saat aturan masuk diaktifkan.

Setelah selesai menguji aplikasi, matikan aplikasi dengan Ctrl+C (Windows) atau ⌘+C (macOS) di prompt perintah.

Tingkatkan keepalive_requests

keepalive_requests dapat ditingkatkan untuk performa yang lebih tinggi, Untuk informasi selengkapnya, lihat masalah GitHub ini.

Memantau aplikasi

Server disiapkan untuk meneruskan permintaan yang dibuat ke http://<serveraddress>:80 aplikasi ASP.NET Core yang berjalan di Kestrelhttp://127.0.0.1:5000. Namun, Nginx tidak disiapkan untuk mengelola proses.Kestrel systemd dapat digunakan untuk membuat file layanan untuk memulai dan memantau aplikasi web yang mendasar. systemd adalah sistem init yang menyediakan banyak fitur canggih untuk memulai, menghentikan, dan mengelola proses.

Membuat file layanan

Buat file definisi layanan:

sudo nano /etc/systemd/system/kestrel-helloapp.service

Contoh berikut adalah .ini file layanan untuk aplikasi:

[Unit]
Description=Example .NET Web API App running on Linux

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_NOLOGO=true

[Install]
WantedBy=multi-user.target

Dalam contoh sebelumnya, pengguna yang mengelola layanan ditentukan oleh User opsi . Pengguna (www-data) harus ada dan memiliki kepemilikan file aplikasi yang tepat.

Gunakan TimeoutStopSec untuk mengonfigurasi durasi waktu untuk menunggu aplikasi dimatikan setelah menerima sinyal interupsi awal. Jika aplikasi tidak dimatikan dalam periode ini, SIGKILL dikeluarkan untuk mengakhiri aplikasi. Berikan nilai sebagai detik tanpa unit (misalnya, 150), nilai rentang waktu (misalnya, 2min 30s), atau infinity untuk menonaktifkan batas waktu. TimeoutStopSecdefault ke nilai DefaultTimeoutStopSec dalam file konfigurasi manajer (systemd-system.conf, , system.conf.d, systemd-user.confuser.conf.d). Batas waktu default untuk sebagian besar distribusi adalah 90 detik.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Linux memiliki sistem file peka huruf besar/kecil. Pengaturan ASPNETCORE_ENVIRONMENT untuk Production menghasilkan pencarian file appsettings.Production.jsonkonfigurasi , bukan appsettings.production.json.

Beberapa nilai (misalnya, string koneksi SQL) harus diloloskan agar penyedia konfigurasi membaca variabel lingkungan. Gunakan perintah berikut untuk menghasilkan nilai yang lolos dengan benar untuk digunakan dalam file konfigurasi:

systemd-escape "<value-to-escape>"

Pemisah titik dua (:) tidak didukung dalam nama variabel lingkungan. Gunakan garis bawah ganda (__) sebagai pengganti titik dua. Penyedia konfigurasi Variabel Lingkungan mengonversi garis bawah ganda menjadi titik dua saat variabel lingkungan dibaca ke dalam konfigurasi. Dalam contoh berikut, kunci ConnectionStrings:DefaultConnection string koneksi diatur ke dalam file definisi layanan sebagai ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Simpan file dan aktifkan layanan.

sudo systemctl enable kestrel-helloapp.service

Mulai layanan dan verifikasi bahwa layanan sedang berjalan.

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on Linux
    Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-helloapp.service
            └─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll

Dengan proksi terbalik yang dikonfigurasi dan Kestrel dikelola melalui systemd, aplikasi web sepenuhnya dikonfigurasi dan dapat diakses dari browser di komputer lokal di http://localhost. Ini juga dapat diakses dari komputer jarak jauh, yang melarang firewall apa pun yang mungkin memblokir. Memeriksa header respons, Server header menunjukkan aplikasi ASP.NET Core yang dilayani oleh Kestrel.

HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked

Menampilkan log

Karena aplikasi web yang digunakan Kestrel dikelola menggunakan systemd, semua peristiwa dan proses dicatat ke jurnal terpusat. Namun, jurnal ini mencakup semua entri untuk semua layanan dan proses yang dikelola oleh systemd. Untuk melihat kestrel-helloapp.serviceitem -spesifik, gunakan perintah berikut:

sudo journalctl -fu kestrel-helloapp.service

Untuk pemfilteran lebih lanjut, opsi waktu seperti --since today, --until 1 hour ago, atau kombinasi ini dapat mengurangi jumlah entri yang dikembalikan.

sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"

Perlindungan data

Tumpukan ASP.NET Core Data Protection digunakan oleh beberapa middleware ASP.NET Core, termasuk middleware autentikasi (misalnya, cookie middleware) dan perlindungan pemalsuan permintaan lintas situs (CSRF). Bahkan jika API Perlindungan Data tidak dipanggil oleh kode pengguna, perlindungan data harus dikonfigurasi untuk membuat penyimpanan kunci kriptografi persisten. Jika perlindungan data tidak dikonfigurasi, kunci disimpan di memori dan dibuang saat aplikasi dimulai ulang.

Jika ring kunci disimpan dalam memori saat aplikasi dimulai ulang:

  • Semua token autentikasi berbasis cookie menjadi tidak valid.
  • Pengguna diminta untuk masuk lagi pada permintaan berikutnya.
  • Data apa pun yang dilindungi dengan ring kunci tidak dapat lagi didekripsi. Ini mungkin termasuk token CSRF dan cookie ASP.NET Core MVC TempData.

Untuk mengonfigurasi perlindungan data untuk mempertahankan dan mengenkripsi cincin kunci, lihat:

Bidang header permintaan panjang

Pengaturan default server proksi biasanya membatasi bidang header permintaan menjadi 4 K atau 8 K tergantung pada platform. Aplikasi mungkin memerlukan bidang yang lebih panjang dari default (misalnya, aplikasi yang menggunakan ID Microsoft Entra). Jika bidang yang lebih panjang diperlukan, pengaturan default server proksi memerlukan penyesuaian. Nilai yang akan diterapkan bergantung pada skenario. Untuk informasi selengkapnya, lihat dokumentasi server Anda.

Peringatan

Jangan tingkatkan nilai default buffer proksi kecuali diperlukan. Meningkatkan nilai-nilai ini meningkatkan risiko serangan buffer overrun (overflow) dan Denial of Service (DoS) oleh pengguna berbahaya.

Mengamankan aplikasi

Aktifkan AppArmor

Linux Security Modules (LSM) adalah kerangka kerja yang merupakan bagian dari kernel Linux sejak Linux 2.6. LSM mendukung berbagai implementasi modul keamanan. AppArmor adalah LSM yang mengimplementasikan sistem Kontrol Akses Wajib, yang memungkinkan pembatasan program ke sekumpulan sumber daya terbatas. Pastikan AppArmor diaktifkan dan dikonfigurasi dengan benar.

Mengonfigurasi firewall

Tutup semua port eksternal yang tidak sedang digunakan. Firewall tidak rumit (ufw) menyediakan ujung depan dengan iptables menyediakan CLI untuk mengonfigurasi firewall.

Peringatan

Firewall mencegah akses ke seluruh sistem jika tidak dikonfigurasi dengan benar. Kegagalan untuk menentukan port SSH yang benar secara efektif mengunci Anda keluar dari sistem jika Anda menggunakan SSH untuk menyambungkannya. Port default adalah 22. Untuk informasi selengkapnya, lihat pengenalan ufw dan manual.

Instal ufw dan konfigurasikan untuk memungkinkan lalu lintas pada port apa pun yang diperlukan.

sudo apt-get install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

Amankan Nginx

Mengubah nama respons Nginx

Edit src/http/ngx_http_header_filter_module.c:

static char ngx_http_server_string[] = "Server: Web Server" CRLF;
static char ngx_http_server_full_string[] = "Server: Web Server" CRLF;

Mengonfigurasi opsi

Konfigurasikan server dengan modul tambahan yang diperlukan. Pertimbangkan untuk menggunakan firewall aplikasi web, seperti ModSecurity, untuk mengeraskan aplikasi.

Konfigurasi HTTPS

Mengonfigurasi aplikasi untuk koneksi lokal aman (HTTPS)

Perintah jalankan dotnet menggunakan file aplikasiProperties/launchSettings.json, yang mengonfigurasi aplikasi untuk mendengarkan URL yang disediakan oleh applicationUrl properti . Contohnya,https://localhost:5001;http://localhost:5000.

Konfigurasikan aplikasi untuk menggunakan sertifikat dalam pengembangan untuk dotnet run perintah atau lingkungan pengembangan (F5 atau Ctrl+F5 di Visual Studio Code) menggunakan salah satu pendekatan berikut:

Mengonfigurasi proksi terbalik untuk koneksi klien aman (HTTPS)

Peringatan

Konfigurasi keamanan di bagian ini adalah konfigurasi umum yang akan digunakan sebagai titik awal untuk penyesuaian lebih lanjut. Kami tidak dapat memberikan dukungan untuk alat, server, dan sistem operasi pihak ketiga. Gunakan konfigurasi di bagian ini dengan risiko Anda sendiri. Untuk informasi selengkapnya, akses sumber daya berikut:

  • Konfigurasikan server untuk mendengarkan lalu lintas HTTPS pada port 443 dengan menentukan sertifikat valid yang dikeluarkan oleh Otoritas Sertifikat (CA) tepercaya.

  • Perkuat keamanan dengan menggunakan beberapa praktik yang digambarkan dalam file /etc/nginx/nginx.conf berikut.

  • Contoh berikut tidak mengonfigurasi server untuk mengalihkan permintaan yang tidak aman. Sebaiknya gunakan Middleware Pengalihan HTTPS. Untuk informasi selengkapnya, lihat Menerapkan HTTPS di ASP.NET Core.

    Catatan

    Untuk lingkungan pengembangan di mana konfigurasi server menangani pengalihan aman alih-alih Middleware Pengalihan HTTPS, sebaiknya gunakan pengalihan sementara (302) daripada pengalihan permanen (301). Penembolokan tautan dapat menyebabkan perilaku yang tidak stabil di lingkungan pengembangan.

  • Strict-Transport-Security Menambahkan header (HSTS) memastikan semua permintaan berikutnya yang dibuat oleh klien melalui HTTPS. Untuk panduan tentang mengatur Strict-Transport-Security header, lihat Menerapkan HTTPS di ASP.NET Core.

  • Jika HTTPS akan dinonaktifkan di masa mendatang, gunakan salah satu pendekatan berikut:

    • Jangan tambahkan header HSTS.
    • Pilih nilai pendek max-age .

Tambahkan file konfigurasi /etc/nginx/proxy.conf:

proxy_redirect          off;
proxy_set_header        Host $host;
proxy_set_header        X-Real-IP $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header        X-Forwarded-Proto $scheme;
client_max_body_size    10m;
client_body_buffer_size 128k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffers           32 4k;

Ganti konten file konfigurasi /etc/nginx/nginx.conf dengan file berikut. Contoh berisi bagian http dan server dalam satu file konfigurasi.

http {
    include        /etc/nginx/proxy.conf;
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
    server_tokens  off;

    sendfile on;
    # Adjust keepalive_timeout to the lowest possible value that makes sense 
    # for your use case.
    keepalive_timeout   29;
    client_body_timeout 10; client_header_timeout 10; send_timeout 10;

    upstream helloapp{
        server 127.0.0.1:5000;
    }

    server {
        listen                    443 ssl http2;
        listen                    [::]:443 ssl http2;
        server_name               example.com *.example.com;
        ssl_certificate           /etc/ssl/certs/testCert.crt;
        ssl_certificate_key       /etc/ssl/certs/testCert.key;
        ssl_session_timeout       1d;
        ssl_protocols             TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers off;
        ssl_ciphers               ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
        ssl_session_cache         shared:SSL:10m;
        ssl_session_tickets       off;
        ssl_stapling              off;

        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;

        #Redirects all traffic
        location / {
            proxy_pass http://helloapp;
            limit_req  zone=one burst=10 nodelay;
        }
    }
}

Catatan

Blazor WebAssembly aplikasi memerlukan nilai parameter yang lebih besar burst untuk mengakomodasi jumlah permintaan yang lebih besar yang dibuat oleh aplikasi. Untuk informasi selengkapnya, lihat Host dan sebarkan ASP.NET Core Blazor WebAssembly.

Catatan

Contoh sebelumnya menonaktifkan Stapling Protokol Status Sertifikat Online (OCSP). Jika diaktifkan, konfirmasikan bahwa sertifikat mendukung fitur tersebut. Untuk informasi dan panduan selengkapnya tentang mengaktifkan OCSP, lihat properti berikut ini di artikel Modul ngx_http_ssl_module (dokumentasi Nginx):

  • ssl_stapling
  • ssl_stapling_file
  • ssl_stapling_responder
  • ssl_stapling_verify

Amankan Nginx dari pembajakan klik

Clickjacking, juga dikenal sebagai serangan redress UI, adalah serangan berbahaya di mana pengunjung situs web ditipu untuk mengklik tautan atau tombol di halaman yang berbeda dari yang saat ini mereka kunjungi. Gunakan X-FRAME-OPTIONS untuk mengamankan situs.

Untuk mengurangi serangan pembajakan klik:

  1. Edit file nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    http{} Dalam blok kode, tambahkan baris:add_header X-Frame-Options "SAMEORIGIN";

  2. Simpan file.

  3. Mulai ulang Nginx.

Sniffing jenis MIME

Header ini mencegah sebagian besar browser dari MIME-mengendus respons dari jenis konten yang dideklarasikan, karena header menginstruksikan browser untuk tidak mengambil alih jenis konten respons. nosniff Dengan opsi , jika server mengatakan kontennya adalah text/html, browser merendernya sebagai text/html.

  1. Edit file nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    http{} Dalam blok kode, tambahkan baris:add_header X-Content-Type-Options "nosniff";

  2. Simpan file.

  3. Mulai ulang Nginx.

Saran Nginx tambahan

Setelah meningkatkan kerangka kerja bersama di server, mulai ulang aplikasi ASP.NET Core yang dihosting oleh server.

Sumber Daya Tambahan:

Panduan ini menjelaskan pengaturan lingkungan ASP.NET Core siap produksi di server Ubuntu 16.04. Instruksi ini kemungkinan berfungsi dengan versi Ubuntu yang lebih baru, tetapi instruksi belum diuji dengan versi yang lebih baru.

Untuk informasi tentang distribusi Linux lain yang didukung oleh ASP.NET Core, lihat Prasyarat untuk .NET Core di Linux.

Catatan

Untuk Ubuntu 14.04, supervisord disarankan sebagai solusi untuk memantau Kestrel proses. systemd tidak tersedia di Ubuntu 14.04. Untuk instruksi Ubuntu 14.04, lihat versi topik ini sebelumnya.

Panduan ini:

  • Menempatkan aplikasi ASP.NET Core yang ada di belakang server proksi terbalik.
  • Menyiapkan server proksi terbalik untuk meneruskan permintaan ke Kestrel server web.
  • Memastikan aplikasi web berjalan pada startup sebagai daemon.
  • Mengonfigurasi alat manajemen proses untuk membantu memulai ulang aplikasi web.

Prasyarat

  • Akses ke server Ubuntu 16.04 dengan akun pengguna standar dengan hak istimewa sudo.
  • Runtime .NET non-pratinjau terbaru terinstal di server.
  • Aplikasi ASP.NET Core yang ada.

Kapan saja di masa mendatang setelah meningkatkan kerangka kerja bersama, mulai ulang aplikasi ASP.NET Core yang dihosting oleh server.

Menerbitkan dan menyalin melalui aplikasi

Konfigurasikan aplikasi untuk penyebaran yang bergantung pada kerangka kerja.

Jika aplikasi dijalankan secara lokal di lingkungan Pengembangan dan tidak dikonfigurasi oleh server untuk membuat koneksi HTTPS yang aman, adopsi salah satu pendekatan berikut:

  • Konfigurasikan aplikasi untuk menangani koneksi lokal yang aman. Untuk informasi selengkapnya, lihat bagian konfigurasi HTTPS.

  • Konfigurasikan aplikasi untuk dijalankan di titik akhir yang tidak aman:

    • Nonaktifkan Middleware Pengalihan HTTPS di lingkungan Pengembangan (Program.cs):

      if (!app.Environment.IsDevelopment())
      {
          app.UseHttpsRedirection();
      }
      

      Untuk informasi lebih lanjut, lihat Menggunakan beberapa lingkungan di ASP.NET Core.

    • Hapus https://localhost:5001 (jika ada) dari applicationUrl properti dalam Properties/launchSettings.json file.

Untuk informasi selengkapnya tentang konfigurasi menurut lingkungan, lihat Menggunakan beberapa lingkungan di ASP.NET Core.

Jalankan penerbitan dotnet dari lingkungan pengembangan untuk mengemas aplikasi ke dalam direktori (misalnya, bin/Release/{TARGET FRAMEWORK MONIKER}/publish, di mana tempat penampung {TARGET FRAMEWORK MONIKER} adalah Target Framework Moniker/TFM) yang dapat berjalan di server:

dotnet publish --configuration Release

Aplikasi ini juga dapat diterbitkan sebagai penyebaran mandiri jika Anda lebih suka tidak mempertahankan runtime .NET Core di server.

Salin aplikasi ASP.NET Core ke server menggunakan alat yang terintegrasi ke dalam alur kerja organisasi (misalnya, SCP, SFTP). Adalah umum untuk menemukan aplikasi web di var bawah direktori (misalnya, var/www/helloapp).

Catatan

Di bawah skenario penyebaran produksi, alur kerja integrasi berkelanjutan melakukan pekerjaan menerbitkan aplikasi dan menyalin aset ke server.

Uji aplikasi:

  1. Dari baris perintah, jalankan aplikasi: dotnet <app_assembly>.dll.
  2. Di browser, buka untuk http://<serveraddress>:<port> memverifikasi bahwa aplikasi berfungsi di Linux secara lokal.

Mengonfigurasi server proksi terbalik

Proksi terbalik adalah penyiapan umum untuk melayani aplikasi web dinamis. Proksi terbalik mengakhiri permintaan HTTP dan meneruskannya ke aplikasi ASP.NET Core.

Menggunakan server proksi terbalik

Kestrel sangat bagus untuk menyajikan konten dinamis dari ASP.NET Core. Namun, kemampuan penyajian web tidak kaya fitur seperti server seperti IIS, Apache, atau Nginx. Server proksi terbalik dapat membongkar pekerjaan seperti menyajikan konten statis, permintaan penembolokan, permintaan pemadatan, dan penghentian HTTPS dari server HTTP. Server proksi terbalik dapat berada di komputer khusus atau dapat disebarkan bersama server HTTP.

Untuk tujuan panduan ini, satu instans Nginx digunakan. Ini berjalan pada server yang sama, bersama dengan server HTTP. Berdasarkan persyaratan, pengaturan yang berbeda dapat dipilih.

Karena permintaan diteruskan oleh proksi terbalik, gunakan Middleware Header yang Diteruskan dari Microsoft.AspNetCore.HttpOverrides paket. Middleware memperbarui Request.Scheme, menggunakan X-Forwarded-Proto header, sehingga URI pengalihan dan kebijakan keamanan lainnya berfungsi dengan benar.

Middleware Header yang Diteruskan harus dijalankan sebelum middleware lainnya. Urutan ini memastikan bahwa middleware yang mengandalkan informasi header yang diteruskan dapat menggunakan nilai header untuk pemrosesan. Untuk menjalankan Middleware Header yang Diteruskan setelah middleware diagnostik dan penanganan kesalahan, lihat Urutan Middleware Header yang Diteruskan.

Panggil UseForwardedHeaders metode di bagian Program.cs atas sebelum memanggil middleware lainnya. Konfigurasikan middleware untuk meneruskan X-Forwarded-For header dan X-Forwarded-Proto :

// requires using Microsoft.AspNetCore.HttpOverrides;
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

Jika tidak ForwardedHeadersOptions ditentukan ke middleware, header default yang akan diteruskan adalah None.

Proksi yang berjalan pada alamat loopback (127.0.0.0/8, [::1]), termasuk alamat localhost standar (127.0.0.1), dipercaya secara default. Jika proksi atau jaringan tepercaya lainnya dalam organisasi menangani permintaan antara Internet dan server web, tambahkan ke daftar KnownProxies atau KnownNetworks dengan ForwardedHeadersOptions. Contoh berikut menambahkan server proksi tepercaya di alamat IP 10.0.0.100 ke Middleware KnownProxies Header yang Diteruskan di Program.cs:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

Untuk informasi selengkapnya, lihat Mengonfigurasi ASP.NET Core untuk bekerja dengan server proxy dan memuat penyeimbang.

Menginstal Nginx

Gunakan apt-get untuk menginstal Nginx. Alat penginstal systemd membuat skrip init yang menjalankan Nginx sebagai daemon pada startup sistem. Ikuti petunjuk penginstalan untuk Ubuntu di Nginx: Paket Resmi Debian/Ubuntu.

Catatan

Jika modul Nginx opsional diperlukan, membangun Nginx dari sumber mungkin diperlukan.

Karena Nginx diinstal untuk pertama kalinya, secara eksplisit memulainya dengan menjalankan:

sudo service nginx start

Verifikasi browser menampilkan halaman arahan default untuk Nginx. Halaman arahan dapat dijangkau di http://<server_IP_address>/index.nginx-debian.html.

Mengonfigurasi Nginx

Untuk mengonfigurasi Nginx sebagai proksi terbalik untuk meneruskan permintaan HTTP ke aplikasi ASP.NET Core Anda, ubah /etc/nginx/sites-available/default. Buka di editor teks, dan ganti konten dengan cuplikan berikut:

server {
    listen        80;
    server_name   example.com *.example.com;
    location / {
        proxy_pass         http://127.0.0.1:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

Jika aplikasi adalah SignalR aplikasi atauBlazor Server, lihat hosting produksi ASP.NET Core SignalR dan penskalaan dan Host dan sebarkan aplikasi sisi Blazor server ASP.NET Core masing-masing untuk informasi selengkapnya.

Ketika tidak ada server_name kecocokan, Nginx menggunakan server default. Jika tidak ada server default yang ditentukan, server pertama dalam file konfigurasi adalah server default. Sebagai praktik terbaik, tambahkan server default tertentu yang mengembalikan kode status 444 dalam file konfigurasi Anda. Contoh konfigurasi server default adalah:

server {
    listen   80 default_server;
    # listen [::]:80 default_server deferred;
    return   444;
}

Dengan file konfigurasi sebelumnya dan server default, Nginx menerima lalu lintas publik pada port 80 dengan header example.com host atau *.example.com. Permintaan yang tidak cocok dengan host ini tidak akan diteruskan ke Kestrel. Nginx meneruskan permintaan yang cocok ke Kestrel di http://127.0.0.1:5000. Untuk informasi selengkapnya, lihat Cara nginx memproses permintaan. Untuk mengubah KestrelIP/port, lihat Kestrel: Konfigurasi titik akhir.

Peringatan

Kegagalan untuk menentukan arahan server_name yang tepat mengekspos aplikasi Anda terhadap kerentanan keamanan. Pengikatan wildcard subdomain (misalnya, *.example.com) tidak menimbulkan risiko keamanan ini jika Anda mengontrol seluruh domain induk ( *.comdibandingkan dengan , yang rentan). Untuk informasi selengkapnya, lihat RFC 9110: Semantik HTTP (Bagian 7.2: Host dan :authority).

Setelah konfigurasi Nginx dibuat, jalankan sudo nginx -t untuk memverifikasi sintaks file konfigurasi. Jika pengujian file konfigurasi berhasil, paksa Nginx untuk mengambil perubahan dengan menjalankan sudo nginx -s reload.

Untuk langsung menjalankan aplikasi di server:

  1. Navigasi ke direktori aplikasi.
  2. Jalankan aplikasi: dotnet <app_assembly.dll>, di mana app_assembly.dll adalah nama file rakitan aplikasi.

Jika aplikasi berjalan di server tetapi gagal merespons melalui Internet, periksa firewall server dan konfirmasi port 80 terbuka. Jika menggunakan Azure Ubuntu VM, tambahkan aturan Network Security Group (NSG) yang memungkinkan lalu lintas port masuk 80. Tidak perlu mengaktifkan aturan port keluar 80, karena lalu lintas keluar secara otomatis diberikan saat aturan masuk diaktifkan.

Setelah selesai menguji aplikasi, matikan aplikasi dengan Ctrl+C (Windows) atau ⌘+C (macOS) di prompt perintah.

Memantau aplikasi

Server disiapkan untuk meneruskan permintaan yang dibuat ke http://<serveraddress>:80 aplikasi ASP.NET Core yang berjalan di Kestrelhttp://127.0.0.1:5000. Namun, Nginx tidak disiapkan untuk mengelola proses.Kestrel systemd dapat digunakan untuk membuat file layanan untuk memulai dan memantau aplikasi web yang mendasar. systemd adalah sistem init yang menyediakan banyak fitur canggih untuk memulai, menghentikan, dan mengelola proses.

Membuat file layanan

Buat file definisi layanan:

sudo nano /etc/systemd/system/kestrel-helloapp.service

Contoh berikut adalah file layanan untuk aplikasi:

[Unit]
Description=Example .NET Web API App running on Ubuntu

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_NOLOGO=true

[Install]
WantedBy=multi-user.target

Dalam contoh sebelumnya, pengguna yang mengelola layanan ditentukan oleh User opsi . Pengguna (www-data) harus ada dan memiliki kepemilikan file aplikasi yang tepat.

Gunakan TimeoutStopSec untuk mengonfigurasi durasi waktu untuk menunggu aplikasi dimatikan setelah menerima sinyal interupsi awal. Jika aplikasi tidak dimatikan dalam periode ini, SIGKILL dikeluarkan untuk mengakhiri aplikasi. Berikan nilai sebagai detik tanpa unit (misalnya, 150), nilai rentang waktu (misalnya, 2min 30s), atau infinity untuk menonaktifkan batas waktu. TimeoutStopSecdefault ke nilai DefaultTimeoutStopSec dalam file konfigurasi manajer (systemd-system.conf, , system.conf.d, systemd-user.confuser.conf.d). Batas waktu default untuk sebagian besar distribusi adalah 90 detik.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Linux memiliki sistem file peka huruf besar/kecil. Pengaturan ASPNETCORE_ENVIRONMENT untuk Production menghasilkan pencarian file appsettings.Production.jsonkonfigurasi , bukan appsettings.production.json.

Beberapa nilai (misalnya, string koneksi SQL) harus diloloskan agar penyedia konfigurasi membaca variabel lingkungan. Gunakan perintah berikut untuk menghasilkan nilai yang lolos dengan benar untuk digunakan dalam file konfigurasi:

systemd-escape "<value-to-escape>"

Pemisah titik dua (:) tidak didukung dalam nama variabel lingkungan. Gunakan garis bawah ganda (__) sebagai pengganti titik dua. Penyedia konfigurasi Variabel Lingkungan mengonversi garis bawah ganda menjadi titik dua saat variabel lingkungan dibaca ke dalam konfigurasi. Dalam contoh berikut, kunci ConnectionStrings:DefaultConnection string koneksi diatur ke dalam file definisi layanan sebagai ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Simpan file dan aktifkan layanan.

sudo systemctl enable kestrel-helloapp.service

Mulai layanan dan verifikasi bahwa layanan sedang berjalan.

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on Ubuntu
    Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-helloapp.service
            └─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll

Dengan proksi terbalik yang dikonfigurasi dan Kestrel dikelola melalui systemd, aplikasi web sepenuhnya dikonfigurasi dan dapat diakses dari browser di komputer lokal di http://localhost. Ini juga dapat diakses dari komputer jarak jauh, yang melarang firewall apa pun yang mungkin memblokir. Memeriksa header respons, Server header menunjukkan aplikasi ASP.NET Core yang dilayani oleh Kestrel.

HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked

Menampilkan log

Karena aplikasi web yang digunakan Kestrel dikelola menggunakan systemd, semua peristiwa dan proses dicatat ke jurnal terpusat. Namun, jurnal ini mencakup semua entri untuk semua layanan dan proses yang dikelola oleh systemd. Untuk melihat kestrel-helloapp.serviceitem -spesifik, gunakan perintah berikut:

sudo journalctl -fu kestrel-helloapp.service

Untuk pemfilteran lebih lanjut, opsi waktu seperti --since today, --until 1 hour ago, atau kombinasi ini dapat mengurangi jumlah entri yang dikembalikan.

sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"

Perlindungan data

Tumpukan ASP.NET Core Data Protection digunakan oleh beberapa middleware ASP.NET Core, termasuk middleware autentikasi (misalnya, cookie middleware) dan perlindungan pemalsuan permintaan lintas situs (CSRF). Bahkan jika API Perlindungan Data tidak dipanggil oleh kode pengguna, perlindungan data harus dikonfigurasi untuk membuat penyimpanan kunci kriptografi persisten. Jika perlindungan data tidak dikonfigurasi, kunci disimpan di memori dan dibuang saat aplikasi dimulai ulang.

Jika ring kunci disimpan dalam memori saat aplikasi dimulai ulang:

  • Semua token autentikasi berbasis cookie menjadi tidak valid.
  • Pengguna diminta untuk masuk lagi pada permintaan berikutnya.
  • Data apa pun yang dilindungi dengan ring kunci tidak dapat lagi didekripsi. Ini mungkin termasuk token CSRF dan cookie ASP.NET Core MVC TempData.

Untuk mengonfigurasi perlindungan data untuk mempertahankan dan mengenkripsi cincin kunci, lihat:

Bidang header permintaan panjang

Pengaturan default server proksi biasanya membatasi bidang header permintaan menjadi 4 K atau 8 K tergantung pada platform. Aplikasi mungkin memerlukan bidang yang lebih panjang dari default (misalnya, aplikasi yang menggunakan Azure Active Directory). Jika bidang yang lebih panjang diperlukan, pengaturan default server proksi memerlukan penyesuaian. Nilai yang akan diterapkan bergantung pada skenario. Untuk informasi selengkapnya, lihat dokumentasi server Anda.

Peringatan

Jangan tingkatkan nilai default buffer proksi kecuali diperlukan. Meningkatkan nilai-nilai ini meningkatkan risiko serangan buffer overrun (overflow) dan Denial of Service (DoS) oleh pengguna berbahaya.

Mengamankan aplikasi

Aktifkan AppArmor

Linux Security Modules (LSM) adalah kerangka kerja yang merupakan bagian dari kernel Linux sejak Linux 2.6. LSM mendukung berbagai implementasi modul keamanan. AppArmor adalah LSM yang mengimplementasikan sistem Kontrol Akses Wajib, yang memungkinkan pembatasan program ke sekumpulan sumber daya terbatas. Pastikan AppArmor diaktifkan dan dikonfigurasi dengan benar.

Mengonfigurasi firewall

Tutup semua port eksternal yang tidak sedang digunakan. Firewall tidak rumit (ufw) menyediakan ujung depan dengan iptables menyediakan CLI untuk mengonfigurasi firewall.

Peringatan

Firewall akan mencegah akses ke seluruh sistem jika tidak dikonfigurasi dengan benar. Kegagalan untuk menentukan port SSH yang benar akan secara efektif mengunci Anda keluar dari sistem jika Anda menggunakan SSH untuk menyambungkannya. Port default adalah 22. Untuk informasi selengkapnya, lihat pengenalan ufw dan manual.

Instal ufw dan konfigurasikan untuk memungkinkan lalu lintas pada port apa pun yang diperlukan.

sudo apt-get install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

Amankan Nginx

Mengubah nama respons Nginx

Edit src/http/ngx_http_header_filter_module.c:

static char ngx_http_server_string[] = "Server: Web Server" CRLF;
static char ngx_http_server_full_string[] = "Server: Web Server" CRLF;

Mengonfigurasi opsi

Konfigurasikan server dengan modul tambahan yang diperlukan. Pertimbangkan untuk menggunakan firewall aplikasi web, seperti ModSecurity, untuk mengeraskan aplikasi.

Konfigurasi HTTPS

Mengonfigurasi aplikasi untuk koneksi lokal aman (HTTPS)

Perintah jalankan dotnet menggunakan file aplikasiProperties/launchSettings.json, yang mengonfigurasi aplikasi untuk mendengarkan URL yang disediakan oleh applicationUrl properti . Contohnya,https://localhost:5001;http://localhost:5000.

Konfigurasikan aplikasi untuk menggunakan sertifikat dalam pengembangan untuk dotnet run perintah atau lingkungan pengembangan (F5 atau Ctrl+F5 di Visual Studio Code) menggunakan salah satu pendekatan berikut:

Mengonfigurasi proksi terbalik untuk koneksi klien aman (HTTPS)

Peringatan

Konfigurasi keamanan di bagian ini adalah konfigurasi umum yang akan digunakan sebagai titik awal untuk penyesuaian lebih lanjut. Kami tidak dapat memberikan dukungan untuk alat, server, dan sistem operasi pihak ketiga. Gunakan konfigurasi di bagian ini dengan risiko Anda sendiri. Untuk informasi selengkapnya, akses sumber daya berikut:

  • Konfigurasikan server untuk mendengarkan lalu lintas HTTPS pada port 443 dengan menentukan sertifikat valid yang dikeluarkan oleh Otoritas Sertifikat (CA) tepercaya.

  • Perkuat keamanan dengan menggunakan beberapa praktik yang digambarkan dalam file /etc/nginx/nginx.conf berikut.

  • Contoh berikut tidak mengonfigurasi server untuk mengalihkan permintaan yang tidak aman. Sebaiknya gunakan Middleware Pengalihan HTTPS. Untuk informasi selengkapnya, lihat Menerapkan HTTPS di ASP.NET Core.

    Catatan

    Untuk lingkungan pengembangan di mana konfigurasi server menangani pengalihan aman alih-alih Middleware Pengalihan HTTPS, sebaiknya gunakan pengalihan sementara (302) daripada pengalihan permanen (301). Penembolokan tautan dapat menyebabkan perilaku yang tidak stabil di lingkungan pengembangan.

  • Strict-Transport-Security Menambahkan header (HSTS) memastikan semua permintaan berikutnya yang dibuat oleh klien melalui HTTPS. Untuk panduan tentang mengatur Strict-Transport-Security header, lihat Menerapkan HTTPS di ASP.NET Core.

  • Jika HTTPS akan dinonaktifkan di masa mendatang, gunakan salah satu pendekatan berikut:

    • Jangan tambahkan header HSTS.
    • Pilih nilai pendek max-age .

Tambahkan file konfigurasi /etc/nginx/proxy.conf:

proxy_redirect          off;
proxy_set_header        Host $host;
proxy_set_header        X-Real-IP $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header        X-Forwarded-Proto $scheme;
client_max_body_size    10m;
client_body_buffer_size 128k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffers           32 4k;

Ganti konten file konfigurasi /etc/nginx/nginx.conf dengan file berikut. Contoh berisi bagian http dan server dalam satu file konfigurasi.

http {
    include        /etc/nginx/proxy.conf;
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
    server_tokens  off;

    sendfile on;
    # Adjust keepalive_timeout to the lowest possible value that makes sense 
    # for your use case.
    keepalive_timeout   29;
    client_body_timeout 10; client_header_timeout 10; send_timeout 10;

    upstream helloapp{
        server 127.0.0.1:5000;
    }

    server {
        listen                    443 ssl http2;
        listen                    [::]:443 ssl http2;
        server_name               example.com *.example.com;
        ssl_certificate           /etc/ssl/certs/testCert.crt;
        ssl_certificate_key       /etc/ssl/certs/testCert.key;
        ssl_session_timeout       1d;
        ssl_protocols             TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers off;
        ssl_ciphers               ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
        ssl_session_cache         shared:SSL:10m;
        ssl_session_tickets       off;
        ssl_stapling              off;

        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;

        #Redirects all traffic
        location / {
            proxy_pass http://helloapp;
            limit_req  zone=one burst=10 nodelay;
        }
    }
}

Catatan

Blazor WebAssembly aplikasi memerlukan nilai parameter yang lebih besar burst untuk mengakomodasi jumlah permintaan yang lebih besar yang dibuat oleh aplikasi. Untuk informasi selengkapnya, lihat Host dan sebarkan ASP.NET Core Blazor WebAssembly.

Catatan

Contoh sebelumnya menonaktifkan Stapling Protokol Status Sertifikat Online (OCSP). Jika diaktifkan, konfirmasikan bahwa sertifikat mendukung fitur tersebut. Untuk informasi dan panduan selengkapnya tentang mengaktifkan OCSP, lihat properti berikut ini di artikel Modul ngx_http_ssl_module (dokumentasi Nginx):

  • ssl_stapling
  • ssl_stapling_file
  • ssl_stapling_responder
  • ssl_stapling_verify

Amankan Nginx dari pembajakan klik

Clickjacking, juga dikenal sebagai serangan redress UI, adalah serangan berbahaya di mana pengunjung situs web ditipu untuk mengklik tautan atau tombol di halaman yang berbeda dari yang saat ini mereka kunjungi. Gunakan X-FRAME-OPTIONS untuk mengamankan situs.

Untuk mengurangi serangan pembajakan klik:

  1. Edit file nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    Tambahkan baris: add_header X-Frame-Options "SAMEORIGIN";

  2. Simpan file.

  3. Mulai ulang Nginx.

Sniffing jenis MIME

Header ini mencegah sebagian besar browser dari MIME-mengendus respons dari jenis konten yang dideklarasikan, karena header menginstruksikan browser untuk tidak mengambil alih jenis konten respons. nosniff Dengan opsi , jika server mengatakan kontennya adalah text/html, browser merendernya sebagai text/html.

  1. Edit file nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    Tambahkan baris: add_header X-Content-Type-Options "nosniff";

  2. Simpan file.

  3. Mulai ulang Nginx.

Saran Nginx tambahan

Setelah meningkatkan kerangka kerja bersama di server, mulai ulang aplikasi ASP.NET Core yang dihosting oleh server.

Sumber Daya Tambahan:

Panduan ini menjelaskan pengaturan lingkungan ASP.NET Core siap produksi di server Ubuntu 16.04. Instruksi ini kemungkinan berfungsi dengan versi Ubuntu yang lebih baru, tetapi instruksi belum diuji dengan versi yang lebih baru.

Untuk informasi tentang distribusi Linux lain yang didukung oleh ASP.NET Core, lihat Prasyarat untuk .NET Core di Linux.

Catatan

Untuk Ubuntu 14.04, supervisord disarankan sebagai solusi untuk memantau Kestrel proses. systemd tidak tersedia di Ubuntu 14.04. Untuk instruksi Ubuntu 14.04, lihat versi topik ini sebelumnya.

Panduan ini:

  • Menempatkan aplikasi ASP.NET Core yang ada di belakang server proksi terbalik.
  • Menyiapkan server proksi terbalik untuk meneruskan permintaan ke Kestrel server web.
  • Memastikan aplikasi web berjalan pada startup sebagai daemon.
  • Mengonfigurasi alat manajemen proses untuk membantu memulai ulang aplikasi web.

Prasyarat

  • Akses ke server Ubuntu 16.04 dengan akun pengguna standar dengan hak istimewa sudo.
  • Runtime .NET non-pratinjau terbaru terinstal di server.
  • Aplikasi ASP.NET Core yang ada.

Kapan saja di masa mendatang setelah meningkatkan kerangka kerja bersama, mulai ulang aplikasi ASP.NET Core yang dihosting oleh server.

Menerbitkan dan menyalin melalui aplikasi

Konfigurasikan aplikasi untuk penyebaran yang bergantung pada kerangka kerja.

Jika aplikasi dijalankan secara lokal di lingkungan Pengembangan dan tidak dikonfigurasi oleh server untuk membuat koneksi HTTPS yang aman, adopsi salah satu pendekatan berikut:

  • Konfigurasikan aplikasi untuk menangani koneksi lokal yang aman. Untuk informasi selengkapnya, lihat bagian konfigurasi HTTPS.

  • Konfigurasikan aplikasi untuk dijalankan di titik akhir yang tidak aman:

    • Nonaktifkan Middleware Pengalihan HTTPS di lingkungan Pengembangan (Program.cs):

      if (!app.Environment.IsDevelopment())
      {
          app.UseHttpsRedirection();
      }
      

      Untuk informasi lebih lanjut, lihat Menggunakan beberapa lingkungan di ASP.NET Core.

    • Hapus https://localhost:5001 (jika ada) dari applicationUrl properti dalam Properties/launchSettings.json file.

Untuk informasi selengkapnya tentang konfigurasi menurut lingkungan, lihat Menggunakan beberapa lingkungan di ASP.NET Core.

Jalankan penerbitan dotnet dari lingkungan pengembangan untuk mengemas aplikasi ke dalam direktori (misalnya, bin/Release/{TARGET FRAMEWORK MONIKER}/publish, di mana tempat penampung {TARGET FRAMEWORK MONIKER} adalah Target Framework Moniker/TFM) yang dapat berjalan di server:

dotnet publish --configuration Release

Aplikasi ini juga dapat diterbitkan sebagai penyebaran mandiri jika Anda lebih suka tidak mempertahankan runtime .NET Core di server.

Salin aplikasi ASP.NET Core ke server menggunakan alat yang terintegrasi ke dalam alur kerja organisasi (misalnya, SCP, SFTP). Adalah umum untuk menemukan aplikasi web di var bawah direktori (misalnya, var/www/helloapp).

Catatan

Di bawah skenario penyebaran produksi, alur kerja integrasi berkelanjutan melakukan pekerjaan menerbitkan aplikasi dan menyalin aset ke server.

Uji aplikasi:

  1. Dari baris perintah, jalankan aplikasi: dotnet <app_assembly>.dll.
  2. Di browser, buka untuk http://<serveraddress>:<port> memverifikasi bahwa aplikasi berfungsi di Linux secara lokal.

Mengonfigurasi server proksi terbalik

Proksi terbalik adalah penyiapan umum untuk melayani aplikasi web dinamis. Proksi terbalik mengakhiri permintaan HTTP dan meneruskannya ke aplikasi ASP.NET Core.

Menggunakan server proksi terbalik

Kestrel sangat bagus untuk menyajikan konten dinamis dari ASP.NET Core. Namun, kemampuan penyajian web tidak kaya fitur seperti server seperti IIS, Apache, atau Nginx. Server proksi terbalik dapat membongkar pekerjaan seperti menyajikan konten statis, permintaan penembolokan, permintaan pemadatan, dan penghentian HTTPS dari server HTTP. Server proksi terbalik dapat berada di komputer khusus atau dapat disebarkan bersama server HTTP.

Untuk tujuan panduan ini, satu instans Nginx digunakan. Ini berjalan pada server yang sama, bersama dengan server HTTP. Berdasarkan persyaratan, pengaturan yang berbeda dapat dipilih.

Karena permintaan diteruskan oleh proksi terbalik, gunakan Middleware Header yang Diteruskan dari Microsoft.AspNetCore.HttpOverrides paket. Middleware memperbarui Request.Scheme, menggunakan X-Forwarded-Proto header, sehingga URI pengalihan dan kebijakan keamanan lainnya berfungsi dengan benar.

Middleware Header yang Diteruskan harus dijalankan sebelum middleware lainnya. Urutan ini memastikan bahwa middleware yang mengandalkan informasi header yang diteruskan dapat menggunakan nilai header untuk pemrosesan. Untuk menjalankan Middleware Header yang Diteruskan setelah middleware diagnostik dan penanganan kesalahan, lihat Urutan Middleware Header yang Diteruskan.

Panggil UseForwardedHeaders metode di bagian Startup.Configure atas sebelum memanggil middleware lainnya. Konfigurasikan middleware untuk meneruskan X-Forwarded-For header dan X-Forwarded-Proto :

using Microsoft.AspNetCore.HttpOverrides;

...

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

Jika tidak ForwardedHeadersOptions ditentukan ke middleware, header default yang akan diteruskan adalah None.

Proksi yang berjalan pada alamat loopback (127.0.0.0/8, [::1]), termasuk alamat localhost standar (127.0.0.1), dipercaya secara default. Jika proksi atau jaringan tepercaya lainnya dalam organisasi menangani permintaan antara Internet dan server web, tambahkan ke daftar KnownProxies atau KnownNetworks dengan ForwardedHeadersOptions. Contoh berikut menambahkan server proksi tepercaya di alamat IP 10.0.0.100 ke Middleware KnownProxies Header yang Diteruskan di Startup.ConfigureServices:

using System.Net;

...

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

Untuk informasi selengkapnya, lihat Mengonfigurasi ASP.NET Core untuk bekerja dengan server proxy dan memuat penyeimbang.

Menginstal Nginx

Gunakan apt-get untuk menginstal Nginx. Alat penginstal systemd membuat skrip init yang menjalankan Nginx sebagai daemon pada startup sistem. Ikuti petunjuk penginstalan untuk Ubuntu di Nginx: Paket Resmi Debian/Ubuntu.

Catatan

Jika modul Nginx opsional diperlukan, membangun Nginx dari sumber mungkin diperlukan.

Karena Nginx diinstal untuk pertama kalinya, secara eksplisit memulainya dengan menjalankan:

sudo service nginx start

Verifikasi browser menampilkan halaman arahan default untuk Nginx. Halaman arahan dapat dijangkau di http://<server_IP_address>/index.nginx-debian.html.

Mengonfigurasi Nginx

Untuk mengonfigurasi Nginx sebagai proksi terbalik untuk meneruskan permintaan HTTP ke aplikasi ASP.NET Core Anda, ubah /etc/nginx/sites-available/default. Buka di editor teks, dan ganti konten dengan cuplikan berikut:

server {
    listen        80;
    server_name   example.com *.example.com;
    location / {
        proxy_pass         http://127.0.0.1:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

Jika aplikasi adalah SignalR aplikasi atauBlazor Server, lihat hosting produksi ASP.NET Core SignalR dan penskalaan dan Host dan sebarkan aplikasi sisi Blazor server ASP.NET Core masing-masing untuk informasi selengkapnya.

Ketika tidak ada server_name kecocokan, Nginx menggunakan server default. Jika tidak ada server default yang ditentukan, server pertama dalam file konfigurasi adalah server default. Sebagai praktik terbaik, tambahkan server default tertentu yang mengembalikan kode status 444 dalam file konfigurasi Anda. Contoh konfigurasi server default adalah:

server {
    listen   80 default_server;
    # listen [::]:80 default_server deferred;
    return   444;
}

Dengan file konfigurasi sebelumnya dan server default, Nginx menerima lalu lintas publik pada port 80 dengan header example.com host atau *.example.com. Permintaan yang tidak cocok dengan host ini tidak akan diteruskan ke Kestrel. Nginx meneruskan permintaan yang cocok ke Kestrel di http://127.0.0.1:5000. Untuk informasi selengkapnya, lihat Cara nginx memproses permintaan. Untuk mengubah KestrelIP/port, lihat Kestrel: Konfigurasi titik akhir.

Peringatan

Kegagalan untuk menentukan arahan server_name yang tepat mengekspos aplikasi Anda terhadap kerentanan keamanan. Pengikatan wildcard subdomain (misalnya, *.example.com) tidak menimbulkan risiko keamanan ini jika Anda mengontrol seluruh domain induk ( *.comdibandingkan dengan , yang rentan). Untuk informasi selengkapnya, lihat RFC 9110: Semantik HTTP (Bagian 7.2: Host dan :authority).

Setelah konfigurasi Nginx dibuat, jalankan sudo nginx -t untuk memverifikasi sintaks file konfigurasi. Jika pengujian file konfigurasi berhasil, paksa Nginx untuk mengambil perubahan dengan menjalankan sudo nginx -s reload.

Untuk langsung menjalankan aplikasi di server:

  1. Navigasi ke direktori aplikasi.
  2. Jalankan aplikasi: dotnet <app_assembly.dll>, di mana app_assembly.dll adalah nama file rakitan aplikasi.

Jika aplikasi berjalan di server tetapi gagal merespons melalui Internet, periksa firewall server dan konfirmasi port 80 terbuka. Jika menggunakan Azure Ubuntu VM, tambahkan aturan Network Security Group (NSG) yang memungkinkan lalu lintas port masuk 80. Tidak perlu mengaktifkan aturan port keluar 80, karena lalu lintas keluar secara otomatis diberikan saat aturan masuk diaktifkan.

Setelah selesai menguji aplikasi, matikan aplikasi dengan Ctrl+C (Windows) atau ⌘+C (macOS) di prompt perintah.

Memantau aplikasi

Server disiapkan untuk meneruskan permintaan yang dibuat ke http://<serveraddress>:80 aplikasi ASP.NET Core yang berjalan di Kestrelhttp://127.0.0.1:5000. Namun, Nginx tidak disiapkan untuk mengelola proses.Kestrel systemd dapat digunakan untuk membuat file layanan untuk memulai dan memantau aplikasi web yang mendasar. systemd adalah sistem init yang menyediakan banyak fitur canggih untuk memulai, menghentikan, dan mengelola proses.

Membuat file layanan

Buat file definisi layanan:

sudo nano /etc/systemd/system/kestrel-helloapp.service

Contoh berikut adalah file layanan untuk aplikasi:

[Unit]
Description=Example .NET Web API App running on Ubuntu

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

Dalam contoh sebelumnya, pengguna yang mengelola layanan ditentukan oleh User opsi . Pengguna (www-data) harus ada dan memiliki kepemilikan file aplikasi yang tepat.

Gunakan TimeoutStopSec untuk mengonfigurasi durasi waktu untuk menunggu aplikasi dimatikan setelah menerima sinyal interupsi awal. Jika aplikasi tidak dimatikan dalam periode ini, SIGKILL dikeluarkan untuk mengakhiri aplikasi. Berikan nilai sebagai detik tanpa unit (misalnya, 150), nilai rentang waktu (misalnya, 2min 30s), atau infinity untuk menonaktifkan batas waktu. TimeoutStopSecdefault ke nilai DefaultTimeoutStopSec dalam file konfigurasi manajer (systemd-system.conf, , system.conf.d, systemd-user.confuser.conf.d). Batas waktu default untuk sebagian besar distribusi adalah 90 detik.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Linux memiliki sistem file peka huruf besar/kecil. Pengaturan ASPNETCORE_ENVIRONMENT untuk Production menghasilkan pencarian file appsettings.Production.jsonkonfigurasi , bukan appsettings.production.json.

Beberapa nilai (misalnya, string koneksi SQL) harus diloloskan agar penyedia konfigurasi membaca variabel lingkungan. Gunakan perintah berikut untuk menghasilkan nilai yang lolos dengan benar untuk digunakan dalam file konfigurasi:

systemd-escape "<value-to-escape>"

Pemisah titik dua (:) tidak didukung dalam nama variabel lingkungan. Gunakan garis bawah ganda (__) sebagai pengganti titik dua. Penyedia konfigurasi Variabel Lingkungan mengonversi garis bawah ganda menjadi titik dua saat variabel lingkungan dibaca ke dalam konfigurasi. Dalam contoh berikut, kunci ConnectionStrings:DefaultConnection string koneksi diatur ke dalam file definisi layanan sebagai ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Simpan file dan aktifkan layanan.

sudo systemctl enable kestrel-helloapp.service

Mulai layanan dan verifikasi bahwa layanan sedang berjalan.

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on Ubuntu
    Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-helloapp.service
            └─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll

Dengan proksi terbalik yang dikonfigurasi dan Kestrel dikelola melalui systemd, aplikasi web sepenuhnya dikonfigurasi dan dapat diakses dari browser di komputer lokal di http://localhost. Ini juga dapat diakses dari komputer jarak jauh, yang melarang firewall apa pun yang mungkin memblokir. Memeriksa header respons, Server header menunjukkan aplikasi ASP.NET Core yang dilayani oleh Kestrel.

HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked

Menampilkan log

Karena aplikasi web yang digunakan Kestrel dikelola menggunakan systemd, semua peristiwa dan proses dicatat ke jurnal terpusat. Namun, jurnal ini mencakup semua entri untuk semua layanan dan proses yang dikelola oleh systemd. Untuk melihat kestrel-helloapp.serviceitem -spesifik, gunakan perintah berikut:

sudo journalctl -fu kestrel-helloapp.service

Untuk pemfilteran lebih lanjut, opsi waktu seperti --since today, --until 1 hour ago, atau kombinasi ini dapat mengurangi jumlah entri yang dikembalikan.

sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"

Perlindungan data

Tumpukan ASP.NET Core Data Protection digunakan oleh beberapa middleware ASP.NET Core, termasuk middleware autentikasi (misalnya, cookie middleware) dan perlindungan pemalsuan permintaan lintas situs (CSRF). Bahkan jika API Perlindungan Data tidak dipanggil oleh kode pengguna, perlindungan data harus dikonfigurasi untuk membuat penyimpanan kunci kriptografi persisten. Jika perlindungan data tidak dikonfigurasi, kunci disimpan di memori dan dibuang saat aplikasi dimulai ulang.

Jika ring kunci disimpan dalam memori saat aplikasi dimulai ulang:

  • Semua token autentikasi berbasis cookie menjadi tidak valid.
  • Pengguna diminta untuk masuk lagi pada permintaan berikutnya.
  • Data apa pun yang dilindungi dengan ring kunci tidak dapat lagi didekripsi. Ini mungkin termasuk token CSRF dan cookie ASP.NET Core MVC TempData.

Untuk mengonfigurasi perlindungan data untuk mempertahankan dan mengenkripsi cincin kunci, lihat:

Bidang header permintaan panjang

Pengaturan default server proksi biasanya membatasi bidang header permintaan menjadi 4 K atau 8 K tergantung pada platform. Aplikasi mungkin memerlukan bidang yang lebih panjang dari default (misalnya, aplikasi yang menggunakan Azure Active Directory). Jika bidang yang lebih panjang diperlukan, pengaturan default server proksi memerlukan penyesuaian. Nilai yang akan diterapkan bergantung pada skenario. Untuk informasi selengkapnya, lihat dokumentasi server Anda.

Peringatan

Jangan tingkatkan nilai default buffer proksi kecuali diperlukan. Meningkatkan nilai-nilai ini meningkatkan risiko serangan buffer overrun (overflow) dan Denial of Service (DoS) oleh pengguna berbahaya.

Mengamankan aplikasi

Aktifkan AppArmor

Linux Security Modules (LSM) adalah kerangka kerja yang merupakan bagian dari kernel Linux sejak Linux 2.6. LSM mendukung berbagai implementasi modul keamanan. AppArmor adalah LSM yang mengimplementasikan sistem Kontrol Akses Wajib, yang memungkinkan pembatasan program ke sekumpulan sumber daya terbatas. Pastikan AppArmor diaktifkan dan dikonfigurasi dengan benar.

Mengonfigurasi firewall

Tutup semua port eksternal yang tidak sedang digunakan. Firewall tidak rumit (ufw) menyediakan ujung depan dengan iptables menyediakan CLI untuk mengonfigurasi firewall.

Peringatan

Firewall akan mencegah akses ke seluruh sistem jika tidak dikonfigurasi dengan benar. Kegagalan untuk menentukan port SSH yang benar akan secara efektif mengunci Anda keluar dari sistem jika Anda menggunakan SSH untuk menyambungkannya. Port default adalah 22. Untuk informasi selengkapnya, lihat pengenalan ufw dan manual.

Instal ufw dan konfigurasikan untuk memungkinkan lalu lintas pada port apa pun yang diperlukan.

sudo apt-get install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

Amankan Nginx

Mengubah nama respons Nginx

Edit src/http/ngx_http_header_filter_module.c:

static char ngx_http_server_string[] = "Server: Web Server" CRLF;
static char ngx_http_server_full_string[] = "Server: Web Server" CRLF;

Mengonfigurasi opsi

Konfigurasikan server dengan modul tambahan yang diperlukan. Pertimbangkan untuk menggunakan firewall aplikasi web, seperti ModSecurity, untuk mengeraskan aplikasi.

Konfigurasi HTTPS

Mengonfigurasi aplikasi untuk koneksi lokal aman (HTTPS)

Perintah jalankan dotnet menggunakan file aplikasiProperties/launchSettings.json, yang mengonfigurasi aplikasi untuk mendengarkan URL yang disediakan oleh applicationUrl properti . Contohnya,https://localhost:5001;http://localhost:5000.

Konfigurasikan aplikasi untuk menggunakan sertifikat dalam pengembangan untuk dotnet run perintah atau lingkungan pengembangan (F5 atau Ctrl+F5 di Visual Studio Code) menggunakan salah satu pendekatan berikut:

Mengonfigurasi proksi terbalik untuk koneksi klien aman (HTTPS)

Peringatan

Konfigurasi keamanan di bagian ini adalah konfigurasi umum yang akan digunakan sebagai titik awal untuk penyesuaian lebih lanjut. Kami tidak dapat memberikan dukungan untuk alat, server, dan sistem operasi pihak ketiga. Gunakan konfigurasi di bagian ini dengan risiko Anda sendiri. Untuk informasi selengkapnya, akses sumber daya berikut:

  • Konfigurasikan server untuk mendengarkan lalu lintas HTTPS pada port 443 dengan menentukan sertifikat valid yang dikeluarkan oleh Otoritas Sertifikat (CA) tepercaya.

  • Perkuat keamanan dengan menggunakan beberapa praktik yang digambarkan dalam file /etc/nginx/nginx.conf berikut.

  • Contoh berikut tidak mengonfigurasi server untuk mengalihkan permintaan yang tidak aman. Sebaiknya gunakan Middleware Pengalihan HTTPS. Untuk informasi selengkapnya, lihat Menerapkan HTTPS di ASP.NET Core.

    Catatan

    Untuk lingkungan pengembangan di mana konfigurasi server menangani pengalihan aman alih-alih Middleware Pengalihan HTTPS, sebaiknya gunakan pengalihan sementara (302) daripada pengalihan permanen (301). Penembolokan tautan dapat menyebabkan perilaku yang tidak stabil di lingkungan pengembangan.

  • Strict-Transport-Security Menambahkan header (HSTS) memastikan semua permintaan berikutnya yang dibuat oleh klien melalui HTTPS. Untuk panduan tentang mengatur Strict-Transport-Security header, lihat Menerapkan HTTPS di ASP.NET Core.

  • Jika HTTPS akan dinonaktifkan di masa mendatang, gunakan salah satu pendekatan berikut:

    • Jangan tambahkan header HSTS.
    • Pilih nilai pendek max-age .

Tambahkan file konfigurasi /etc/nginx/proxy.conf:

proxy_redirect          off;
proxy_set_header        Host $host;
proxy_set_header        X-Real-IP $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header        X-Forwarded-Proto $scheme;
client_max_body_size    10m;
client_body_buffer_size 128k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffers           32 4k;

Ganti konten file konfigurasi /etc/nginx/nginx.conf dengan file berikut. Contoh berisi bagian http dan server dalam satu file konfigurasi.

http {
    include        /etc/nginx/proxy.conf;
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
    server_tokens  off;

    sendfile on;
    # Adjust keepalive_timeout to the lowest possible value that makes sense 
    # for your use case.
    keepalive_timeout   29;
    client_body_timeout 10; client_header_timeout 10; send_timeout 10;

    upstream helloapp{
        server 127.0.0.1:5000;
    }

    server {
        listen                    443 ssl http2;
        listen                    [::]:443 ssl http2;
        server_name               example.com *.example.com;
        ssl_certificate           /etc/ssl/certs/testCert.crt;
        ssl_certificate_key       /etc/ssl/certs/testCert.key;
        ssl_session_timeout       1d;
        ssl_protocols             TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers off;
        ssl_ciphers               ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
        ssl_session_cache         shared:SSL:10m;
        ssl_session_tickets       off;
        ssl_stapling              off;

        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;

        #Redirects all traffic
        location / {
            proxy_pass http://helloapp;
            limit_req  zone=one burst=10 nodelay;
        }
    }
}

Catatan

Blazor WebAssembly aplikasi memerlukan nilai parameter yang lebih besar burst untuk mengakomodasi jumlah permintaan yang lebih besar yang dibuat oleh aplikasi. Untuk informasi selengkapnya, lihat Host dan sebarkan ASP.NET Core Blazor WebAssembly.

Catatan

Contoh sebelumnya menonaktifkan Stapling Protokol Status Sertifikat Online (OCSP). Jika diaktifkan, konfirmasikan bahwa sertifikat mendukung fitur tersebut. Untuk informasi dan panduan selengkapnya tentang mengaktifkan OCSP, lihat properti berikut ini di artikel Modul ngx_http_ssl_module (dokumentasi Nginx):

  • ssl_stapling
  • ssl_stapling_file
  • ssl_stapling_responder
  • ssl_stapling_verify

Amankan Nginx dari pembajakan klik

Clickjacking, juga dikenal sebagai serangan redress UI, adalah serangan berbahaya di mana pengunjung situs web ditipu untuk mengklik tautan atau tombol di halaman yang berbeda dari yang saat ini mereka kunjungi. Gunakan X-FRAME-OPTIONS untuk mengamankan situs.

Untuk mengurangi serangan pembajakan klik:

  1. Edit file nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    Tambahkan baris: add_header X-Frame-Options "SAMEORIGIN";

  2. Simpan file.

  3. Mulai ulang Nginx.

Sniffing jenis MIME

Header ini mencegah sebagian besar browser dari MIME-mengendus respons dari jenis konten yang dideklarasikan, karena header menginstruksikan browser untuk tidak mengambil alih jenis konten respons. nosniff Dengan opsi , jika server mengatakan kontennya adalah text/html, browser merendernya sebagai text/html.

  1. Edit file nginx.conf:

    sudo nano /etc/nginx/nginx.conf
    

    Tambahkan baris: add_header X-Content-Type-Options "nosniff";

  2. Simpan file.

  3. Mulai ulang Nginx.

Saran Nginx tambahan

Setelah meningkatkan kerangka kerja bersama di server, mulai ulang aplikasi ASP.NET Core yang dihosting oleh server.

Sumber Daya Tambahan: