Nginx ile Linux üzerinde ASP.NET Core Barındırma

Sourabh Shirhatti tarafından

Bu kılavuzda Ubuntu, Red Hat Enterprise (RHEL) ve SUSE Linux Enterprise Server için üretime hazır ASP.NET Core ortamı ayarlama işlemi açıklanmaktadır.

ASP.NET Core tarafından desteklenen diğer Linux dağıtımları hakkında bilgi için bkz . Linux üzerinde .NET Core önkoşulları.

Bu kılavuz:

• Mevcut bir ASP.NET Core uygulamasını ters ara sunucunun arkasına yerleştirir.
• İstekleri Kestrel web sunucusuna iletmek için ters ara sunucuyu ayarlar.
• Web uygulamasının başlatma sırasında bir daemon olarak çalışmasını sağlar.
• Web uygulamasını yeniden başlatmaya yardımcı olmak için bir işlem yönetim aracı yapılandırılır.

Önkoşullar

Ubuntu

• Sudo ayrıcalığına sahip standart bir kullanıcı hesabıyla Ubuntu 20.04'e erişim.
• Sunucuda yüklü en son kararlı .NET çalışma zamanı.
• Mevcut bir ASP.NET Core uygulaması.

Red Hat Enterprise Linux

• Red Hat Enterprise (RHEL) 8.0 veya üzeri sürümlere sudo ayrıcalığına sahip standart bir kullanıcı hesabıyla erişim.
• Sunucuda yüklü en son kararlı .NET çalışma zamanı.
• Mevcut bir ASP.NET Core uygulaması.

SUSE Linux Enterprise Server

• Sudo ayrıcalığına sahip standart bir kullanıcı hesabıyla SLES 12 veya 15'e erişim.
• Sunucuda yüklü en son kararlı .NET çalışma zamanı.
• Mevcut bir ASP.NET Core uygulaması.

Paylaşılan çerçeveyi yükselttikten sonra gelecekte herhangi bir noktada, sunucu tarafından barındırılan ASP.NET Core uygulamalarını yeniden başlatın.

Uygulama üzerinde yayımlama ve kopyalama

Uygulamayı çerçeveye bağımlı bir dağıtım için yapılandırın.

Uygulama Geliştirme ortamında yerel olarak çalıştırılıyorsa ve sunucu tarafından güvenli HTTPS bağlantıları yapacak şekilde yapılandırılmamışsa, aşağıdaki yaklaşımlardan birini benimseyin:

• Uygulamayı güvenli yerel bağlantıları işleyecek şekilde yapılandırın. Daha fazla bilgi için HTTPS yapılandırma bölümüne bakın.

• Uygulamayı güvenli olmayan uç noktada çalışacak şekilde yapılandırın:

  • Geliştirme ortamında HTTPS Yeniden Yönlendirme Ara Yazılımını devre dışı bırakın (Program.cs):

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

    Daha fazla bilgi için, bkz. ASP.NET Core'da birden çok ortam kullanma.

  • Dosyadaki applicationUrlProperties/launchSettings.json özelliğinden (varsa) kaldırın https://localhost:5001 .

Ortama göre yapılandırma hakkında daha fazla bilgi için bkz . ASP.NET Core'da birden çok ortam kullanma.

Bir uygulamayı sunucuda çalıştırabilen bir dizine (örneğin, bin/Release/{TARGET FRAMEWORK MONIKER}/publishyer tutucunun Hedef Çerçeve Adı (TFM) olduğu{TARGET FRAMEWORK MONIKER}) paketlemek için geliştirme ortamından dotnet publish komutunu çalıştırın:

dotnet publish --configuration Release

Uygulama, sunucuda .NET Core çalışma zamanını korumayı tercih ediyorsanız bağımsız dağıtım olarak da yayımlanabilir.

kuruluşun iş akışıyla tümleşen bir araç kullanarak ASP.NET Core uygulamasını sunucuya kopyalayın (örneğin, , SCPSFTP). Web uygulamalarını dizin altında var (örneğin, var/www/helloapp) bulmak yaygın olarak görülür.

Not

Üretim dağıtım senaryosunda sürekli tümleştirme iş akışı, uygulamayı yayımlama ve varlıkları sunucuya kopyalama işini yapar.

Uygulamayı test edin:

1. Komut satırından uygulamayı çalıştırın: dotnet <app_assembly>.dll.
2. Tarayıcıda, uygulamanın Linux'ta yerel olarak çalıştığını doğrulamak için adresine gidin http://<serveraddress>:<port> .

Ters ara sunucu yapılandırma

Ters ara sunucu, dinamik web uygulamalarına hizmet veren yaygın bir kurulumdur. Ters ara sunucu HTTP isteğini sonlandırır ve ASP.NET Core uygulamasına iletir.

Ters ara sunucu kullanma

Kestrel ASP.NET Core'dan dinamik içerik sunma açısından idealdir. Ancak web hizmeti özellikleri IIS, Apache veya Nginx gibi sunucular kadar zengin özelliklere sahip değildir. Ters ara sunucu, http sunucusundan statik içerik sunma, istekleri önbelleğe alma, istekleri sıkıştırma ve HTTPS sonlandırma gibi işleri boşaltabilir. Ters ara sunucu, ayrılmış bir makinede bulunabilir veya bir HTTP sunucusuyla birlikte dağıtılabilir.

Bu kılavuzun amaçları doğrultusunda tek bir Nginx örneği kullanılır. HTTP sunucusuyla birlikte aynı sunucuda çalışır. Gereksinimlere göre farklı bir kurulum seçilebilir.

İstekler ters ara sunucu tarafından iletildiğinden, paylaşılan çerçevenin Microsoft.AspNetCore.App meta paketi aracılığıyla ASP.NET Core uygulamalarına otomatik olarak eklenen paketten Microsoft.AspNetCore.HttpOverrides İletilen Üst Bilgiler Ara Yazılımını kullanın. Ara yazılım, yeniden yönlendirme URI'lerinin ve diğer güvenlik ilkelerinin X-Forwarded-Proto düzgün çalışması için üst bilgisini kullanarak öğesini güncelleştirirRequest.Scheme.

İletilen Üst Bilgiler Ara Yazılımı diğer ara yazılımlardan önce çalıştırılmalıdır. Bu sıralama, iletilen üst bilgilere dayalı ara yazılımların işlemek üzere üst bilgi değerlerini kullanabilmesini sağlar. İletilen Üst Bilgiler Ara Yazılımını tanılamalar ve hata işleme ara yazılımından sonra çalıştırmak için bkz. İletilen Üst Bilgiler Ara Yazılımı sırası.

UseForwardedHeaders Diğer ara yazılımı çağırmadan önce yöntemini çağırın. ara yazılımı ve X-Forwarded-Proto üst bilgilerini iletecek X-Forwarded-For şekilde yapılandırın:

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();

Ara yazılım için hayır ForwardedHeadersOptions belirtilmezse, iletecek varsayılan üst bilgiler şeklindedir None.

Standart localhost adresi127.0.0.1 () dahil olmak üzere geri döngü adreslerinde (127.0.0.0/8, [::1]) çalışan proxy'lere varsayılan olarak güvenilir. Kuruluştaki diğer güvenilen proxy'ler veya ağlar İnternet ile web sunucusu arasındaki istekleri işliyorsa, bunları veya KnownNetworks ile ForwardedHeadersOptionslistesine KnownProxies ekleyin. Aşağıdaki örnek, İletilen Üst Bilgiler Ara Yazılımına KnownProxiesIP adresinde 10.0.0.100 güvenilen bir proxy sunucusu ekler:

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();

Daha fazla bilgi için bkz. ASP.NET Core'u ara sunucular ve yük dengeleyicilerle çalışacak şekilde yapılandırma.

Nginx'i yükleme

Ubuntu

Nginx'i yüklemek için kullanın apt-get . Yükleyici, sistem başlangıcında Nginx'i daemon olarak çalıştıran bir systemd init betiği oluşturur. Nginx: Official Debian/Ubuntu packages adresinde Ubuntu yükleme yönergelerini izleyin.

Red Hat Enterprise Linux

Nginx modül akışı seçmek ve yüklemek için kullanın yum-utils . Nginx: Linux packages - RHEL konumunda RHEL yükleme yönergelerini izleyin.

SUSE Linux Enterprise Server

Nginx modül akışı seçmek ve yüklemek için kullanın yum-utils . Nginx: Linux paketleri - SLES'de SLES yükleme yönergelerini izleyin.

Not

İsteğe bağlı Nginx modülleri gerekiyorsa, kaynaktan Nginx oluşturmak gerekebilir.

Nginx ilk kez yüklendiğinden şunu çalıştırarak açıkça başlatın:

sudo service nginx start

Tarayıcının Nginx için varsayılan giriş sayfasını görüntüleyişini doğrulayın. Giriş sayfasına adresinden http://<server_IP_address>/index.nginx-debian.htmlulaşılabilir.

Nginx hizmetini yapılandırma

Ubuntu

Nginx'i HTTP isteklerini ASP.NET Core uygulamasına iletmek üzere ters ara sunucu olarak yapılandırmak için, symlink'i değiştirin /etc/nginx/sites-available/default ve yeniden oluşturun. Dosyayı oluşturduktan /etc/nginx/sites-available/default sonra symlink'i oluşturmak için aşağıdaki komutu kullanın:

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

Bir metin düzenleyicisinde açın /etc/nginx/sites-available/default ve içeriğini aşağıdaki kod parçacığıyla değiştirin:

Red Hat Enterprise Linux

Nginx'i HTTP isteklerini bir ASP.NET Core uygulamasına iletecek şekilde ters proxy olarak yapılandırmak için öğesini değiştirin /etc/nginx.conf. Kod bloğunu http{} aşağıdaki kod parçacığıyla güncelleştirin:

SUSE Linux Enterprise Server

Nginx'i HTTP isteklerini bir ASP.NET Core uygulamasına iletecek şekilde ters proxy olarak yapılandırmak için öğesini değiştirin /etc/nginx.conf. Kod bloğunu http{} aşağıdaki kod parçacığıyla güncelleştirin:

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;
    }
  }
}

Uygulama bir SignalR veya Blazor Server uygulamasıysa daha fazla bilgi için bkz . ASP.NET Core SignalR üretim barındırma ve ölçeklendirme ile Konak ve ASP.NET Core sunucu tarafı Blazor uygulamaları dağıtma.

Eşleşme olmadığında server_name Nginx varsayılan sunucuyu kullanır. Varsayılan sunucu tanımlanmamışsa, yapılandırma dosyasındaki ilk sunucu varsayılan sunucudur. En iyi uygulama olarak, yapılandırma dosyanızda 444 durum kodunu döndüren belirli bir varsayılan sunucu ekleyin. Varsayılan sunucu yapılandırma örneği:

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

Önceki yapılandırma dosyası ve varsayılan sunucu ile Nginx, 80 numaralı bağlantı noktasında konak üst bilgisi example.com veya *.example.comile genel trafiği kabul eder. Bu konaklarla eşleşmeyen istekler adresine Kestreliletılmaz. Nginx, eşleşen istekleri Kestrel adresine http://127.0.0.1:5000/iletir. Daha fazla bilgi için bkz . Nginx bir isteği nasıl işler? 'nin IP/bağlantı noktasını değiştirmek Kestreliçin bkz Kestrel. Uç nokta yapılandırması.

Uyarı

Uygun bir server_name yönergesi belirtilmesi, uygulamanızı güvenlik açıklarına maruz bırakır. Alt etki alanı joker karakter bağlaması (örneğin, *.example.com) üst etki alanının tamamını denetlerseniz ( *.comgüvenlik açığı olan yerine) bu güvenlik riskini oluşturmaz. Daha fazla bilgi için bkz . RFC 9110: HTTP Semantiği (Bölüm 7.2: Konak ve :yetkili).

Nginx yapılandırması oluşturulduktan sonra komutunu çalıştırarak sudo nginx -t yapılandırma dosyalarının söz dizimini doğrulayın. Yapılandırma dosyası testi başarılı olursa, Nginx'i komutunu çalıştırarak değişiklikleri almaya zorlayabilirsiniz sudo nginx -s reload.

Uygulamayı doğrudan sunucuda çalıştırmak için:

1. Uygulamanın dizinine gidin.
2. Uygulamayı çalıştırın: dotnet <app_assembly.dll>, burada app_assembly.dll uygulamanın derleme dosyası adıdır.

Ubuntu

Uygulama sunucuda çalışıyorsa ancak İnternet üzerinden yanıt veremiyorsa, sunucunun güvenlik duvarını denetleyin ve 80 numaralı bağlantı noktasının açık olduğunu onaylayın. Azure Ubuntu VM kullanıyorsanız, gelen bağlantı noktası 80 trafiğini etkinleştiren bir Ağ Güvenlik Grubu (NSG) kuralı ekleyin. Gelen kuralı etkinleştirildiğinde giden trafiğe otomatik olarak verildiğinden, giden bağlantı noktası 80 kuralını etkinleştirmeniz gerekmez.

Red Hat Enterprise Linux

Uygulama sunucuda çalışıyorsa ancak İnternet üzerinden yanıt veremiyorsa, sunucunun güvenlik duvarını denetleyin ve 80 numaralı bağlantı noktasının açık olduğunu onaylayın.

SUSE Linux Enterprise Server

Uygulama sunucuda çalışıyorsa ancak İnternet üzerinden yanıt veremiyorsa, sunucunun güvenlik duvarını denetleyin ve 80 numaralı bağlantı noktasının açık olduğunu onaylayın.

Uygulamayı test ettiğinizde, komut isteminde Ctrl+C (Windows) veya ⌘+C (macOS) ile uygulamayı kapatın.

keepalive_requests artırma

keepalive_requestsdaha yüksek performans için artırılabilir. Daha fazla bilgi için bu GitHub sorununa bakın.

Uygulamayı izleme

Sunucu, üzerinde yapılan http://<serveraddress>:80 istekleri üzerinde çalışan ASP.NET Core uygulamasına Kestrelhttp://127.0.0.1:5000iletecek şekilde ayarlanır. Ancak, Nginx işlemi yönetmek Kestrel için ayarlanmadı. systemd temel web uygulamasını başlatmak ve izlemek için bir hizmet dosyası oluşturmak için kullanılabilir. systemd , işlemleri başlatmak, durdurmak ve yönetmek için birçok güçlü özellik sağlayan bir init sistemidir.

Hizmet dosyasını oluşturma

Hizmet tanımı dosyasını oluşturun:

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

Aşağıdaki örnek, uygulama için bir .ini hizmet dosyasıdır:

[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

Yukarıdaki örnekte, hizmeti yöneten kullanıcı seçeneğiyle User belirtilir. Kullanıcının (www-data) mevcut olması ve uygulamanın dosyalarına uygun sahip olması gerekir.

uygulamanın ilk kesme sinyalini aldıktan sonra kapanmasını bekleme süresini yapılandırmak için kullanın TimeoutStopSec . Uygulama bu süre içinde kapatılmıyorsa, uygulamayı sonlandırmak için SIGKILL verilir. Zaman aşımını devre dışı bırakmak için değeri birimsiz saniye (örneğin, 150), bir zaman aralığı değeri (örneğin, 2min 30s) infinity olarak belirtin. TimeoutStopSecDefaultTimeoutStopSec varsayılan değerini yönetici yapılandırma dosyasında (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d) kullanır. Çoğu dağıtım için varsayılan zaman aşımı 90 saniyedir.

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

Linux büyük/küçük harfe duyarlı bir dosya sistemine sahiptir. ayarının ayarlanması ASPNETCORE_ENVIRONMENTProduction , yapılandırma dosyasının appsettings.Production.jsondeğil, appsettings.production.jsonaranmasıyla sonuçlanıyor.

Yapılandırma sağlayıcılarının ortam değişkenlerini okuması için bazı değerlerin (örneğin, SQL bağlantı dizesi) kaçılması gerekir. Yapılandırma dosyasında kullanmak üzere doğru şekilde kaçış değeri oluşturmak için aşağıdaki komutu kullanın:

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

İki nokta (:) ayırıcıları ortam değişkeni adlarında desteklenmez. İki nokta üst üste yerine çift alt çizgi (__) kullanın. Ortam Değişkenleri yapılandırma sağlayıcısı, ortam değişkenleri yapılandırmaya okunduğunda çift alt çizgileri iki nokta üst üste dönüştürür. Aşağıdaki örnekte, bağlantı dizesi anahtarı ConnectionStrings:DefaultConnection hizmet tanımı dosyasına olarak ConnectionStrings__DefaultConnectionayarlanır:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Dosyayı kaydedin ve hizmeti etkinleştirin.

sudo systemctl enable kestrel-helloapp.service

Hizmeti başlatın ve çalıştığını doğrulayın.

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

Ters proxy yapılandırıldığında ve Kestrel aracılığıyla systemdyönetildiğinde, web uygulaması tamamen yapılandırılır ve konumundaki yerel makinedeki http://localhostbir tarayıcıdan erişilebilir. Ayrıca uzak bir makineden de erişilebilir ve engelleyici olabilecek tüm güvenlik duvarları engellenebilir. Yanıt üst bilgilerini inceleyen üst bilgi, Server tarafından Kestrelsunulan ASP.NET Core uygulamasını gösterir.

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

Günlükleri görüntüleme

kullanan Kestrel web uygulaması kullanılarak systemdyönetildiğinden, tüm olaylar ve işlemler merkezi bir günlüğe kaydedilir. Ancak, bu günlük tarafından systemdyönetilen tüm hizmetler ve işlemler için tüm girişleri içerir. -specific öğelerini görüntülemek kestrel-helloapp.serviceiçin aşağıdaki komutu kullanın:

sudo journalctl -fu kestrel-helloapp.service

Daha fazla filtreleme için, , --until 1 hour agoveya bunların bir bileşimi gibi --since todayzaman seçenekleri döndürülen girdi sayısını azaltabilir.

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

Veri koruması

ASP.NET Core Data Protection yığını, kimlik doğrulama ara yazılımı (örneğin cookie ara yazılım) ve siteler arası istek sahteciliği (CSRF) korumaları dahil olmak üzere birkaç ASP.NET Core ara yazılımı tarafından kullanılır. Veri Koruma API'leri kullanıcı kodu tarafından çağrılmasa bile, veri koruması kalıcı bir şifreleme anahtar deposu oluşturacak şekilde yapılandırılmalıdır. Veri koruması yapılandırılmazsa anahtarlar bellekte tutulur ve uygulama yeniden başlatıldığında atılır.

Anahtarlık bellekte depolanıyorsa uygulama yeniden başlatıldığında:

• Tüm cookie tabanlı kimlik doğrulama belirteçleri geçersiz kılınır.
• Kullanıcıların, sonraki isteklerinde yeniden oturum açmaları gerekir.
• Artık anahtarlıkla korunan verilerin şifresi çözülemez. CSRF belirteçleri ve ASP.NET Core MVC TempData tanımlama bilgileri de bunlara dahil olabilir.

Anahtar halkasını kalıcı hale getirmek ve şifrelemek için veri korumasını yapılandırmak için bkz:

• ASP.NET Core'daki önemli depolama sağlayıcıları
• ASP.NET Core kullanarak Windows ve Azure'da bekleyen anahtar şifrelemesi

Uzun istek üst bilgisi alanları

Ara sunucu varsayılan ayarları genellikle platforma bağlı olarak istek üst bilgisi alanlarını 4 K veya 8 K ile sınırlar. Bir uygulama varsayılandan daha uzun alanlar gerektirebilir (örneğin, Microsoft Entra Id kullanan uygulamalar). Daha uzun alanlar gerekiyorsa, ara sunucunun varsayılan ayarları için ayarlama gerekir. Uygulanacak değerler senaryoya bağlıdır. Daha fazla bilgi için sunucunuzun belgelerine bakın.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Uyarı

Gerekli olmadıkça ara sunucu arabelleklerinin varsayılan değerlerini artırmayın. Bu değerlerin artırılması, kötü amaçlı kullanıcıların arabellek taşması (taşma) ve Hizmet Reddi (DoS) saldırıları riskini artırır.

Uygulamanın güvenliğini sağlama

AppArmor'un etkinleştirilmesi

Linux Güvenlik Modülleri (LSM), Linux 2.6'dan bu yana Linux çekirdeğinin bir parçası olan bir çerçevedir. LSM, güvenlik modüllerinin farklı uygulamalarını destekler. AppArmor , programın sınırlı bir kaynak kümesine el konulmasını sağlayan Zorunlu Erişim Denetimi sistemi uygulayan bir LSM'dir. AppArmor'un etkinleştirildiğinden ve düzgün yapılandırıldığından emin olun.

Güvenlik duvarını yapılandırma

Kullanımda olmayan tüm dış bağlantı noktalarını kapatın. Karmaşık olmayan güvenlik duvarı (ufw), güvenlik duvarını yapılandırmak için iptables bir CLI sağlayarak için bir ön uç sağlar.

Ubuntu

Uyarı

Güvenlik duvarı, doğru yapılandırılmamışsa sistemin tamamına erişimi engeller. Doğru SSH bağlantı noktasının belirtememesi, bağlanmak için SSH kullanıyorsanız sizi sistemin dışına etkili bir şekilde kilitler. Varsayılan bağlantı noktası 22'dir. Daha fazla bilgi için bkz . ufw'a giriş ve kılavuz.

Gerekli tüm bağlantı noktalarında trafiğe izin verecek şekilde yükleyin ufw ve yapılandırın.

sudo apt-get install ufw

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

sudo ufw enable

Red Hat Enterprise Linux

Uyarı

Güvenlik duvarı, doğru yapılandırılmamışsa sistemin tamamına erişimi engeller. Doğru SSH bağlantı noktasının belirtememesi, bağlanmak için SSH kullanıyorsanız sizi sistemin dışına etkili bir şekilde kilitler. Varsayılan bağlantı noktası 22'dir. Daha fazla bilgi için bkz . ufw'a giriş.

Gerekli tüm bağlantı noktalarında trafiğe izin verecek şekilde yükleyin ufw ve yapılandırın.

sudo yum -y install ufw

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

sudo ufw enable

SUSE Linux Enterprise Server

Uyarı

Güvenlik duvarı, doğru yapılandırılmamışsa sistemin tamamına erişimi engeller. Doğru SSH bağlantı noktasının belirtememesi, bağlanmak için SSH kullanıyorsanız sizi sistemin dışına etkili bir şekilde kilitler. Varsayılan bağlantı noktası 22'dir. Daha fazla bilgi için bkz . ufw'a giriş.

Gerekli tüm bağlantı noktalarında trafiğe izin verecek şekilde yükleyin ufw ve yapılandırın.

sudo yum -y install ufw

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

sudo ufw enable

Güvenli Nginx

Nginx yanıt adını değiştirme

Düzenle 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;

Seçenekleri yapılandırma

Sunucuyu ek gerekli modüllerle yapılandırın. Uygulamayı sağlamlaştırmak için ModSecurity gibi bir web uygulaması güvenlik duvarı kullanmayı göz önünde bulundurun.

HTTPS yapılandırması

Uygulamayı güvenli (HTTPS) yerel bağlantılar için yapılandırma

dotnet run komutu, uygulamanın Properties/launchSettings.json dosyasını kullanır. Bu komut, uygulamayı özelliği tarafından applicationUrl sağlanan URL'leri dinleyecek şekilde yapılandırır. Örneğin, https://localhost:5001;http://localhost:5000.

Uygulamayı, aşağıdaki yaklaşımlardan birini kullanarak komut veya geliştirme ortamı (Visual Studio Code'da F5 veya Ctrl+F5) geliştirme dotnet run aşamasında bir sertifika kullanacak şekilde yapılandırın:

• Varsayılan sertifikayı yapılandırmadan değiştirme (Önerilen)
• KestrelServerOptions.ConfigureHttpsDefaults

Güvenli (HTTPS) istemci bağlantıları için ters ara sunucuyu yapılandırma

Uyarı

Bu bölümdeki güvenlik yapılandırması, daha fazla özelleştirme için başlangıç noktası olarak kullanılacak genel bir yapılandırmadır. Üçüncü taraf araçlar, sunucular ve işletim sistemleri için destek sağlayamıyoruz. Bu bölümdeki yapılandırmayı kendi riski altında kullanın. Daha fazla bilgi için aşağıdaki kaynaklara erişin:

• HTTPS sunucularını yapılandırma (Nginx belgeleri)
• SSL Yapılandırma Oluşturucu'mozilla.org

• Güvenilen bir Sertifika Yetkilisi (CA) tarafından verilen geçerli bir sertifika belirterek sunucuyu 443 numaralı bağlantı noktasında HTTPS trafiğini dinleyecek şekilde yapılandırın.

• Aşağıdaki /etc/nginx/nginx.conf dosyasında gösterilen uygulamalardan bazılarını kullanarak güvenliği sağlamlaştırın .

• Aşağıdaki örnek, sunucuyu güvenli olmayan istekleri yeniden yönlendirecek şekilde yapılandırmaz. HTTPS Yeniden Yönlendirme Ara Yazılımını kullanmanızı öneririz. Daha fazla bilgi için bkz . ASP.NET Core'da HTTPS'yi zorunlu kılma.

  Not

  Sunucu yapılandırmasının HTTPS Yeniden Yönlendirme Ara Yazılımı yerine güvenli yeniden yönlendirmeyi işlediği geliştirme ortamları için, kalıcı yeniden yönlendirmeler (301) yerine geçici yeniden yönlendirmeler (302) kullanmanızı öneririz. Bağlantı önbelleğe alma, geliştirme ortamlarında kararsız davranışlara neden olabilir.

• Strict-Transport-Security (HSTS) üst bilgisi eklemek, istemci tarafından yapılan sonraki tüm isteklerin HTTPS üzerinden yapılmasını sağlar. Üst bilgiyi ayarlama hakkında yönergeler için bkz. ASP.NET Core'da HTTPS'yi zorunlu kılmaStrict-Transport-Security.

• HTTPS gelecekte devre dışı bırakılacaksa aşağıdaki yaklaşımlardan birini kullanın:

  • HSTS üst bilgisini eklemeyin.
  • Kısa max-age bir değer seçin.

/etc/nginx/proxy.conf yapılandırma dosyasını ekleyin:

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;

Ubuntu

/etc/nginx/nginx.conf yapılandırma dosyasının içeriğini aşağıdaki dosyayla değiştirin. Örnek, tek bir yapılandırma dosyasında hem hem de httpserver bölümleri içerir.

Red Hat Enterprise Linux

öğesini değiştirin /etc/nginx/nginx.conf. Bunu bir metin düzenleyicisinde açın ve ve server{} kod bloklarını içeriğiyle aşağıdaki kod parçacığıyla değiştirinhttp{}:

SUSE Linux Enterprise Server

öğesini değiştirin /etc/nginx/nginx.conf. Bunu bir metin düzenleyicisinde açın ve ve server{} kod bloklarını içeriğiyle aşağıdaki kod parçacığıyla değiştirinhttp{}:

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;
        }
    }
}

Not

Blazor WebAssembly uygulamalar, bir burst uygulama tarafından yapılan istek sayısının daha fazla olmasını sağlamak için daha büyük bir parametre değeri gerektirir. Daha fazla bilgi için bkz . ASP.NET Core'u Blazor WebAssemblybarındırma ve dağıtma.

Not

Yukarıdaki örnek, Çevrimiçi Sertifika Durum Protokolü (OCSP) Zımbalamayı devre dışı bırakır. Etkinleştirilirse, sertifikanın özelliği desteklediğini onaylayın. OCSP'yi etkinleştirme hakkında daha fazla bilgi ve kılavuz için Modül ngx_http_ssl_module (Nginx belgeleri) makalesinde aşağıdaki özelliklere bakın:

• ssl_stapling
• ssl_stapling_file
• ssl_stapling_responder
• ssl_stapling_verify

Nginx'i tıklama hırsızlığından koruma

Kullanıcı arabirimi yeniden giriş saldırısı olarak da bilinen tıklama hırsızlığı, web sitesi ziyaretçilerinin şu anda ziyaret ettikleri sayfadan farklı bir sayfadaki bir bağlantıya veya düğmeye tıklamak için kandırıldığı kötü amaçlı bir saldırıdır. Sitenin güvenliğini sağlamak için kullanın X-FRAME-OPTIONS .

Tıklama kaçırma saldırılarını azaltmak için:

1. nginx.conf dosyasını düzenleyin:

   sudo nano /etc/nginx/nginx.conf
   

   Kod bloğunun http{} içine satırı ekleyin: add_header X-Frame-Options "SAMEORIGIN";

2. Dosyayı kaydedin.

3. Nginx'i yeniden başlatın.

MIME türü algılama

Üst bilgi tarayıcıya yanıt içerik türünü geçersiz kılmamasını bildirdiğinden, bu üst bilgi çoğu tarayıcının bildirilen içerik türünden uzak bir yanıt algılamasını engeller. seçeneğiyle nosniff , sunucu içeriğin olduğunu text/htmlsöylüyorsa tarayıcı bunu olarak text/htmlişler.

1. nginx.conf dosyasını düzenleyin:

   sudo nano /etc/nginx/nginx.conf
   

   Kod bloğunun http{} içine satırı ekleyin: add_header X-Content-Type-Options "nosniff";

2. Dosyayı kaydedin.

3. Nginx'i yeniden başlatın.

Ek Nginx önerileri

Sunucuda paylaşılan çerçeveyi yükselttikten sonra, sunucu tarafından barındırılan ASP.NET Core uygulamalarını yeniden başlatın.

Ek kaynaklar

• Linux üzerinde .NET Core önkoşulları
• Nginx: İkili Sürümler: Resmi Debian/Ubuntu paketleri
• ASP.NET Core projelerinde sorun giderme ve hata ayıklama
• ASP.NET Core'u ara sunucular ve yük dengeleyicilerle çalışacak şekilde yapılandırma
• NGINX: İletilen üst bilgiyi kullanma