21 Mayıs 2012 tarihinde Bilgi Üniversitesi’nde düzenlenen NOPcon Konferansında gerçekleştirdiğim “FreeBSD Kernel’de Protokol Analizi ve DoS/DDoS Engelleme” başlıklı konuşmaya ilişkin sunum dosyasına ve kullandıgım materyallere aşağıdaki linklerden ulaşabilirsiniz.

Sunum Dosyası: http://www.ikizler.net/sunumlar/nopcon/Protocol_Analysis_DefeatingDDOS_FreeBSD.pdf

Materyaller: http://www.ikizler.net/sunumlar/nopcon/NOPcon.tgz

Share on Twitter
Written on May 23rd, 2012 , Security Tags: , , , , , , , , ,

When the interest of the “human beings” to the mobile technologies are analyzed, it is clear that the “i” series, apple products, are the number one. There is no doubt that they are miracle of design. When you first use these products, you are attracted by either physical compactness or look and feel.

Apple is not only interested in attractiveness of these products, but also trying to solve security issues in depth. However, the problem is not so easy :)

Actually, it is believed that the non-jailbroken apple products are strongly sealed for penetration and leakage. Is it really like that? Of course NO!

From the beginning of the iPxxx usage, you should connect the device to a computer for activation, software insallation/upgrade, synchronization and backup. Do you think that, your data on the phone is really sealed after all? Think again. Let’s have a look, what’s happening?

As you know this is the iTunes screen, when the iPxxx is connected to your computer.  There are some options regarding the operations you perform. The “Encrypt iPxxx backup” option is directly related with the confidentiality of your data, when you backed up your device.

The first question is, “What is backed up?”.

  • Almost everything on your phone is backed up. Your contacts, call history, notes, calendar, settings, wi-fi’s you connected, photos, location datas, application data, browsing history etc.

The second question is, “How is it stored on computer?”.

  • It is stored in the form of you selected. Actually, if you select encryption option, then all the data is stored as encrypted with 128-bit AES in CBC mode (Symmetric-key encryption). However, if you do not select this option, then all your data is stored in cleartext form on your computer.

Then the third question is, “Where all the backed up data is stored?”.

  • You can check it out from your iTunes settings.
  • Default location for Mac OS: “~/Library/Application\ Support/MobileSync/Backup/XXXX”
  • Default location for Microsoft Windows: “C:\Documents and Settings\YourUserName\Application Data\Apple Computer\MobileSync\Backup\XXXX” (Here the XXX is the UDID of your device, seen on iTunes)

When you list the content of the backup directory, you face with ambiguous file names.

At a glance, you realise that there are couple of files with same name but different extension. “.mddata” and “.mdinfo” files.

  • The “.mdinfo” contains the metadata info about the file such as what category or type of information (i.e., Address Book, SMS, Call History, etc).
  • The “.mddata” contains the actual content for that file.

So let’s have a look file command outputs for all  files, we know that iPxxx stores the data on Sqlite databases, and filter by database.

Hmm, actually file command revealed circa 50 database files. Now just use Sqlite to dig in deeper. I’ve selected some of these database files, and interpret the content of the databases, here is the samples, and the outputs:

Tables on this file are not valuable.

Here I found the calendar entires.

This file contains the contacts.


These are the samples that I’ve checked, and also I should mentioned that, there exist several ASCII text files, XML files and other types of files that contain several forms of data. Additionally you should keep in mind that, the backup file names, database structures and table formats may be different as the device type, iOS version and the iTunes version. However, the searching and the accessing methods will be the same for an attacker to find and steel these and may be much more confidential data from your unencrypted iPxxx device back up. You should keep your device backups encrypted to feel much more comfortable.

Do not forget that, the motivation is the most powerful weapon of an attacker…

Share on Twitter
Written on December 11th, 2011 , Security Tags: , , , , , , , , , , , ,


23 Ekim tarihinde yine binlerce can yandi, yine ocaklar sondu…

Peki ne yapmali?
Tabi ki yapilacak cok sey var, alinacak cok ders var… Ama once, binlerce insan yardim bekliyor…

Once YARDIM gerekiyor… Hem de her turlu yardim:

- Her boyutta cadir
- Battaniye
- Yorgan
- Kuru gida
- Konserve
- Seker
- Tuz
- Biberon
- Bebek mamasi
- Su
- Bebek bezi
- Kadin pedi
- Kislik giysi
- Ic camasiri
- Tibbi malzeme
- Aydinlatici

Peki bu yardimlari nasil ulastiracagiz?

Depremin ardindan bircok yardim kurulusu, yardimlarin toplanmasi ve Van’a ulastirilmasi icin calismalara basladi.

Kizilay: http://www.kizilay.org.tr/

Akut: http://www.akut.org.tr/

Basbakanlik: http://www.bbm.gov.tr/Forms/pgNewsDetail.aspx?Id=%202218&Type=3

Kargo Firmalari: Yurtici Kargo, PTT Kargo, MNG Kargo, Aras Kargo


Share on Twitter
Written on October 26th, 2011 , Uncategorized Tags: , , ,

I really do not know what to say…

Dennis MacAlistair Ritchie (dmr), September 9, 1941 – October 12, 2011, the creator of the “C” programming language and the co-author of the UNIX operating system.

It is really hard to imagine that, how could the technological developments happen without the direct contribution of  Denis Ritchie. The things that he involved within the creation of them, are the basis of almost everything from smartphones to well-known computer systems running todays internet infrastructure and other technological products.

Especially I should express that, his contribution to my career can not be ignored. Whole of my career is full of application development with “C” and running operating systems that based on UNIX. They all supported the formation of my career and  knowledge-base from beginning of my school life up to now. It is also clear that, I’ll never get them out of my life…

Really thank you Dennis Rithcie for everything that you have done for us.

Dennis M. Ritchie







Dedicated to Dennis M. Ritchie



#include <stdio.h>

int main(){

printf(“RIP GrandMaster…\n”);


return 0;



  1. Dennis M. Ritchie
  2. The C Programming Language
  3. UNIX
Share on Twitter
Written on October 16th, 2011 , Uncategorized Tags: , , , , ,

TCP SYN Flood is the most popular attack in internet infrastructure. Dozen of well-known internet sites or services became a victim of different size of such flood attack. Motivation of the attacker mostly rely on his self-satisfaction, and the complexity and the size of the attack especially based on this motivation.

Some of such incidents showed that, if the attacker is highly motivated, exact protection against the attack does not exist and there is no choice of waiting for the satisfaction of the attacker.

Although the cases above are faced rarely, most of the sites or services have no protection with IPS, and even though the size of the attack is low, sites and services are affected by such tiny attack.

Here you will find, how these attacks can be defused.


1. TCP SYN backlog (Enlarge The Queue):

TCP stack keep track of the connections with a queue (backlog queue). When a packet received with SYN flag is set, the server constructs a memory structure in the SYN queue. The three-way handshake is completed and the connection is established with the information stored in this queue.

However, under the SYN Flood, the SYN queue is filled up with bogus SYN requests resulting connections with half-open state. And the legitimate SYN packets from the legitimate clients are dropped respectively.

Simplest way to serve more clients under SYN Flood is to modify and enlarge the SYN queue. On the other hand, this operation requires more resources to be used by the SYN queue.

On linux systems, the SYN queue (backlog queue) size can be set by:

“net.ipv4.tcp_max_syn_backlog” kernel parameter. Default value can be increased under SYN Flood Attack.


2. TCP synack_retries (Decrease SYN+ACK retransmission):

Although the SYN queue size is increased, under the SYN Flood the queue will be filled again. So the time for the half-open session entries should be decreased respectively. By the way, even if the queue is filled, the older bogus session entries will be dropped from the SYN queue automatically.

When a server receives a SYN flagged packet, it sends a SYN+ACK flagged packet and waits for the corresponding ACK flagged packet. In current TCP stack on linux systems, if the corresponding ACK flagged packet is not received, the server retransmits SYN+ACK flagged packet and again waits for the corresponding ACK flagged packet. Half-open connection is still keep stored in SYN queue in the meantime. And also SYN+ACK retransmission keep going on respectively. Waiting times for the retransmissions:

  • 1. SYN+ACK retransmit : 3 Sec.
  • 2. SYN+ACK retransmit : 6 Sec.
  • 3. SYN+ACK retransmit : 12 Sec.

In the current TCP stack on linux systems, RTO (Retransmission Timeout) can not be modified directly, however it can bu modified by the number of SYN+ACK retransmission.Removal of the half-open connections from the backlog queue can be speed up by changing the total number of retransmissions.

  • SYN+ACK retransmission=1 – Half-open connection life time : 9 sec
  • SYN+ACK retransmission=2 – Half-open connection life time : 21 sec
  • SYN+ACK retransmission=3 – Half-open connection life time : 45 sec

On linux systems, the SYN+ACK retransmission number can be set by:

“net.ipv4.tcp_synack_retries” kernel parameter. Default value can be decreased under SYN Flood Attack.


3. TCP SYN cookies:

SYN cookies protection is the most useful method when the sites or services are under a SYN flood attack. During a SYN Flood attack, the system generates a standard SYN – ACK packet with a cookie, stored within sequence number. This cookie is a result of a hash function, generated from source IP, source port, destination IP, destination port etc. In this stage no entry has been constructed within the SYN queue (backlog queue). When the server receives corresponding ACK flagged packet to complete three-way handshake process, it verifies the cookie. If the cookie is correct, it creates the connection, even though there is no entry in SYN queue (backlog queue). The information for the cookie verification is stored cookie session table other than the SYN queue.

As a result from the nature of the mechanism, only the legitimate connections are stored in SYN queue (backlog queue), and the SYN queue does not filled up with bogus SYN flagged request, the legitimate connections does not affected from the flood. Therefore there is no need to enlarge the SYN queue (backlog queue) size.

On linux systems, the SYN cookies method can be enabled by:

“net.ipv4.tcp_syncookies” kernel parameter. Value can be set to “1″ under SYN Flood Attack.



As mentioned in the methods, these are simple modifications on the running TCP/IP stack of your systems. These methods  make servers more resistant to SYN Flood attacks respectively and each methods could be used under different size od SYN Flood attacks.

You can find much more information about the sysctl and kernel TCP/IP kernel parameters on http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt . and the information about SYN cookies can be found at D. J. Bernstein‘s site  http://cr.yp.to/syncookies.html .

Share on Twitter


Kredi karti kullaniminin ve internet uzerinden alisveris yapan kisi sayisinin giderek arttigi su gunlerde, hem bankalarin hem de kredi karti ile odeme imkani sunan uye isyerlerinin isi pek de kolay degil.


Zorluk nereden geliyor? 

Cebimizdeki kredi karlarina baktigimizda, MasterCard, Visa, American Express gibi farkli kart ureticilerine ait kartlar tasidigimizi goruyoruz. Bankalarin farkli ureticilerden farkli kart urunu sunabilme imkanlari vardir. Yukarida bahsettigimiz ve bunlar gibi bir kac ureticinin de olusturdugu birlik bugun PCI olarak karsimiza cikiyor. Boyle bir biriligin kurulmasindaki temel amac ise musteri ve karta ait bilgileri korumak.

Bilgilerin korunmasi noktasinda, birligin olusturdugu standart ile karsilasiyoruz, PCI DSS (Payment Card Industry Data Security Standard). Bu olusuma http://www.pcisecuritystandards.org/ adresinden ulasilabilir. Bu standart icerisinde 6 temel hedef ve 12 temel gereksinim bulunmaktadir.

Temel 6 hedef ve 12 gereksinim su sekilde ozetlenebilir:

A. Guvenli Bir Ag Olusturun ve Gerekli Onlemleri Alin

1. Musteri bilgisini korumak icin guvenlik duvari kurun ve gerekli onlemleri alin.

2. Sistem sifreleri ve diger guvenlik parametreleri icin ureticilerin belirledigi on tanimli degerleri kullanmayin.

B. Musteri Bilgilerini Koruyun

3. Tutmus oldugunuz musteri bilgilerini koruyun.

4. Acik aglarda transfer edilen musteri bilgilerini sifreleyin.

C. Zaafiyet Yonetim Programi Olusturun

5. Antivirus yazilimi kullanin ve duzenli olarak guncelleyin.

6. Guvenli sistemler ve uygulmalar gelistirin devamliligini saglayin.

D. Guclu Erisim Kontrol Onlemleri Alin

7. Is gereksinimleri dogrultusunda musteri bilgilerine erisimi kisitlayin.

8. Bilgisayar erisimlerinde kullanilmak uzere herkese tekil bir tanimlayici atayin.

9. Musteri bilgilerine fiziksel erisimi kisitlayin.

E. Aginizi Duzenli Olarak Izleyin ve Test Edin

10. Ag kaynaklarina ve musteri bilgilerine olan butun erisimleri takip edin ve gozlemleyin.

11. Guvenlik sistemlerini ve surecleri duzenli olarak test edin.

F. Bilgi Guvenligi Politikasi Olusturun

12. Butun personel icin bilgi guvenligini belirleyen bir politika olusturun.

Kimlerin Uymasi Bekleniyor?

PCI DSS, musteri bilgisinin tutuldugu, transfer edildigi ya da  islendigi her adimda uyulmasi gereken bir standarttir. Dolayisi ile islem gerceklestiren tum uye isyerlerini, servis saglayacilari ve bankalari kapsamaktadir. Belirtilen musteri verisi “Musteri Bilgisi” ve “Hassas Yetkilendirme Bilgisi”dir. Burada PCI DSS zorunlulugunda belirleyici olan PAN (Primary Account Number) bilgisidir (Kart Numarasi). Bu bilginin tutuldugu, transfer edildigi ya da islendigi her durumda PCI DSS uyumlulugu zorunludur.

PCI DSS kapsaminda “Hassas Yetkilendirme Bilgisikesinlikle tutulamaz.


Surec Nasil Isliyor?

Yukarida belirtilen taraflardan bir tanesinde yer aliyorsak, standardi uygulayacagiz fakat nasil? Bu noktada standart, islem hacmine gore bazi prosedurel farklar gerektiriyor. Burada uye isyerlerinin islem hacimlerine gore belirlendigi seviyeleri asagidaki gibidir.

 Tablodan da anlasildigi gibi,

Butun uye isyerlerinin her ceyrekte “Network Security Scan” yaptirmasi, her yil “Self Assessment Questionnaire” doldurmasi gerekmektedir. Uye isyerinin kredi karti islem sayisi 6.000.000 uzerine ciktigi zaman, “Onsite Audit” zorunlu hale gelmektedir.


Simdi Ne Yapacagim?

Ne seviyede olursa olsun, bir uye isyerinin mutlaka network scanning yaptirmasi gerekiyor. Bu tarama ise herkes tarafindan ve her tool ile yapilan bir tarama degil ne yazik ki. PCI tarafindan onaylanmis tarama hizmet saglayicisi bu taramayi yapmaya yetkilidir. PCI’in onayladigi hizmet saglayicilarina buradan ulasabilirsiniz.

Bir hizmet saglayici ile anlasma yaptiktan sonra, her ceyrekte kredi karti islemi yaptiginiz tum sunculari taratmaniz ve uyumluluk raporunu bankalara iletmeniz gerekmektedir.

Eger kredi karti islem sayiniz 6.000.000′u gecmiyor ise, yillik olarak bir de “Self Assessment Questionnaire” doldurmaniz gerekiyor. PCI’da yine doldurulacak olan bu soru seti, kredi karti bilgisi isleme bicimine gore degisiklik gostermektedir.

Uye isyerleri ve servis saglayicilari, kredi karti bilgisi isleme bicimlerine gore uygun olan kategorideki soru setini cevaplayacaktir.

Burada doldurulacak soru setlerine PCI sitesi uzerinden erisilmektedir. Uygun soru seti, firma icerisindeki mufettis veya guvenlik yoneticisi tarafindan imzalanarak bankalara iletilmelidir.


Eger uye isyerinin isledigi kredi karti sayisi 6.000.000′u gecti ise, ilgili uye isyerine yillik olarak onsite denetim yapilma zorunlulugu bulunmaktadir. Bu denetimi ise, yine PCI tarafindan onaylanan PCI QSA (Qualified Security Assessor) gereceklestirebilmektedir. PCI’in onayladigi PCI QSA’lere buradan ulasabilirsiniz.

Uye isyerlerinin doldurduklari ve altina imza attiklari her dokuman, onsite denetim olmadigi surece bankalara ve ilgili kart ureticilerine sadece belirli bir yere kadar guvence vermek icindir. Burada doldurulan formlar, PCI’in gerek gordugu 12 temel gereksinimin karsilanip karsilanmadigini sorgulamaktadir. Formlarin gereksinimleri karsilamadan uygunsuz bicimde doldurularak banklara iletilmesi, hem kredi karti islemi yapan musterileri hem de uye isyerlerini tehlikeye sokmaktadir.

Standartin orjinaline PCI DSS uzerinden ulasabilirsiniz.



Nebi Senol YILMAZ



  1. http://www.pcisecuritystandards.org/
  2. http://www.visa.com/pinsecurity/
  3. http://www.mastercard.com/us/company/en/whatwedo/site_data_protection.html



Share on Twitter


Hic degise ele, avuca gelir birseyler oldu.

Biraz daha eklenecekler var ama, onlar da yakinda :)





Share on Twitter
Written on September 3rd, 2011 , Uncategorized


Share on Twitter
Written on September 3rd, 2011 , Documents, Resources Tags: , , , , , ,


Share on Twitter
Written on September 3rd, 2011 , Documents, Resources Tags: , , , , , ,
Her son yeni bir baslangictir…
Burada da yine, yeni bir son ve yeni bir baslangic :)
Share on Twitter
Written on September 3rd, 2011 , Uncategorized

Ikizler.net is proudly powered by WordPress and the Theme Adventure by Eric Schwarz
Entries (RSS) and Comments (RSS).