![]() |
Atef Helmy |
(Çeviridir, yazının kaynağı: http://www.dailynewsegypt.com/2014/03/19/ministry-communication-adopts-open-source-software-strategy/)
Ali E. İMREK 20 Mart 2014
Posted In: lkd_gezegen, Özgürlük için
![]() |
Atef Helmy |
Ali E. İMREK 20 Mart 2014
Posted In: lkd_gezegen, Özgürlük için
![]() |
Kibana dashboard showing various NetFlow metrics |
1: # nfdump -r fnf1.dump -oextended -c5
2: Date flow start Duration Proto Src IP Addr:Port Dst IP Addr:Port Flags Tos Packets Bytes pps bps Bpp Flows
3: 2014-01-01 00:04:23.980 25.000 TCP 172.16.0.156:33510 -> 172.16.0.94:58781 .AP... 0 296 237484 11 75994 802 1
4: 2014-01-01 00:04:23.980 34.000 TCP 192.168.0.133:20022 -> 172.16.0.121:64327 .AP... 0 375 24206 11 5695 64 1
5: 2014-01-01 00:04:23.980 25.000 TCP 172.16.0.156:5910 -> 172.16.0.132:63880 .AP... 0 319 173587 12 55547 544 1
6: 2014-01-01 00:04:23.980 21.000 TCP 172.16.0.22:39621 -> 172.16.2.135:80 .AP... 0 35 9504 1 3620 271 1
7: 2014-01-01 00:04:23.980 11.000 TCP 172.16.0.99:65192 -> 172.16.9.132:80 .AP..F 0 39 6800 3 4945 174 1
# nfdump -mR ./nfdump -zw fnf1.dump
# nfdump -Nqr fnf1.dump -o "fmt:%ts, %sa, %sp, %da, %dp, %byt, %pkt, %out, %pr" > fnf1.csv
1: {
2: "fnf1x": {
3: "_all" : {"enabled" : false},
4: "_source" : {"enabled" : false},
5: "properties": {
6: "ts": {"type": "date", "format" : "YYYY-MM-dd HH:mm:ss"},
7: "sa": {"type": "string", "index": "not_analyzed"},
8: "sp": {"type": "integer", "index": "not_analyzed"},
9: "da": {"type": "string", "index": "not_analyzed"},
10: "dp": {"type": "integer", "index": "not_analyzed"},
11: "byte": {"type": "long"},
12: "pkt": {"type": "long"},
13: "out": {"type": "integer", "index": "not_analyzed"},
14: "pr": {"type": "string", "index" : "not_analyzed"}
15: }
16: }
17: }
1: #!/usr/bin/python
2: import csv, sys, time, json, elasticsearch
3: from elasticsearch import helpers
4: es = elasticsearch.Elasticsearch()
5: source = 'fnf1'
6: csvfile = source + '.csv'
7: jdata = dict()
8: actions = list()
9: i = 0
10: proto = {'0': '0', '1': 'ICMP', '2': 'IGMP', '6': 'TCP', '17': 'UDP', '112': 'VRRP', '3': 'GGP', '50': 'ESP'}
11: with open(csvfile, 'rb') as file :
12: line = csv.reader(file, delimiter = ',', skipinitialspace = True)
13: for row in line :
14: ptime = time.strptime(row[0][0:19], "%Y-%m-%d %H:%M:%S")
15: ctime = time.strftime('%Y-%m-%d %H:%M:%S', ptime)
16: jdata = { 'ts': ctime, 'byte': int(row[5]), 'sa': row[1], 'sp': int(float(row[2])), 'da': row[3], 'dp': int(float(row[4])), 'pkt': int(row[6]), 'out': int(row[7]), 'pr': proto[row[8].strip()] }
17: action = { '_index': 'netflowlab', '_type': 'fnf1x', '_source': json.dumps(jdata, separators=(',', ':'))}
18: actions.append(action)
19: i += 1
20: if i % 100000 == 0:
21: elasticsearch.helpers.bulk(es, actions)
22: print "Indexed %d, working on next 100000" %(i)
23: actions = list()
24: elasticsearch.helpers.bulk(es, actions)
25: print "Indexed %d, finishing." %(i)
http://localhost:9200/netflowlab/_optimize?max_num_segments=1
Rows | Nfdump (bz2) | Nfdump | Nfdump (-j) | CSV | Json | ES Index Size | Tar.gz | |
---|---|---|---|---|---|---|---|---|
FNF1 | 4,616,895 | 38.33 | 228.96 | 85.77 | 484.33 | 781.21 | ||
FNF2 | 8,598,766 | 74.02 | 426.43 | 146.18 | 902.05 | 1,424.96 | ||
FNF3 | 33,710,008 | 402.99 | 1,671.73 | 667.57 | 3,536.32 | 5,854.58 | ||
Total | 46,925,669 | 515.35 | 2,327.12 | 899.52 | 4,922.70 | 8,060.74 | 3,805.68 | 2,711.24 |
I'll continue experimenting with ElasticSearch and post my notes about using ElasticSearch for Netflow analytic purposes. Please send in your questions and comments.All files required to set up this proof of concept environment are located here : https://github.com/bulutsal
Kayra Otaner 11 Mart 2014
Posted In: ElasticSearch, Gezegen, NetFlow
Yönetmekte olduğum bir sisteme sürekli olarak SYN paketleri gönderildiğini farketmemin üzerine çalışmalara başladım. Paketlerin gönderilme hızı değişkenlik gösteriyordu; çoğunlukla 1 paket/saniye hızında seyreden trafik zaman zaman saniyede 100 SYN paketi geçiyordu. Yavaş ulaşan paketler gerçek IP’lerden gelirken, hızlı gönderilenler değiştirilmiş kaynak IP sine (IP Spoofing) sahipti -ulaşan paketlerin TTL Time To Live değerlerindeki farklılıktan bunu tespit etmek mümkün-.
Evvelce etkinleştirdiğim SYNCookie özelliği sayesinde kaynak israfı çok artmıyor, sistemim cevap veremez hale gelmiyordu. (yoğun bir saldırıda SYNCookie CPU kullanımını sature edebilir)
netstat -ant|grep SYN_REC
SYNCookie özelliği sayesinde yukarıdaki komutu çalıştırdığımda SYN_REC durumunda bağlantı görmüyordum. Fakat SYNCookie gelen her SYN paketine SYN+ACK cevabı dönüyordu. Bunun önüne geçmeliydim. SYNCookie önlemine ek olarak, aynı IP’den gelen çok fazla SYN paketi olduğunda, bu IP lere SYN+ACK cevabı dönülmeyerek kara listeye alınmasının uygun olacağına karar verdim.
iptables -N SYNFLOOD iptables -A INPUT -p tcp --syn -j SYNFLOOD iptables -A SYNFLOOD -m recent --set --name KARALISTE iptables -A SYNFLOOD -m recent --update --seconds 10 --hitcount 20 --name KARALISTE -j DROP
İki günlük çabanın ve trafik incelemesinin ardından yukarıdaki satırları iptables üzerine tanımladım. Bu satırlar sayesinde dışarıdan sunucuya doğru gelen, 20paket/10saniye oranı aşan tüm tekil IP adresleri kara listeye alınacak ve bu oranın üzerinde kaldıkları süre boyunca gönderdiği SYN paketleri DROP edilecek. Bu orana karar verirken sunucunun trafiğini bir süre incelemem ve ona göre karar vermem gerekti. Bazı sistemler için bu oran agresif sayılabilir
İşlem tamamlandı, öncesinde sunucuyu sürekli meşgul edenler, bu çalışma sonrasında kısa süreli ziyaretler dışında uğramaz oldular.
Bana gelen saldırının odaklı bir saldırı olduğunu düşünmüyorum. Büyük bir bütünün, bir parçası olarak sistemin üzerinden trafik geçiriliyor olma ihtimali yüksek. Daha odaklı bir saldırı karşısında farklı savunma yöntemleri geliştirmek gerekeceği açık.
Gelelim izleme kısmına. Kimler bu filtreye takılıyor, anlık takılanların paket akışı, filtre kuralına takılan paket sayısı gibi bilgileri alalım şimdide;
cat /proc/net/xt_recent/KARALISTE
Ubuntu tabanlı sistemlerde yukarıdaki komut ile iptables filtresinde tanımladığımız isme göre oluşan dosyayı görüntülüyoruz. Bu dosyanın içinde, belirtilen hitcount oranın üzerine çıkan kaynak IP adresleri listeleniyor ve istenmeyen davranışı tekrarladıklarında zaman bilgisi güncelleniyor. Ayrıca TTL bilgisi gibi ek bilgiler de yeralıyor.
tcpdump -nni eth0 'tcp[13] = 2'
Yukarıdaki komut ile saldırı anında veya normal izleme sırasında sadece SYN bayraklı TCP paketlerini izleyebiliyoruz.
watch -n 0.5 'iptables -vL'
Yukarıdaki komut ile iptables üzerinde tanımladığımız kurallardan geçen trafik bilgisi anlık olarak izlenebiliyor.
Eklemek istedikleriniz veya farklı önerileriniz için çekinmeden yorum bırakabilirsiniz.
Hamdi ÖZCAN – ozcan.com
Hamdi Özcan 5 Mart 2014
Posted In: hitcount, iptables, lkd, SYN, syn-flood, syncookie, synflood, teknik, tr
Yönetmekte olduğum bir sisteme sürekli olarak SYN paketleri gönderildiğini farketmemin üzerine çalışmalara başladım. Paketlerin gönderilme hızı değişkenlik gösteriyordu; çoğunlukla 1 paket/saniye hızında seyreden trafik zaman zaman saniyede 100 SYN paketi geçiyordu. Yavaş ulaşan paketler gerçek IP’lerden gelirken, hızlı gönderilenler değiştirilmiş kaynak IP sine (IP Spoofing) sahipti -ulaşan paketlerin TTL Time To Live değerlerindeki farklılıktan bunu tespit etmek mümkün-.
Evvelce etkinleştirdiğim SYNCookie özelliği sayesinde kaynak israfı çok artmıyor, sistemim cevap veremez hale gelmiyordu. (yoğun bir saldırıda SYNCookie CPU kullanımını sature edebilir)
netstat -ant|grep SYN_REC
SYNCookie özelliği sayesinde yukarıdaki komutu çalıştırdığımda SYN_REC durumunda bağlantı görmüyordum. Fakat SYNCookie gelen her SYN paketine SYN+ACK cevabı dönüyordu. Bunun önüne geçmeliydim. SYNCookie önlemine ek olarak, aynı IP’den gelen çok fazla SYN paketi olduğunda, bu IP lere SYN+ACK cevabı dönülmeyerek kara listeye alınmasının uygun olacağına karar verdim.
iptables -N SYNFLOOD iptables -A INPUT -p tcp --syn -j SYNFLOOD iptables -A SYNFLOOD -m recent --set --name KARALISTE iptables -A SYNFLOOD -m recent --update --seconds 10 --hitcount 20 --name KARALISTE -j DROP
İki günlük çabanın ve trafik incelemesinin ardından yukarıdaki satırları iptables üzerine tanımladım. Bu satırlar sayesinde dışarıdan sunucuya doğru gelen, 20paket/10saniye oranı aşan tüm tekil IP adresleri kara listeye alınacak ve bu oranın üzerinde kaldıkları süre boyunca gönderdiği SYN paketleri DROP edilecek. Bu orana karar verirken sunucunun trafiğini bir süre incelemem ve ona göre karar vermem gerekti. Bazı sistemler için bu oran agresif sayılabilir
İşlem tamamlandı, öncesinde sunucuyu sürekli meşgul edenler, bu çalışma sonrasında kısa süreli ziyaretler dışında uğramaz oldular.
Bana gelen saldırının odaklı bir saldırı olduğunu düşünmüyorum. Büyük bir bütünün, bir parçası olarak sistemin üzerinden trafik geçiriliyor olma ihtimali yüksek. Daha odaklı bir saldırı karşısında farklı savunma yöntemleri geliştirmek gerekeceği açık.
Gelelim izleme kısmına. Kimler bu filtreye takılıyor, anlık takılanların paket akışı, filtre kuralına takılan paket sayısı gibi bilgileri alalım şimdide;
cat /proc/net/xt_recent/KARALISTE
Ubuntu tabanlı sistemlerde yukarıdaki komut ile iptables filtresinde tanımladığımız isme göre oluşan dosyayı görüntülüyoruz. Bu dosyanın içinde, belirtilen hitcount oranın üzerine çıkan kaynak IP adresleri listeleniyor ve istenmeyen davranışı tekrarladıklarında zaman bilgisi güncelleniyor. Ayrıca TTL bilgisi gibi ek bilgiler de yeralıyor.
tcpdump -nni eth0 'tcp[13] = 2'
Yukarıdaki komut ile saldırı anında veya normal izleme sırasında sadece SYN bayraklı TCP paketlerini izleyebiliyoruz.
watch -n 0.5 'iptables -vL'
Yukarıdaki komut ile iptables üzerinde tanımladığımız kurallardan geçen trafik bilgisi anlık olarak izlenebiliyor.
Eklemek istedikleriniz veya farklı önerileriniz için çekinmeden yorum bırakabilirsiniz.
Hamdi ÖZCAN – ozcan.com
Hamdi Özcan 5 Mart 2014
Posted In: hitcount, iptables, lkd, SYN, syn-flood, syncookie, synflood, teknik, tr
Ping komutunun alışılagelmiş hızı içinizi baymaya başladıysa;
Linux tabanlı sistemlerde -i parametresi ile hız arttırılabiliyor. 0.2 saniyeden daha hızlı olsun istiyorsanız root yetkilerini kullanmanız gerekiyor.
sudo ping -i 0.1 localhost
Windows tabanlı sistemlerde üçüncü parti uygulamalar kullanılması gerekiyor. hrPING hızlı ping atabilme yeteneğine sahip.
hrping -s 100 -t localhost
Artık ping komutundan nasıl performans alınacağını biliyorsunuz, hızlı vızıldamalar.
Hamdi Özcan 2 Mart 2014
Ping komutunun alışılagelmiş hızı içinizi baymaya başladıysa;
Linux tabanlı sistemlerde -i parametresi ile hız arttırılabiliyor. 0.2 saniyeden daha hızlı olsun istiyorsanız root yetkilerini kullanmanız gerekiyor.
sudo ping -i 0.1 localhost
Windows tabanlı sistemlerde üçüncü parti uygulamalar kullanılması gerekiyor. hrPING hızlı ping atabilme yeteneğine sahip.
hrping -s 100 -t localhost
Artık ping komutundan nasıl performans alınacağını biliyorsunuz, hızlı vızıldamalar.
Hamdi Özcan 1 Mart 2014
flock -w 5 /herhangi/bir/yol komut-w 5: eğer komut kullanımdaysa, belirtilen saniye kadar bekle. belirtilen sürede komut boşa çıkar ise, komutunu çalıştır.
flock -w 0 /space/deneme cp /dizin/kaynak/* /dizin/hedef/
Volkan Yalçın 1 Mart 2014