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.
Peringatan
Versi ASP.NET Core ini tidak lagi didukung. Untuk informasi selengkapnya, lihat Kebijakan Dukungan .NET dan .NET Core. 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) dariapplicationUrl
properti dalamProperties/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:
- Dari baris perintah, jalankan aplikasi:
dotnet <app_assembly>.dll
. - 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 KnownProxies
Header 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 ( *.com
dibandingkan 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:
- Navigasi ke direktori aplikasi.
- Jalankan aplikasi:
dotnet <app_assembly.dll>
, di manaapp_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 Kestrel http://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. TimeoutStopSec
default ke nilai DefaultTimeoutStopSec
dalam file konfigurasi manajer (systemd-system.conf
, , system.conf.d
, systemd-user.conf
user.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.json
konfigurasi , 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.service
item -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:
- Penyedia penyimpanan utama di ASP.NET Core
- Enkripsi kunci di rest Windows dan Azure menggunakan ASP.NET Core
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:
- Mengonfigurasi server HTTPS (dokumentasi Nginx)
- Generator Konfigurasi SSL mozilla.org
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 mengaturStrict-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:
Edit file nginx.conf:
sudo nano /etc/nginx/nginx.conf
http{}
Dalam blok kode, tambahkan baris:add_header X-Frame-Options "SAMEORIGIN";
Simpan file.
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
.
Edit file nginx.conf:
sudo nano /etc/nginx/nginx.conf
http{}
Dalam blok kode, tambahkan baris:add_header X-Content-Type-Options "nosniff";
Simpan file.
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) dariapplicationUrl
properti dalamProperties/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:
- Dari baris perintah, jalankan aplikasi:
dotnet <app_assembly>.dll
. - 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 ( *.com
dibandingkan 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:
- Navigasi ke direktori aplikasi.
- Jalankan aplikasi:
dotnet <app_assembly.dll>
, di manaapp_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 Kestrel http://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. TimeoutStopSec
default ke nilai DefaultTimeoutStopSec
dalam file konfigurasi manajer (systemd-system.conf
, , system.conf.d
, systemd-user.conf
user.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.json
konfigurasi , 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.service
item -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:
- Penyedia penyimpanan utama di ASP.NET Core
- Enkripsi kunci di rest Windows dan Azure menggunakan ASP.NET Core
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:
- Mengonfigurasi server HTTPS (dokumentasi Nginx)
- Generator Konfigurasi SSL mozilla.org
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 mengaturStrict-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:
Edit file nginx.conf:
sudo nano /etc/nginx/nginx.conf
Tambahkan baris:
add_header X-Frame-Options "SAMEORIGIN";
Simpan file.
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
.
Edit file nginx.conf:
sudo nano /etc/nginx/nginx.conf
Tambahkan baris:
add_header X-Content-Type-Options "nosniff";
Simpan file.
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) dariapplicationUrl
properti dalamProperties/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:
- Dari baris perintah, jalankan aplikasi:
dotnet <app_assembly>.dll
. - 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 ( *.com
dibandingkan 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:
- Navigasi ke direktori aplikasi.
- Jalankan aplikasi:
dotnet <app_assembly.dll>
, di manaapp_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 Kestrel http://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. TimeoutStopSec
default ke nilai DefaultTimeoutStopSec
dalam file konfigurasi manajer (systemd-system.conf
, , system.conf.d
, systemd-user.conf
user.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.json
konfigurasi , 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.service
item -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:
- Penyedia penyimpanan utama di ASP.NET Core
- Enkripsi kunci di rest Windows dan Azure menggunakan ASP.NET Core
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:
- Mengonfigurasi server HTTPS (dokumentasi Nginx)
- Generator Konfigurasi SSL mozilla.org
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 mengaturStrict-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:
Edit file nginx.conf:
sudo nano /etc/nginx/nginx.conf
Tambahkan baris:
add_header X-Frame-Options "SAMEORIGIN";
Simpan file.
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
.
Edit file nginx.conf:
sudo nano /etc/nginx/nginx.conf
Tambahkan baris:
add_header X-Content-Type-Options "nosniff";
Simpan file.
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:
ASP.NET Core