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

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

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 applicationUrl Properties/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.

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

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

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

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ı.

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.

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 Kestrel http://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_ENVIRONMENT Production , 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. Bu, CSRF belirteçlerini ve ASP.NET Core MVC TempData tanımlama bilgilerini içerebilir.

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 anahtar şifreleme rest

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

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.

sudo apt-get install ufw

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

sudo ufw enable

sudo yum -y install ufw

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

sudo ufw enable

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

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

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

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

Bu kılavuzda Ubuntu 16.04 sunucusunda üretime hazır ASP.NET Core ortamı ayarlama işlemi açıklanmaktadır. Bu yönergeler büyük olasılıkla Ubuntu'nun daha yeni sürümleriyle çalışır, ancak yönergeler daha yeni sürümlerle test edilmedi.

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

• Sudo ayrıcalığına sahip standart bir kullanıcı hesabıyla Ubuntu 16.04 sunucusuna erişim.
• Sunucuda yüklü en son önizleme dışı .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 applicationUrl Properties/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, yer tutucunun {TARGET FRAMEWORK MONIKER} Target Framework Takma Adı/TFM olduğu) paketlemek için geliştirme ortamından dotnet publish komutunu çalıştırın: bin/Release/{TARGET FRAMEWORK MONIKER}/publish

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.

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, 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 en üstündeki Program.cs yöntemini çağırın. ara yazılımı ve X-Forwarded-Proto üst bilgilerini iletecek X-Forwarded-For şekilde yapılandırın:

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

app.UseAuthentication();

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, 10.0.0.100 IP adresinde güvenilen bir proxy sunucusunu içindeki İletilen Üst Bilgiler Ara Yazılımı'na KnownProxies Program.csekler:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

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

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

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.

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

Nginx'i HTTP isteklerini ASP.NET Core uygulamanıza iletmek üzere ters ara sunucu olarak yapılandırmak için öğesini değiştirin /etc/nginx/sites-available/default. Bunu bir metin düzenleyicisinde açın ve içeriğini aşağıdaki kod parçacığıyla değiştirin:

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

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:5000iletir. 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ı.

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.

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.

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

Uygulamayı izleme

Sunucu, üzerinde yapılan http://<serveraddress>:80 istekleri üzerinde çalışan ASP.NET Core uygulamasına Kestrel http://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 hizmet dosyasıdır:

[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

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_ENVIRONMENT Production , 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 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

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. Bu, CSRF belirteçlerini ve ASP.NET Core MVC TempData tanımlama bilgilerini içerebilir.

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 anahtar şifreleme rest

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, Azure Active Directory 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

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.

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

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

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

/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 http server bölümleri içerir.

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

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
   

   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
   

   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

Bu kılavuzda Ubuntu 16.04 sunucusunda üretime hazır ASP.NET Core ortamı ayarlama işlemi açıklanmaktadır. Bu yönergeler büyük olasılıkla Ubuntu'nun daha yeni sürümleriyle çalışır, ancak yönergeler daha yeni sürümlerle test edilmedi.

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

• Sudo ayrıcalığına sahip standart bir kullanıcı hesabıyla Ubuntu 16.04 sunucusuna erişim.
• Sunucuda yüklü en son önizleme dışı .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 applicationUrl Properties/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, yer tutucunun {TARGET FRAMEWORK MONIKER} Target Framework Takma Adı/TFM olduğu) paketlemek için geliştirme ortamından dotnet publish komutunu çalıştırın: bin/Release/{TARGET FRAMEWORK MONIKER}/publish

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.

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, 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 en üstündeki Startup.Configure 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;

...

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

app.UseAuthentication();

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, 10.0.0.100 IP adresinde güvenilen bir proxy sunucusunu içindeki İletilen Üst Bilgiler Ara Yazılımı'na KnownProxies Startup.ConfigureServicesekler:

using System.Net;

...

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

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

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.

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

Nginx'i HTTP isteklerini ASP.NET Core uygulamanıza iletmek üzere ters ara sunucu olarak yapılandırmak için öğesini değiştirin /etc/nginx/sites-available/default. Bunu bir metin düzenleyicisinde açın ve içeriğini aşağıdaki kod parçacığıyla değiştirin:

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

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:5000iletir. 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ı.

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.

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.

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

Uygulamayı izleme

Sunucu, üzerinde yapılan http://<serveraddress>:80 istekleri üzerinde çalışan ASP.NET Core uygulamasına Kestrel http://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 hizmet dosyasıdır:

[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

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_ENVIRONMENT Production , 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 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

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. Bu, CSRF belirteçlerini ve ASP.NET Core MVC TempData tanımlama bilgilerini içerebilir.

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 anahtar şifreleme rest

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, Azure Active Directory 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

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.

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

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

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

/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 http server bölümleri içerir.

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

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
   

   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
   

   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