Linux за българи: Форуми

Какво става  по въпроса с тия "трафични данни". Някой има ли конкретна информация?
Ако трябва да се прави как го прави?

На скоро искаха от нас трафични данни (със съдебно решение), съответно трябва да се съхраняват трафични данни.
Така и не отделих време за този проблем. Няма да е лошо да интегрирам някакво решение в системата. Някои колеги използвали tcpdump, но аз си мисля за iptables --log
Ако намериш някое елегантно решение сподели и с нас.

ами и аз си мисля за --лог....

iptables -A ....  LOG --log-prefix='[netfilter] '

 и в рсиъслог да сложа такава настойка  /etc/rsyslog.d/my_iptables.conf

:msg,contains,"[netfilter] " /var/log/iptables.log

който да ротирам???? може би... колко голям лог ще изплющи тва за денонощие!??!


PS:
инсталирах си ulog2 защото с таргет ЛОГ флуди дмесг и така :

iptables -I INPUT -m state --state NEW -j NFLOG --nflog-prefix  "iptables_log: "
iptables -I OUTPUT -m state --state NEW -j NFLOG --nflog-prefix  "iptables_log: "

да видим ко ши стани :)

Какво възприемате за трафични данни?
:)
Какво искате да записвате?

По закон нямате право на пълен дъмп освен изрично, по искан по ЗЕС с изрично указано начало и край и сродните закони.

По закон нямате право на пълен дъмп освен изрично, по искан по ЗЕС с изрично указано начало и край и сродните закони.

Ако зависеше от мен бих казал, който иска да следи кой какво прави, сам да се оправя...
Никой не говори за пълен дъмп, IP - MAC --> IP в определено време и лог за 1 месец на зад.

Аз пък тествах:

tcpdump -ni eth0 -s 96 -w eth0.pcap

# ls -lh
-rw-r--r-- 1 root     root      14M Nov  9 20:55 eth0.pcap

tcpdump -r eth0.pcap | less

За няма и 30 сек. 14M файл с 45 Mbit плътен трафик.
Натоварването на CPU: ~2-3%

Трябва да се спрем на вариянта, който най-малко ще се отрази на мрежовата производителност. Ако tcpdump само прихваща трафика, без да се отразява на мрежовата проиводителност...

нямам идея какво става :

http://legalworld.bg/53292.trafichni-danni-shte-se-izpolzvat-i-za-izdirvane-na-jertvi-na-tejki-prestypleniia.html

новина от май месец 2016

или

https://www.google.com/search?q=%D1%82%D1%80%D0%B0%D1%84%D0%B8%D1%87%D0%BD%D0%B8+%D0%B4%D0%B0%D0%BD%D0%BD%D0%B8&ie=utf-8&oe=utf-8&client=firefox-b

Пример, има флууд към държавен уеб сайд:
В този случай, ще искат на
2016.11.09 21:56 от IP (може да конкретизират и MAC) към кое IP има заявки и информация за клиента (ако има такъм IP адрес в мрежата).

Другия проблем са частните IP адреси, понеже ще искат инфо за реален IP адрес. Това означава в това време, кое частно IP с кое реално IP е било натнато.

Пример, има флууд към държавен уеб сайд:
В този случай, ще искат на
2016.11.09 21:56 от IP (може да конкретизират и MAC) към кое IP има заявки и информация за клиента (ако има такъм IP адрес в мрежата).

Другия проблем са частните IP адреси, понеже ще искат инфо за реален IP адрес. Това означава в това време, кое частно IP с кое реално IP е било натнато.

то така де... ама това означава да пазиш тези данни за 6 месеца назад?

   Пичове, добре си разсъждатате,но аз бих се замислил за смисъла
от всичко това ...
   Престъпниците трябва да са малоумни, за да не използват tor .
   И,какво ще се види от тези "трафични данни" - веднъж айпи напр.  от
Германия,после от Франция,Швеция,Холандия ...  ;D

Това само за интернет доставчици ли е. Ако става дума за отворен wifi на публично място тип хотел, кафене, търговски център... как стои въпроса? Трябва ли да се пазят разни логове?

Tor не е панацея. Могат да те намерят и през него. Ако аз бих правил такова нещо, бих заразил с нещо няколко стотин компютъра или колкото мога там за два-три месеца и после само ще им кажа да флудят на воля. От мойта машина нищо няма да излезе. Също, ще спра някъде с колата на няколко стотин метра от някоя бензиностанция, ще си пъхна хубава антена в юесбито на лапито и ще ги изкомандвам от там. А пък и свободни мрежи, колкото искате в града. Тя и моята е свободна

   Съгласен съм, че Tor не е панацея. Но все пак е много трудно да бъде
хакнат по някакъв начин.
   Освен от ... пентагона. Те не крият,че Tor е тяхна разработка, и е почти
сигурно, че са си оставили "задни вратички" ...
   Само че,не мога да си представя Явор Колев или подобен на него да
моли пентагона за това или онова  ;D
   
// off
   Абе,къде е gat3way,липсата му се усеща във форума, а и темата е от
неговата компетентност.

Не говоря за хакване на Tor. Има си индиректни начини.

A за NetFlow/sFlow/IPFIX решения не сте ли мислили?

   Стана ми интересно за тези "индиректни начини".
   Има 2 варианта:
   1. Слабо криптиране и/или уязвимости в съотв. протоколи (малко вероятно).
   2. Прецизен анализ на трафика.
   По отношение на т.2: Ако службите са вменили на доставчиците да следят кои и
по кое време ползват Tor, може напр. да съществуват логове:кой, от колко до колко
часа и от кое айпи е влизал в Tor ; тогава може да се предположи с някаква
вероятност в кой сайт е влизал: от логовете на съотв. сайт се вижда и по кое време.
   Но и това е трудно постижимо ...

Малко по-подробна информация относно идеята на колегата edmon:


apt-get install ulogd
modprobe nf_conntrack_netlink
iptables -A FORWARD -m state --state NEW -j NFLOG --nflog-group 2 --nflog-prefix [NEW]


nano /etc/ulogd.conf

[global]
logfile="syslog"
loglevel=3
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inppkt_NFLOG.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inpflow_NFCT.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_raw2packet_BASE.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_IFINDEX.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_IP2STR.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_PRINTPKT.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_PRINTFLOW.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_LOGEMU.so"
plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_SYSLOG.so"

stack=log1:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu1:LOGEMU
stack=ct1:NFCT,ip2str1:IP2STR,print1:PRINTFLOW,emu1:LOGEMU

[ct1]
netlink_socket_buffer_size=217088
netlink_socket_buffer_maxsize=1085440
#netlink_resync_timeout=60 # seconds to wait to perform resynchronization
#pollinterval=10 # use poll-based logging instead of event-driven
# If pollinterval is not set, NFCT plugin will work in event mode
# In this case, you can use the following filters on events:
#accept_src_filter=192.168.1.0/24,1:2::/64 # source ip of connection must belong to these networks
#accept_dst_filter=192.168.1.0/24 # destination ip of connection must belong to these networks
#accept_proto_filter=tcp,sctp # layer 4 proto of connections

[log1]
group=2
netlink_socket_buffer_size=217088
netlink_socket_buffer_maxsize=1085440
# set number of packet to queue inside kernel
#netlink_qthreshold=1
# set the delay before flushing packet in the queue inside kernel (in 10ms)
#netlink_qtimeout=100

[emu1]
file="/var/log/ulog/traffic_data.log"
sync=1

/etc/init.d/ulogd2 restart

Настроени по този начин iptables и ulogd съхраняват информация за всички нови връзки и всички затворени връзки.

Добавих тази функционалност към системата:
https://github.com/mysticall/imslu/commit/c50c2b1f26f1e47525694bc950961e6a8e4a1251 ($2)

може да добавиш в настройката на логротате за улог да ги върти 185 дни например.