Bu ilk modülde, ortamımız için dedektif ve duyarlı kontrolleri yapılandıracağız. Bu kontrollerden bazılarının oluşturulmasını otomatikleştirecek ve iki CloudFormation şablonundan ilkini çalıştıracağız ve ardından geri kalanını manuel olarak yapılandırmaya çalışıcağız. AWS Konsolunda oturum açalım.





















3. Create Rule tıklayın
4. Event Pattern i seçin Olayları hizmete göre eşleştirmek için Olay kalıbı oluştur etiketli açılır menüyü tıklayın ve açılır menüden Custom event pattern seçin.

Aşağıdaki özel etkinlik modelini kopyalayıp yapıştırın:


{
"source": [
"aws.guardduty"
],
"detail": {
"type": [
"UnauthorizedAccess:EC2/MaliciousIPCaller.Custom"
]
}
}

1. Hedefler için Hedef Add Target öğesini seçin Lambda Function öğesini seçin ve ardından threat-detection-wksp-remediation-nacl öğesini seçin. En alttaki Configure details tıklayın.

2. Configure rule details ekranında Ad ve Açıklama'yı doldurun ( aşağıdaki öneriler ).

İsim: threat-detection-wksp-guardduty-finding-ec2-maliciousip
Açıklama: GuardDuty Finding: UnauthorizedAccess:EC2/MaliciousIPCaller.Custom

3. Create rule tıklayın. Optional: Ne yaptığını görmek için Lambda işlevini incelemeyi düşünün. Lambda konsolunu threat-detection-wksp-remediation-nacl adlı işleve tıklayın.

Artık tüm dedektif kontrolleriniz yapılandırıldığına göre, size AWS ortamınızın güvenliği ve uyumluluğu hakkında kapsamlı bir görünüm sağlayacak olan AWS Security Hub'ı etkinleştirmeniz gerekiyor.

1. AWS Security Hub konsoluna gidin.
2. Go to Security Hub düğmesine tıklayın.
3. Bir sonraki ekranda Enable AWS Security Hub düğmesine tıklayın.

AWS Security Hub artık etkinleştirildi

Ortamınızı başarıyla kurduktan sonra bir sonraki modüle geçebiliriz.

Artık algılayıcı ve duyarlı kontroller kurulumunuz olduğuna göre, araştıracağınız gerçek saldırıyı simüle edecek başka bir CloudFormation şablonu çalıştıracaksınız.

1. İkinci CloudFormation şablonunu çalıştırın –
2. Tehdit algılama ve müdahale sunumu –

Saldırı simülasyonunu başlatmak için modül 2 CloudFormation şablonunu çalıştırmanız gerekecek:

ABD Batı 2 (Oregon) Deploy to AWS

1. Yukarıdaki Deploy to AWS düğmesini tıklayın. Bu, şablonu çalıştırmak için sizi otomatik olarak konsola götürecektir.

2. Yığının adı otomatik olarak doldurulacaktır, ancak bunu değiştirmekte özgürsünüz, ardından next e ve ardından tekrar next e tıklayın (bu sayfadaki her şeyi varsayılan olarak bırakın).

3. Son olarak, şablonun IAM rolleri oluşturacağını kabul edin ve Create tuşuna tıklayın.

Bu sizi CloudFormation konsoluna geri getirecektir. Yığının oluşmaya başladığını görmek için sayfayı yenileyebilirsiniz. Devam etmeden önce yığının aşağıda gösterildiği gibi CREATE_COMPLETE durumunda olduğundan emin olun.

Aşağıda, modül 2 CloudFormation yığını oluşturulduktan sonraki kurulumun bir şeması bulunmaktadır.

Ne yazık ki, ortamımıza bir yanlış yapılandırma nedeniyle, bir saldırgan web sunucusuna erişim elde etmiş olabilir. Yerleştirdiğimiz güvenlik hizmetlerinden, kötü niyetli etkinliği gösteren uyarılar alıyoruz. Bu uyarılar, bilinen kötü amaçlı IP adresleriyle iletişim, hesap keşfi, Amazon S3 klasör yapılandırmasındaki değişiklikler ve güvenlik yapılandırmalarının devre dışı bırakılmasını içerir. Davetsiz misafirin hangi etkinliği gerçekleştirmiş olabileceğini ve bunu nasıl yaptığını belirlemeliyiz, böylece davetsiz misafirin erişimini engelleyebilir, güvenlik açıklarını düzeltebilir ve yapılandırmayı uygun durumuna geri yükleyebilirsiniz.

Şimdiye kadar etkinleştirdiğimiz güvenlik hizmetlerinden e-posta uyarıları alıyoruz. Şimdi ne olacak? Risk odaklı algılama stratejinizin bir parçası olarak kuruluşumuz, AWS IAM ile ilgili bulgulara öncelik vermeye karar verdi.


1. E-posta uyarılarınızı sıralayalım ve bir AWS IAM sorumlusuyla ilgili bir uyarıyı belirleyelim.

Amazon GuardDuty Finding: YetkisizErişim:IAMUser/MaliciousIPCaller.Custom

2. E-posta uyarısından kopyalayın.

Artık bir kaynak tanımlayıcınız olduğuna göre, bu bulgularla ilgili ilk araştırmayı yapmaya başlamak için Amazon GuardDuty'yi kullanabiliriz.

1. Amazon GuardDuty konsoluna gidin (us-west-2).

2. Add filter criteria kutusuna tıklayın, Access Key ID seçin ve ardından e-postadan kopyaladığınızı yapıştırın ve ardından apply seçin.

3. Ayrıntıları görmek için UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom bulgularından birine tıklayın. Bu bulgu, özel bir kötü amaçlı IP arayan listesindeki bir IP'den bir API çağrısının çağrıldığını gösterir.

4. Bulgu ayrıntılarındaki Resources affected bölümünde, bu kimlik bilgilerinin ait olduğu EC2 bulut sunucusunun bulut sunucusu kimliğini tanımlayabileceksiniz. i-08fa26ffb15a66f5a gibi 'i' ile başlar. İlk etapta kimlik bilgilerinin nasıl ele geçirildiğini belirlemek için daha sonraki araştırmalarda ihtiyaç duyacağımız için örnek kimliğini kopyalayalım.

5. Şimdi erişim anahtarının hangi role ait olduğunu belirleyelim. Finding ID köprüsüne tıklayarak JSON bulmayı inceleyelim.

AccessKeyDetails bölümünü bulana kadar ilerleyelim, bu bulguda atıfta bulunulan erişim anahtarının bir IAM varsayılan rolünden geldiğini görüyoruz; bu, bu API çağrılarını çağırmak için kullanılan Erişim Anahtarı kimlik bilgilerinin bir IAM Rolüne ait olduğu anlamına gelir. Rolün adını kopyalayalım, düzeltme amacıyla buna ihtiyacımız olacak.

EC2 için bir IAM rolünden gelen geçici bir güvenlik kimlik bilgisinin bir saldırgan tarafından kullanıldığını belirlediğinize göre, daha fazla kötüye kullanımı veya olası ayrıcalık artışını önlemek için kimlik bilgilerini hemen döndürmeye karar verilmiştir.

1. AWS IAM konsoluna göz atın.

2. Roles e tıklayın ve daha önce kopyaladığınız Kullanıcı Adını kullanarak önceki bölümde tanımladığınız rol adını bulun (bu, güvenliği ihlal edilmiş örneğe eklenen roldür) ve o Role Name tıklayın.

3. Revoke sessions sekmesine tıklayın.

4. Revoke active sessions seçeneğine tıklayın.

5. check box ve ardından Revoke active sessions tıklayın.

Güvenliği ihlal edilmiş IAM rolü için tüm etkin kimlik bilgileri geçersiz kılındı. Bu, saldırganın bu erişim anahtarlarını artık kullanamayacağı, ancak bu rolü kullanan uygulamaların da kullanamayacağı anlamına gelir. Bunun olacağını biliyordunuz, ancak güvenliği ihlal edilmiş bir IAM erişim anahtarı riskinin yüksek olması nedeniyle gerekli olduğuna kararını verdik. Uygulamamızın kullanılabilirliğini sağlamak için, örneği durdurup başlatarak örnek üzerindeki erişim anahtarlarını yenilememiz gerekir. Basit bir yeniden başlatma, tuşları değiştirmez.Beklediyseniz, bulut sunucusundaki geçici güvenlik bilgileri yenilenir ancak bu prosedür işleri hızlandırır. EC2 bulut sunucularınızda yönetim için AWS Systems Manager kullandığınızdan, bulut sunucusu yeniden başlatıldıktan sonra erişim anahtarlarının döndürüldüğünü doğrulamak için meta verileri sorgulamak için kullanabiliriz.

1. EC2 konsolunda threat-detection-wksp: Compromised Instance adlı Eşgörünümü Durdurun.
Örneğin yanındaki kutuyu işaretleyin, Actions menu, Instance State, Stop, Evet, Stop a basarak onaylayın.

2. Örnek Durumu altında Örnek Durumunun durdurulduğunu söylemesini bekleyin (EC2 konsolunu yenilemeniz gerekebilir) ve ardından örneği başlatın.
Erişim anahtarlarının döndürüldüğünü doğrulayın (Sistem Yöneticisi)

3. AWS Systems Manager konsoluna gidin ve sol gezinme panelindeki Session Manager'a ve ardından Start Session'a tıklayın.
threat-detection-wksp: Compromised Instance adlı bir örnek görmelisiniz: Çalışan bir Örnek durumu ile Tehlike Altında Örnek.

4. Örnekte şu anda etkin olan kimlik bilgilerini görmek için, threat-detection-wksp: Compromised Instance yanındaki radyo düğmesini tıklayın ve Start Session a tıklayın.

5. Kabukta aşağıdaki komutu çalıştırın ve değiştiğinden emin olmak için erişim anahtarı kimliğini e-posta uyarılarında bulunanla karşılaştırın:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/threat-detection-wksp-compromised-ec2

Bu noktada, AWS IAM rolündeki tüm etkin oturumları başarıyla iptal ettiniz ve EC2 bulut sunucusundaki geçici güvenlik kimlik bilgilerini döndürdünüz.

Artık güvenliği ihlal edilmiş IAM kimlik bilgilerini ele aldığımıza göre, saldırganın EC2 bulut sunucusunu nasıl tehlikeye atabildiğine odaklanmamız gerekir. Örnek meta verilerini sorgulamalarına ve kimlik bilgilerini çalmalarına izin veren bu uzlaşmadır.

Güvenliği ihlal edilmiş IAM kimlik bilgilerini araştırırken, bunun EC2 için bir IAM rolünden geldiğini keşfettiniz ve bulgunun asıl kimliğinden EC2 bulut sunucusu kimliğini belirlediniz. Örnek kimliğini (önceden kopyaladığınız, i-08fa26ffb15a66f5a gibi bir "i" ile başlar) kullanarak, bulguları araştırmaya başlamak için AWS Security Hub'ı kullanabilirsiniz. Başlangıç ​​olarak, EC2 bulut sunucusuyla ilgili GuardDuty bulgularını birlikte araştırıcağız.

1. AWS Security Hub konsoluna gidin.

2. Bağlantı sizi Findings bölümüne götürmelidir (değilse, soldaki gezinme bölümündeki Findings etıklayın).

Add filter kutusuna tıklayarak ve Product Name ye giderek bir filtre ekleyin ve kelimeyi yapıştırın GuardDuty.
Tarayıcınızın Control-F bulma işlevini kullanın ve daha önce kopyaladığınıza yapıştırın.
Bu örnek kimliğiyle ilişkili bulgulardan birine tıklayın, yeni bir panel açılacak, Resources bölümünü genişletecektir.
Şimdi ARN'yi arayın, şöyle görünecek arn:aws:ec2:us-west-2:166199753942:instance/i-0efc5172a5d7ecc6b
Büyüteç üzerine tıklayarak bu ARN'yi başka bir filtre olarak ekleyelim.

bir IP adresiyle iletişim kurduğunu göstermelidir; bu, bulut sunucusunun güvenliğinin ihlal edildiği sonucuna daha fazla kanıt ekler. Başka bir bulgu, belirli bir IP adresindeki bir sistemin, araştırdığınız örneğe karşı bir SSH kaba kuvvet saldırısı gerçekleştirdiğini göstermelidir. Şimdi SSH kaba kuvvet saldırısının başarılı olup olmadığını ve saldırganın örneğe erişmesine izin veren şeyin bu olup olmadığını araştırmanız gerekiyor.

Tehditlere karşı otomatik yanıtlar birçok şey yapabilir. Örneğin, güvenlik ekibi tarafından soruşturmada kullanılabilecek tehdit hakkında bilgi toplamaya yardımcı olan bir tetikleyiciniz olabilir. Bu seçeneği göz önünde bulundurarak, GuardDuty belirli bir saldırı tespit ettiğinde bir EC2 bulut sunucusunun Amazon Inspector taramasını tetikleyecek bir CloudWatch olay kuralımız var . Inspector'ın bulgularını görüntülemek için AWS Security Hub'ı kullanacağız. SSH yapılandırmasının en iyi uygulamalara uyup uymadığını belirlemek istiyoruz.


1. Konsolda yeni bir AWS Security Hub bulguları sayfası açın.( Bu bölümde yalnızca Denetçi bulgularına göre filtreleme yapacağız.)

2. Bağlantı sizi Findings bölümüne götürmelidir (değilse , soldaki gezinme bölümündeki Findings e tıklayın).

Add filter kutusuna tıklayarak ve Product Name e giderek bir filtre ekleyin ve kelimeyi yapıştırın Inspector.

Tarayıcınızın Control-F bulma işlevini kullanın ve yapıştırın password authentication over SSH

Bulgu, bulguların ilk sayfasında olmayabilir >, sonraki sayfaya geçmek için düğmesini kullanın.


SSH brute force saldırısı ve incelemesini deneyimleyen örnek için SSH ve parola doğrulama ile ilgili bulguya tıklayın.
İncelemeden sonra, örnekte SSH üzerinden parola doğrulamasının yapılandırıldığını görmelisiniz. Ayrıca diğer Inspector bulgularını incelerseniz, herhangi bir şifre karmaşıklığı kısıtlaması olmadığını göreceksiniz. Bu, örneğin bir SSH kaba kuvvet saldırısına daha duyarlı olduğu anlamına gelir.

Şimdi örneğin bir SSH kaba kuvvet saldırısına karşı daha duyarlı olduğunu bildiğimize göre, CloudWatch günlüklerine bakalım ve başarılı SSH oturumları olup olmadığını görmek için bir ölçüm oluşturalım (sonunda SSH kaba kuvvet saldırısı olup olmadığı sorusunu yanıtlamak için). başarılı.) Kurumsal politikanız, belirli güvenlik günlüklerini EC2 bulut sunucularından CloudWatch'a göndermektir.

1. CloudWatch günlüklerine gidin.

2. günlük grubuna tıklayın /threat-detection-wksp/var/log/secure

3. Birden fazla günlük akışınız varsa, daha önce kopyaladığınız Örnek Kimliğini kullanarak filtreleyin ve akışa tıklayın.

4. Filtre Olayları metin kutusuna aşağıdaki Filtre Modelini koyun:
[Mon, day, timestamp, ip, id, msg1= Invalid, msg2 = user, ...]

5. Başarılı denemeler için şimdi Filtreyi bir taneyle değiştirin:
[Mon, day, timestamp, ip, id, msg1= Accepted, msg2 = password, ...]

Saldırganın etkin oturumu, örneğin bulunduğu alt ağda NACL'de yapılan bir güncellemeyle otomatik olarak durduruldu. Bu, belirli GuardDuty bulgularına dayalı olarak çağrılan bir CloudWatch olay kuralı tetikleyicisi tarafından yapıldı.

1. Otomasyonun nasıl tetiklendiğini belirlemek için Cloudwatch Event Console'a bakın

2. Lambda İşlevlerine bakın.

3. NACL'nin VPC'deki NACL Konsolunda SSH Bruteforce'u gerçekleştiren ana bilgisayarın IP adresiyle güncellendiğini onaylayın. Tehdit-algılama-wksp-güvenliği ihlal edilmiş kötü niyetli ana bilgisayarın IP adresinin reddedilmiş olması gerekir.


Örnekte SSH etkinleştirildiği için bu saldırı başarılı oldu. EC2 Bulut Sunucuları üzerindeki tüm yönetimin AWS Systems Manager aracılığıyla yapılmasına karar verdiniz, bu nedenle artık yönetici bağlantı noktalarının açık olmasına gerek yok, bu nedenle bir sonraki adım, saldırganın veya başka birinin saldırı yapmasını önlemek için EC2 bulut sunucusuyla ilişkili güvenlik grubunu değiştirmek olacaktır. Bağlanıyor.

1. Amazon EC2 Konsolu'na gidin.

2. threat-detection-wksp: Compromised Instance adıyla çalışan örnekleri bulun.

3. Description sekmesi altında, güvenliği ihlal edilmiş örnek için Güvenlik Grubuna tıklayın.

4. Inbound sekmesi altındaki kuralları görüntüleyin.

5.Edit tıklayın ve gelen SSH kuralını silin.

6. kaydedin.


Olayı başarıyla düzelttik ve ortamımızı daha da sertleştirdik. Bu açıkça bir simülasyondur ve verilen kısa sürede yanıt işlevinin her yönünü kapsayamayız, ancak umarız bu size AWS'de tehditleri ve saldırıları algılamak, araştırmak ve bunlara yanıt vermek için mevcut yetenekler hakkında bir fikir vermiştir.

İşte az önce araştırdığınız saldırının bir diyagramı. 1 ve 2 numaralı sayılar, SSH kaba kuvvet saldırısını ve başarılı SSH girişini gösterir. 3 numara, saldırganın yaptığı S3 kova değişikliklerini gösterir. 4 Numara, saldırganın, güvenliği ihlal edilmiş EC2 bulut sunucusundan çalınan IAM geçici kimlik bilgileriyle yaptığı API çağrılarını gösterir.

Son modülde kısa bir tartışma yapacağız ve tam olarak ne olduğunu tartışacağız. Ayrıca bilginizi test etmek için bir dizi soruyu gözden geçireceğiz.

1. İnceleme ve Tartışma –
2. Sorular –
3. Temizleme –

Aşağıda genel atölye kurulumunun bir şeması bulunmaktadır:

Çalıştayın 1. Modülünde, GuardDuty, Inspecto, SecurityHub gibi dedektif kontrollerin yanı sıra basit bildirim ve iyileştirme boru hattı dahil olmak üzere altyapınızın ilk bileşenlerini kurarsınız. Adımlardan bazıları manuel yapılandırma gerektiriyordu, ancak bazı bileşenleri kuran bir CloudFormation şablonu da çalıştırdık.

Modül 2'de, bu atölye tarafından simüle edilen saldırıyı başlatan ikinci bir CloudFormation şablonu başlattık. CloudFormation şablonu iki EC2 örneği oluşturdu. Bir örnekte ( Kötü Amaçlı Ana Bilgisayar olarak adlandırılır ), GuardDuty özel tehdit listenize eklenmiş bir EIP'si vardı. Kötü Amaçlı Ana Bilgisayar, diğer örnekle aynı VPC'de olmasına rağmen, senaryo uğruna (ve bir sızma testi isteği gönderme ihtiyacını önlemek için) İnternetteymiş gibi davrandık ve saldırganın bilgisayarını temsil ettik. Diğer örnek ( Güvenli Örnek olarak adlandırılır) web sunucumuzdu ve Kötü Amaçlı Ana Bilgisayar tarafından devralındı.

Modül 3'te saldırıyı araştırdık, hasarı düzelttik ve gelecekteki saldırılar için bazı otomatik iyileştirmeler ayarladık.

1. Modül 2 CloudFormation şablonu tarafından oluşturulan iki örnek vardır. Aynı VPC'de ancak farklı alt ağlardalar. Kötü Amaçlı Ana Bilgisayar, İnternette olduğunu varsaydığımız saldırganı temsil eder. Kötü Amaçlı Ana Bilgisayardaki Elastik IP, GuardDuty'de özel bir tehdit listesindedir. Ele Geçirilmiş Örnek adlı diğer örnek, kaldırılan ve AWS'ye taşınan web sunucusunu temsil eder.

2. Şirket ilkesi, SSH için yalnızca anahtar tabanlı kimlik doğrulamanın etkinleştirilmesi gerektiği olsa da, bir noktada SSH için parola kimlik doğrulaması, Tehlike Altındaki Örnekte etkinleştirildi. Bu yanlış yapılandırma, GuardDuty bulgusundan tetiklenen Müfettiş taramasında tanımlanır.

3. Kötü Amaçlı Ana Bilgisayar, Güvenliği Bozulmuş Örnek'e karşı kaba kuvvet SSH parola saldırısı gerçekleştirdi. Kaba kuvvet saldırısı başarılı olacak şekilde tasarlanmıştır.

4. SSH kaba kuvvet saldırısı başarılı oldu ve saldırgan, Tehlike Altına Alınmış Örnekte oturum açabildi.

5. Ele Geçirilmiş Örnek ayrıca, özel tehdit listesine dayalı olarak bir GuardDuty bulgusu oluşturmak için Kötü Amaçlı Ana Bilgisayara sürekli olarak ping atan bir cron işine sahiptir.

6. API bulgularını oluşturan API Çağrıları, Kötü Amaçlı Ana Bilgisayardan gelir. Çağrılar, Kötü Amaçlı Ana Bilgisayarda çalışan EC2 için IAM rolündeki geçici kimlik bilgilerini kullanır. GuardDuty bulguları, Kötü Amaçlı Ana Bilgisayara eklenen EIP özel bir tehdit listesinde olduğu için oluşturulur.

7. GuardDuty bulguları tarafından bir dizi CloudWatch Olay Kuralı uyandırılır ve ardından bunlar çeşitli hizmetleri tetikler.

CloudWatch Olay Kuralı : Genel GuardDuty bulgusu, SNS'yi bir e-posta göndermesi için tetikleyen bir CloudWatch Olay kuralını çağırır.

CloudWatch Olay Kuralı : SSH kaba kuvvet saldırı bulma, bir NACL aracılığıyla saldırganın saldırgan IP adresini engellemek için bir Lambda işlevini tetikleyen bir CloudWatch Olay kuralını ve EC2 örneğinde bir Denetçi taraması çalıştıran bir Lambda işlevini çağırır.

CloudWatch Olay Kuralı : Yetkisiz Erişim Özel Kötü Amaçlı IP bulma, bir NACL aracılığıyla saldırganın IP adresini engellemek için bir Lambda işlevini tetikleyen bir CloudWatch Olay kuralını çağırır.