PowerMax 9.2 için Unisphere Uzaktan Güvenli Sistem Günlüğü

Sistem günlüğü geçmişi

Syslog, 1980'lerde Eric Paul Allman (2 Eylül 1955 doğumlu) tarafından geliştirilmiştir.
Eric, 1970'lerin Sonunda ve 1980'lerin Başında Uc Berkeley'de Sendmail ve Öncülü Delivermail'i Geliştiren Amerikalı Bir Bilgisayar Programcısıdır. 1998'de Allman ve Greg Olson, Sendmail, Inc. Şirketini kurdu. Sistem günlüğü olarak bilinen MTA ileti aktarım aracısı tarafından kullanılan günlük tutma biçimi. Sistem günlüğü ilk başta yalnızca Sendmail tarafından kullanıldı, ancak sonunda diğer ilgisiz programlar tarafından günlük kaydı için kullanılan resmi olmayan standart bir biçim haline geldi. Daha sonra bu format 2001 yılında Rfc 3164 tarafından resmileştirildi; Ancak, orijinal biçim en son revizyon olan rfc 5424 tarafından geçersiz hale getirilmiştir.

İnternet Mühendisliği Görev Gücü

İnternet Mühendisliği Görev Gücü (IETF), gönüllü İnternet standartlarını, özellikle de İnternet protokol paketinden (TCP/IP) oluşan standartları geliştiren ve destekleyen bir açık standartlar kuruluşudur. 
Resmi bir üyelik listesi veya üyelik şartı yoktur. Tüm katılımcılar ve yöneticiler gönüllüdür, ancak çalışmaları işverenleri veya sponsorları tarafından finanse edilmektedir.

İnternet Mimarisi Kurulu (IAB), IETF'nin dış ilişkilerini ve RFC Editörü ile olan ilişkilerini denetler. IAB, İnternet gelişimi için uzun vadeli teknik yön sağlar. IAB ayrıca, IETF için lojistik vb. destek sağlayan IETF İdari Destek Faaliyetini (IASA) denetleyen IETF İdari Gözetim Komitesi'nden (IAOC) müştereken sorumludur. 
IAB ayrıca, IETF'nin çeşitli gruplar arası ilişkilerine sahip olduğu İnternet Araştırma Görev Gücü'nü (IRTF) de yönetmektedir.

Yönlendirme Grubu

İnternet Mühendisliği Yönlendirme Grubu (IESG), İnternet Mühendisliği Görev Gücü (IETF) başkanı ve alan yöneticilerinden oluşan bir organdır. İnternet standartlarının son teknik incelemesini sağlar ve IETF'nin günlük yönetiminden sorumludur. Çalışma gruplarının kararlarına itiraz edilir ve IESG, belgeleri standartlar yolunda ilerletme kararını verir.

Syslog Protokolü

Syslog utilizes three layers
  o "syslog content" is the management information contained in a syslog message.
  o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages.
  o The "syslog transport" layer puts messages on the wire and takes them off the wire.
  o An "originator" generates syslog content to be carried in a message.
  o A "collector" gathers syslog content for further analysis.
  o A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays.
  o A "transport sender" passes syslog messages to a specific transport protocol.
  o A "transport receiver" takes syslog messages from a specific transport protocol.

Diagram 1 shows the different entities separated by layer.

+-------------------------+  +----------------------+
 | content                |  | content              |
 |------------------------|  |----------------------|
 | syslog application     |  | syslog application   |
 |                        |  |                      | (originator,
 |                        |  |                      | (collector, relay)
 |------------------------|  |----------------------|
 | syslog transport       |  | syslog transport     | (transport sender,
 |                        |  |                      | (transport receiver)
 +------------------------+  +----------------------+
      ^                                     ^
      |                                     |
          -----------------------------

Sistem günlüğü nasıl taşınır?

Sistem günlüğü mesajları göndermenin yaygın olarak kullanılan iki yolu vardır. RFC 5424, tüm sistem günlüğü uygulamalarının TCP üzerinden şifrelenmiş bir TLS ağ aktarımını desteklemesini gerektirse de, çoğu sistem günlüğü iletisi hala eski UDP yöntemi kullanılarak teslim edilir. UDP sürümünde, mesajlar basitçe bir UDP paketinin veri bölümüne yerleştirilir ve UDP bağlantı noktası 514 üzerinden sunucuya gönderilir. Her mesaj genellikle tek bir pakete sığar. UDP durumsuzdur ve oturumsuzdur, bu nedenle onay yoktur. Paketler ağa gönderilir. Bu, herhangi bir ağ sorununun paketin teslimini engelleyebileceği gibi bariz bir soruna sahiptir, bu durumda ağın kapalı olduğunu bilmiyor olabilirsiniz çünkü size söyleyemez. Ayrıca, bazen önemli paketlerin nakliye sırasında kaybolabileceği veya hasar görebileceği anlamına gelir.

Temel İlkeler

 Sistem günlüğü iletişimi için aşağıdaki ilkeler geçerlidir:
o Sistem günlüğü protokolü, ileti tesliminin onaylanmasını sağlamaz. Bazı taşımalar durum bilgisi sağlayabilse de, kavramsal olarak sistem günlüğü tamamen tek yönlü bir iletişim protokolüdür.
 o Oluşturucular ve aktarıcılar, aynı mesajı birden fazla toplayıcıya ve aktarıcıya gönderecek şekilde yapılandırılabilir.
 o Oluşturucu, aktarıcı ve toplayıcı işlevselliği aynı sistemde bulunabilir.

Gerekli Minimum Aktarım Eşlemesi

 Bu spesifikasyonun tüm uygulamaları, [RFC5425]'de açıklandığı gibi TLS tabanlı bir aktarımı DESTEKLEMELİDİR.
 Bu spesifikasyonun tüm uygulamaları, [RFC5426]'de açıklandığı gibi UDP tabanlı bir taşımayı da desteklemelidir. Bu belirtimin dağıtımlarının TLS tabanlı aktarımı kullanması TAVSİYE EDİLİR.
Sistem günlüğü mesajlarının serbest biçimli doğası, sistem günlüğünün en büyük gücüdür, ancak aynı zamanda sistem günlüğünün en büyük sorunudur. Farklı satıcılardan düzinelerce farklı sistemden gelen olayları içeren bir günlüğü ayrıştırmak ve bunları aynı anda anlamlandırmak çok zordur. Hangi mesajlar hangi işlevleri temsil eder? Ve hangileri sadece bilgi mesajlarına karşı kritik olayları temsil ediyor?
Bu sorularla başa çıkmak için, sistem günlüğü protokolü (RFC 5424'te tanımlanmıştır) bu serbest biçimli iletileri "kolaylık" ve "önem derecesi" adı verilen özel alanlarla sağlar.
(RFC 5424'ün sistem günlüğü için standart olduğunu ancak tüm sistem günlüğü uygulamalarının RFC 5424 uyumlu olmadığını unutmayın. Sistem günlüğü protokolü çok uzun bir süredir kullanılmaktadır ve hala kullanımda olan bazı standart öncesi uygulamalar vardır.)

Syslog için Güvenlik Gereksinimleri

Sistem günlüğü iletileri, hedeflenen toplayıcıya ulaşmak için birkaç atlama geçirebilir. Ağ, farklı bir güvenlik etki alanında veya kaynak, aktarıcı veya toplayıcıdan farklı bir güvenlik düzeyinde olduğu için bazı aracı ağlara kaynak, aktarıcı veya alıcı tarafından güvenilmeyebilir. Diğer bir güvenlik endişesi, gönderenin, aktarıcının veya alıcının kendisinin güvenli olmayan bir ağda olmasıdır.
Sistem günlüğü güvenliği için ele alınması gereken birkaç tehdit vardır.

Başlıca tehditler şunlardır

  o Maskeli Balo. Yetkisiz bir aktarım göndericisi, meşru bir aktarım alıcısına ileti gönderebilir veya yetkisiz bir aktarım alıcısı, meşru bir aktarım göndericisini kendisine syslog iletileri göndermesi için kandırmaya çalışabilir. 
 
  o Değişiklik. Aktarım göndericisi ile aktarım alıcısı arasındaki bir saldırgan, aktarım halindeki bir sistem günlüğü iletisini değiştirebilir ve ardından iletiyi aktarım alıcısına iletebilir. Bu tür bir değişiklik, aktarım alıcısının mesajı yanlış anlamasına veya istenmeyen şekillerde davranmasına neden olabilir.

  o İfşa. Yetkisiz bir varlık, syslog mesajlarının içeriğini inceleyerek bilgilere yetkisiz erişim elde edebilir. Sistem günlüğü mesajlarındaki bazı veriler hassastır ve yetkili bir yöneticinin veya kullanıcının parolası gibi bir saldırgan için yararlı olabilir.

İkincil tehdit ise

o Mesaj akışı değişikliği. Saldırgan bir dizi iletiden bir veya daha fazla sistem günlüğü iletisini silebilir, bir iletiyi yeniden oynatabilir veya teslim sırasını değiştirebilir. Sistem günlüğü protokolünün kendisi ileti sırasına dayalı değildir. Bununla birlikte, bir sistem günlüğü iletisindeki bir olay, diğer iletilerdeki olaylarla anlamsal olarak ilişkili olabilir, bu nedenle ileti sıralaması, bir olay dizisini anlamak için önemli olabilir.

Aşağıdaki tehditlerin sistem günlüğü için daha az önemli olduğu kabul edilir ve bu belgede ele alınmaz:
  o Hizmet Reddi

o Trafik Analizi

Sistem Günlüğünün Güvenliğini Sağlamak için TLS yi Kullanma

TLS, yukarıda açıklanan sistem günlüğüne yönelik tüm birincil tehditlere karşı koymak için güvenli bir aktarım olarak kullanılabilir

  o Mesaj içeriğinin ifşasına karşı gizlilik.

  o Bir mesajda yapılan değişikliklere atlama bazında karşı koymak için bütünlük kontrolü.

  o Maskeli baloya karşı koymak için sunucu veya karşılıklı kimlik doğrulama.

Not: Bu güvenli aktarım (yani TLS), yalnızca atlamalı şekilde sistem günlüğü aktarımının güvenliğini sağlar ve sistem günlüğü mesajlarının içeriğiyle ilgilenmez. Özellikle, aktarım göndericisinin kimliği doğrulanmış kimliği (örneğin, sertifikadaki konu adı), sistem günlüğü mesajının HOSTNAME alanıyla ilgili olmak zorunda değildir. Sistem günlüğü mesaj kaynağının doğrulanması gerektiğinde [SYS-SIGN] kullanılabilir.

Sistem Günlüğü Trafiğini TLS (SSL) ile Şifreleme https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Dell Security Management Server Sistem Günlüğü ve SIEM kılavuzu
https://www.dell.com/support/kbdoc/en-us/000124929/dell-security-management-server-syslog-and-siem-guide

Rsys günlüğe kaydetme
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

 PowerMax ve VMAX 9.2 İçin Olaylar ve Uyarılar Kullanıcı Rehberi

Solutions Enabler 9.2 CLI Referans Rehberi

PowerMax İçin Unisphere 9.2.0 Çevrimiçi Yardım