-
Notifications
You must be signed in to change notification settings - Fork 596
/
readme.txt
1974 lines (1616 loc) · 201 KB
/
readme.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
zapret v.65
English
-------
For english version refer to docs/readme.eng.txt
Для чего это надо
-----------------
Автономное, без задействования сторонних серверов, средство противодействия DPI.
Может помочь обойти блокировки или замедление сайтов http(s), сигнатурный анализ tcp и udp протоколов,
например с целью блокировки VPN.
Проект нацелен прежде всего на маломощные embedded устройства - роутеры, работающие под openwrt.
Поддерживаются традиционные Linux системы, FreeBSD, OpenBSD, частично MacOS.
В некоторых случаях возможна самостоятельная прикрутка решения к различным прошивкам.
Большая часть функционала работает на windows.
Как побыстрее начать
--------------------
Читайте docs/quick_start.txt для linux и openwrt, docs/quick_start_windows.txt для windows.
Как это работает
----------------
В самом простейшем случае вы имеете дело с пассивным DPI. Пассивный DPI может читать трафик
из потока, может инжектить свои пакеты, но не может блокировать проходящие пакеты.
Если запрос "плохой", пассивный DPI инжектит пакет RST, опционально дополняя его пакетом http redirect.
Если фейк пакет инжектится только для клиента, в этом случае можно обойтись командами iptables
для дропа RST и/или редиректа на заглушку по определенным условиям, которые нужно подбирать
для каждого провайдера индивидуально. Так мы обходим последствия срабатывания триггера запрета.
Если пассивный DPI направляет пакет RST в том числе и серверу, то вы ничего с этим не сможете сделать.
Ваша задача - не допустить срабатывания триггера запрета. Одними iptables уже не обойдетесь.
Этот проект нацелен именно на предотвращение срабатывания запрета, а не ликвидацию его последствий.
Активный DPI ставится в разрез провода и может дропать пакеты по любым критериям,
в том числе распознавать TCP потоки и блокировать любые пакеты, принадлежащие потоку.
Как не допустить срабатывания триггера запрета ? Послать то, на что DPI не рассчитывает
и что ломает ему алгоритм распознавания запросов и их блокировки.
Некоторые DPI не могут распознать http запрос, если он разделен на TCP сегменты.
Например, запрос вида "GET / HTTP/1.1\r\nHost: kinozal.tv......"
мы посылаем 2 частями : сначала идет "GET ", затем "/ HTTP/1.1\r\nHost: kinozal.tv.....".
Другие DPI спотыкаются, когда заголовок "Host:" пишется в другом регистре : например, "host:".
Кое-где работает добавление дополнительного пробела после метода : "GET /" => "GET /"
или добавление точки в конце имени хоста : "Host: kinozal.tv."
Существует и более продвинутая магия, направленная на преодоление DPI на пакетном уровне.
Подробнее про DPI :
https://habr.com/ru/post/335436
https://geneva.cs.umd.edu/papers/geneva_ccs19.pdf
Что сейчас происходит в России
------------------------------
Раньше, до внедрения повсеместных систем ТСПУ, использовался зоопарк различных DPI
у провайдеров. Какие-то были активными, какие-то пассивными.
Сейчас время простых iptables окончательно ушло. Везде активный DPI ТСПУ, но кое-где
могут оставаться невыключенными дополнительные старые DPI из зоопарка.
В этом случае приходится обходить сразу несколько DPI.
Все больше становится внереестровых блокировок, о которых вы узнаете только по факту
недоступности чего-либо, в списках этого нет.
Применяются блокировки некоторых диапазонов ip адресов (автономный обход невозможен)
и протоколов (VPN).
На некоторых диапазонах IP используется более строгий фильтр, распознающий попытки
обмана через сегментацию. Должно быть это связано с некоторыми сервисами, которые
пытаются таким образом обмануть DPI.
Как это реализовать на практике в системе linux
-----------------------------------------------
Если кратко, то варианты можно классифицировать по следующей схеме :
1) Пассивный DPI, не отправляющий RST серверу. Помогут индивидуально настраиваемые под провайдера команды iptables.
На rutracker в разделе "обход блокировок - другие способы" по этому вопросу существует отдельная тема.
В данном проекте не рассматривается. Если вы не допустите срабатывание триггера запрета, то и не придется
бороться с его последствиями.
2) Модификация TCP соединения на уровне потока. Реализуется через proxy или transparent proxy.
3) Модификация TCP соединения на уровне пакетов. Реализуется через обработчик очереди NFQUEUE и raw сокеты.
Для вариантов 2 и 3 реализованы программы tpws и nfqws соответственно.
Чтобы они работали, необходимо их запустить с нужными параметрами и перенаправить на них определенный трафик
средствами iptables или nftables.
Для перенаправления tcp соединения на transparent proxy используются команды следующего вида :
проходящий трафик :
iptables -t nat -I PREROUTING -i <внутренний_интерфейс> -p tcp --dport 80 -j DNAT --to 127.0.0.127:988
исходящий трафик :
iptables -t nat -I OUTPUT -o <внешний_интерфейс> -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to 127.0.0.127:988
DNAT на localhost работает в цепочке OUTPUT, но не работает в цепочке PREROUTING без включения параметра route_localnet :
sysctl -w net.ipv4.conf.<внутренний_интерфейс>.route_localnet=1
Можно использовать "-j REDIRECT --to-port 988" вместо DNAT, однако в этом случае процесс transparent proxy
должен слушать на ip адресе входящего интерфейса или на всех адресах. Слушать на всех - не есть хорошо
с точки зрения безопасности. Слушать на одном (локальном) можно, но в случае автоматизированного
скрипта придется его узнавать, потом динамически вписывать в команду. В любом случае требуются дополнительные усилия.
Использование route_localnet тоже имеет потенциальные проблемы с безопасностью. Вы делаете доступным все, что висит
на 127.0.0.0/8 для локальной подсети <внутренний_интерфейс>. Службы обычно привязываются к 127.0.0.1, поэтому можно
средствами iptables запретить входящие на 127.0.0.1 не с интерфейса lo, либо повесить tpws на любой другой IP из
из 127.0.0.0/8, например на 127.0.0.127, и разрешить входящие не с lo только на этот IP.
iptables -A INPUT ! -i lo -d 127.0.0.127 -j ACCEPT
iptables -A INPUT ! -i lo -d 127.0.0.0/8 -j DROP
Фильтр по owner необходим для исключения рекурсивного перенаправления соединений от самого tpws.
tpws запускается под пользователем "tpws", для него задается исключающее правило.
tpws может использоваться в режиме socks proxy. В этом случае iptables не нужны, а нужно прописать socks
в настройки программы (например, броузера), с которой будем обходить блокировки.
transparent proxy отличается от socks именно тем, что в варианте transparent настраивать клиентские программы не нужно.
Для перенаправления на очередь NFQUEUE исходящего и проходящего в сторону внешнего интерфейса трафика используются
команды следующего вида :
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -j NFQUEUE --queue-num 200 --queue-bypass
Чтобы не трогать трафик на незаблокированные адреса, можно взять список заблокированных хостов, заресолвить его
в IP адреса и загнать в ipset zapret, затем добавить фильтр в команду :
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass
DPI может ловить только первый http запрос, игнорируя последующие запросы в keep-alive сессии.
Тогда можем уменьшить нагрузку на проц, отказавшись от процессинга ненужных пакетов.
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:6 -m mark ! --mark 0x40000000/0x40000000 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass
Фильтр по mark нужен для отсечения от очереди пакетов, сгенерированных внутри nfqws.
Если применяется фильтр по connbytes 1:6, то обязательно добавлять в iptables и фильтр по mark. Иначе возможно
перепутывание порядка следования пакетов, что приведет к неработоспособности метода.
Для некоторых атак на DPI требуется перенаправлять один или несколько входящих пакетов от соединения :
iptables -t mangle -I PREROUTING -i <внешний_интерфейс> -p tcp --sport 80 -m connbytes --connbytes-dir=reply --connbytes-mode=packets --connbytes 1:6 -m set --match-set zapret src -j NFQUEUE --queue-num 200 --queue-bypass
Получаемые пакеты будут фильтроваться по входящему интерфейсу, порту и IP источника, то есть наоборот прямому правилу.
Некоторые техники, ломающие NAT, не всегда можно реализовать через iptables. Требуются nftables.
Если ваше устройство поддерживает аппаратное ускорение (flow offloading, hardware nat, hardware acceleration), то iptables могут не работать.
При включенном offloading пакет не проходит по обычному пути netfilter.
Необходимо или его отключить, или выборочно им управлять.
В новых ядрах (и в более старых, openwrt портировал изменение на 4.14) присутствует software flow offloading (SFO).
Пакеты, проходящие через SFO, так же проходят мимо большей части механизмов iptables.
При включенном SFO работает DNAT/REDIRECT (tpws). Эти соединения исключаются из offloading.
Однако, остальные соединения идут через SFO, потому NFQUEUE будет срабатывать только до помещения
соединения в flowtable. Практически это означает, что nfqws будет работать на window size changing,
но не будут работать опции по модификации содержимого пакетов.
Offload включается через специальный target в iptables "FLOWOFFLOAD". Не обязательно пропускать весь трафик через offload.
Можно исключить из offload соединения, которые должны попасть на tpws или nfqws.
openwrt не предусматривает выборочного управления offload.
Поэтому скрипты zapret поддерживают свою систему выборочного управления offload в openwrt.
Особенности применения ip6tables
--------------------------------
ip6tables работают почти точно так же, как и ipv4, но есть ряд важных нюансов.
В DNAT следует брать адрес --to в квадратные скобки. Например :
ip6tables -t nat -I OUTPUT -o <внешний_интерфейс> -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to [::1]:988
Параметра route_localnet не существует для ipv6.
DNAT на localhost (::1) возможен только в цепочке OUTPUT.
В цепочке PREROUTING DNAT возможен на любой global address или на link local address того же интерфейса,
откуда пришел пакет.
NFQUEUE работает без изменений.
Особенности применения nftables
-------------------------------
Более подробно преимущества и недостатки nftables применительно к данной системе описаны в docs/nftables_notes.txt
Если коротко, то в nftables невозможно работать с большими ip листами на системах с малым количеством RAM.
Остальные рассматриваемые здесь функции могут быть перенесены на nftables.
Рекомендуется версия nft 1.0.2 или выше. Но чем выше версия, тем лучше. В nft регулярно находят баги.
Относительно старые версии ядра и/или утилиты nft могут вызывать ошибки.
В частности, на ubuntu 18.04 с ядром 4.15 будут проблемы. В 20.04 - работает.
Некоторые техники можно полноценно использовать только с nftables.
Например, в iptables невозможно перенаправить пакеты на nfqws после NAT.
Следовательно, при использовании NAT невозможно произвести атаку, не совместимую с NAT.
В nftables этой проблемы не существует, потому что приоритеты хука выставляете вы сами, а не привязаны к фиксированным
значениям, соответствующим разным таблицам iptables. В iptables нет таблицы, способной перехватить пакеты после MASQUERDADE.
Когда это работать не будет
---------------------------
* Если подменяется DNS. С этой проблемой легко справиться.
* Если блокировка осуществляется по IP.
* Если соединение проходит через фильтр, способный реконструировать TCP соединение, и который
следует всем стандартам. Например, нас заворачивают на squid. Соединение идет через полноценный стек tcpip
операционной системы, фрагментация отпадает сразу как средство обхода. Squid правильный, он все найдет
как надо, обманывать его бесполезно.
НО. Заворачивать на squid могут позволить себе лишь небольшие провайдеры, поскольку это очень ресурсоемко.
Большие компании обычно используют DPI, который рассчитан на гораздо большую пропускную способность.
Может применяться комбинированный подход, когда на DPI заворачивают только IP из "плохого" списка,
и дальше уже DPI решает пропускать или нет. Так можно снизить нагрузку на DPI в десятки, если не сотни раз,
а следовательно не покупать очень дорогие решения, обойдясь чем-то существенно более дешевым.
Мелкие провайдеры могут покупать услугу фильтрации у вышестоящих, чтобы самим не морочиться, и
они уже будут применять DPI.
nfqws
-----
Эта программа - модификатор пакетов и обработчик очереди NFQUEUE.
Для BSD систем существует адаптированный вариант - dvtws, собираемый из тех же исходников (см. bsd.txt).
--debug=0|1 ; 1=выводить отладочные сообщения
--daemon ; демонизировать прогу
--pidfile=<file> ; сохранить PID в файл
--user=<username> ; менять uid процесса
--uid=uid[:gid] ; менять uid процесса
--qnum=N ; номер очереди N
--bind-fix4 ; пытаться решить проблему неверного выбора исходящего интерфейса для сгенерированных ipv4 пакетов
--bind-fix6 ; пытаться решить проблему неверного выбора исходящего интерфейса для сгенерированных ipv6 пакетов
--wsize=<winsize>[:<scale_factor>] ; менять tcp window size на указанный размер в SYN,ACK. если не задан scale_factor, то он не меняется (устарело !)
--wssize=<winsize>[:<scale_factor>] ; менять tcp window size на указанный размер в исходящих пакетах. scale_factor по умолчанию 0. (см. conntrack !)
--wssize-cutoff=[n|d|s]N ; изменять server window size в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру меньше N
--ctrack-timeouts=S:E:F[:U] ; таймауты внутреннего conntrack в состояниях SYN, ESTABLISHED, FIN, таймаут udp. по умолчанию 60:300:60:60
--hostcase ; менять регистр заголовка "Host:" по умолчанию на "host:".
--hostnospace ; убрать пробел после "Host:" и переместить его в конец значения "User-Agent:" для сохранения длины пакета
--hostspell=HoST ; точное написание заголовка Host (можно "HOST" или "HoSt"). автоматом включает --hostcase
--domcase ; домен после Host: сделать таким : TeSt.cOm
--dpi-desync=[<mode0>,]<mode>[,<mode2] ; атака по десинхронизации DPI. mode : synack syndata fake fakeknown rst rstack hopbyhop destopt ipfrag1 disorder disorder2 split split2 ipfrag2 udplen tamper
--dpi-desync-fwmark=<int|0xHEX> ; бит fwmark для пометки десинхронизирующих пакетов, чтобы они повторно не падали в очередь. default = 0x40000000
--dpi-desync-ttl=<int> ; установить ttl для десинхронизирующих пакетов
--dpi-desync-ttl6=<int> ; установить ipv6 hop limit для десинхронизирующих пакетов. если не указано, используется значение ttl
--dpi-desync-autottl=[<delta>[:<min>[-<max>]]] ; режим auto ttl для ipv4 и ipv6. по умолчанию: 1:3-20. delta=0 отключает функцию.
--dpi-desync-autottl6=[<delta>[:<min>[-<max>]]] ; переопределение предыдущего параметра для ipv6
--dpi-desync-fooling=<fooling> ; дополнительные методики как сделать, чтобы фейковый пакет не дошел до сервера. none md5sig badseq badsum datanoack hopbyhop hopbyhop2
--dpi-desync-repeats=<N> ; посылать каждый генерируемый в nfqws пакет N раз (не влияет на остальные пакеты)
--dpi-desync-skip-nosni=0| 1 ; 1(default)=не применять dpi desync для запросов без hostname в SNI, в частности для ESNI
--dpi-desync-split-pos=<1..1500> ; (только для split*, disorder*) разбивать пакет на указанной позиции
--dpi-desync-split-http-req=method|host ; разбивка http request на указанном логическом месте
--dpi-desync-split-tls=sni|sniext ; разбивка tls client hello на указанном логическом месте
--dpi-desync-split-seqovl=<int> ; использовать sequence overlap перед первым отсылаемым оригинальным tcp сегментом
--dpi-desync-split-seqovl-pattern=<filename>|0xHEX ; чем заполнять фейковую часть overlap
--dpi-desync-badseq-increment=<int|0xHEX> ; инкремент sequence number для badseq. по умолчанию -10000
--dpi-desync-badack-increment=<int|0xHEX> ; инкремент ack sequence number для badseq. по умолчанию -66000
--dpi-desync-any-protocol=0|1 ; 0(default)=работать только по http request и tls clienthello 1=по всем непустым пакетам данных
--dpi-desync-fake-http=<filename>|0xHEX ; файл, содержащий фейковый http запрос для dpi-desync=fake, на замену стандартному www.iana.org
--dpi-desync-fake-tls=<filename>|0xHEX ; файл, содержащий фейковый tls clienthello для dpi-desync=fake, на замену стандартному
--dpi-desync-fake-unknown=<filename>|0xHEX ; файл, содержащий фейковый пейлоад неизвестного протокола для dpi-desync=fake, на замену стандартным нулям 256 байт
--dpi-desync-fake-syndata=<filename>|0xHEX ; файл, содержащий фейковый пейлоад пакета SYN для режима десинхронизации syndata
--dpi-desync-fake-quic=<filename>|0xHEX ; файл, содержащий фейковый QUIC Initial
--dpi-desync-fake-dht=<filename>|0xHEX ; файл, содержащий фейковый пейлоад DHT протокола для dpi-desync=fake, на замену стандартным нулям 64 байт
--dpi-desync-fake-unknown-udp=<filename>|0xHEX ; файл, содержащий фейковый пейлоад неизвестного udp протокола для dpi-desync=fake, на замену стандартным нулям 64 байт
--dpi-desync-udplen-increment=<int> ; насколько увеличивать длину udp пейлоада в режиме udplen
--dpi-desync-udplen-pattern=<filename>|0xHEX ; чем добивать udp пакет в режиме udplen. по умолчанию - нули
--dpi-desync-start=[n|d|s]N ; применять dpi desync только в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру больше или равно N
--dpi-desync-cutoff=[n|d|s]N ; применять dpi desync только в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру меньше N
--hostlist=<filename> ; применять дурение только к хостам из листа. может быть множество листов, они объединяются. пустой обший лист = его отсутствие
--hostlist-exclude=<filename> ; не применять дурение к хостам из листа. может быть множество листов, они объединяются
--hostlist-auto=<filename> ; обнаруживать автоматически блокировки и заполнять автоматический hostlist (требует перенаправления входящего трафика)
--hostlist-auto-fail-threshold=<int> ; сколько раз нужно обнаружить ситуацию, похожую на блокировку, чтобы добавить хост в лист (по умолчанию: 3)
--hostlist-auto-fail-time=<int> ; все эти ситуации должны быть в пределах указанного количества секунд (по умолчанию: 60)
--hostlist-auto-retrans-threshold=<int> ; сколько ретрансмиссий запроса считать блокировкой (по умолчанию: 3)
--hostlist-auto-debug=<logfile> ; лог положительных решений по autohostlist. позволяет разобраться почему там появляются хосты.
--new ; начало новой стратегии
--filter-l3=ipv4|ipv6 ; фильтр версии ip для текущей стратегии
--filter-tcp=[~]port1[-port2] ; фильтр портов tcp для текущей стратегии. ~ означает инверсию. установка фильтра tcp и неустановка фильтра udp запрещает udp.
--filter-udp=[~]port1[-port2] ; фильтр портов udp для текущей стратегии. ~ означает инверсию. установка фильтра udp и неустановка фильтра tcp запрещает udp.
--filter-l7=[http|tls|quic|wireguard|dht|unknown] ; фильтр протокола L6-L7. поддерживается несколько значений через запятую.
--ipset=<filename> ; включающий ip list. на каждой строчке ip или cidr ipv4 или ipv6. поддерживается множество листов и gzip.
--ipset-exclude=<filename> ; исключающий ip list. на каждой строчке ip или cidr ipv4 или ipv6. поддерживается множество листов и gzip.
Параметры манипуляции могут сочетаться в любых комбинациях.
ЗАМЕЧАНИЕ. Параметр --wsize считается устаревшим и более не поддерживается в скриптах.
Функции сплита выполняются в рамках атаки десинхронизации. Это быстрее и избавляет от целого ряда недостатков wsize.
--debug позволяет выводить подробный лог действий на консоль, в syslog или в файл.
Может быть важен порядок следования опций. --debug лучше всего указывать в самом начале.
Опции анализируются последовательно. Если ошибка будет при проверке опции, а до анализа --debug еще дело не дошло,
то сообщения не будут выведены в файл или syslog.
При логировании в файл процесс не держит файл открытым. Ради каждой записи файл открывается и потом закрывается.
Так что файл можно удалить в любой момент, и он будет создан заново при первом же сообщении в лог.
Но имейте в виду, что если вы запускаете процесс под root, то будет сменен UID на не-root.
В начале на лог файл меняется owner, иначе запись будет невозможна. Если вы потом удалите файл,
и у процесса не будет прав на создание файла в его директории, лог больше не будет вестись.
Вместо удаления лучше использовать truncate.
В шелле это можно сделать через команду ": >filename"
АТАКА ДЕСИНХРОНИЗАЦИИ DPI
Суть ее в следующем. После выполнения tcp 3-way handshake идет первый пакет с данными от клиента.
Там обычно "GET / ..." или TLS ClientHello. Мы дропаем этот пакет, заменяя чем-то другим.
Это может быть поддельная версия с безобидным, но валидным запросом http или https (вариант fake),
пакет сброса соединения (варианты rst, rstack), разбитый на части оригинальный пакет с перепутанным
порядком следования сегментов + обрамление первого сегмента фейками (disorder),
то же самое без перепутывания порядка сегментов (split).
fakeknown отличается от fake тем, что применяется только к распознанному протоколу.
В литературе такие атаки еще называют TCB desynchronization и TCB teardown.
Надо, чтобы фейковые пакеты дошли до DPI, но не дошли до сервера.
На вооружении есть следующие возможности : установить низкий TTL, посылать пакет с инвалидной чексуммой,
добавлять tcp option "MD5 signature", испортить sequence numbers. Все они не лишены недостатков.
* md5sig работает не на всех серверах. Пакеты с md5 обычно отбрасывают только linux.
* badsum не сработает, если ваше устройство за NAT, который не пропускает пакеты с инвалидной суммой.
Наиболее распространенная настройка NAT роутера в Linux их не пропускает. На Linux построено большинство
домашних роутеров. Непропускание обеспечивается так : настройка ядра sysctl по умолчанию
net.netfilter.nf_conntrack_checksum=1 заставляет conntrack проверять tcp и udp чексуммы входящих пакетов
и выставлять state INVALID для пакетов с инвалидной суммой.
Обычно в правилах iptables вставляется правило для дропа пакетов с состоянием INVALID в цепочке FORWARD.
Совместное сочетание этих факторов приводит к непрохождению badsum через такой роутер.
В openwrt из коробки net.netfilter.nf_conntrack_checksum=0, в других роутерах часто нет,
и не всегда это можно изменить. Чтобы nfqws мог работать через роутер, нужно на нем выставить указанное
значение sysctl в 0. nfqws на самом роутере будет работать и без этой настройки, потому что
чексумма локально созданных пакетов не проверяется никогда.
Если роутер за другим NAT, например провайдерским, и он не пропускает invalid packets
вы ничего не сможете с этим сделать. Но обычно провайдеры все же пропускают badsum.
На некоторых адаптерах/свитчах/драйверах принудительно включен rx-checksum offload, badsum пакеты отсекаются
еще до получения в ОС. В этом случае если что-то и можно сделать, то только модифицировать драйвер,
что представляется задачей крайне нетривиальной. Установлено, что так себя ведут некоторые роутеры на базе mediatek.
badsum пакеты уходят с клиентской ОС, но роутером не видятся в br-lan через tcpdump.
При этом если nfqws выполняется на самом роутере, обход может работать. badsum нормально уходят с внешнего интерфейса.
* Пакеты с badseq будут наверняка отброшены принимающим узлом, но так же и DPI, если он ориентируется
на sequence numbers. По умолчанию смещение seq выбирается -10000. Практика показала, что некоторые DPI
не пропускают seq вне определенного окна. Однако, такое небольшое смещение может вызвать проблемы
при существенной потоковой передаче и потере пакетов. Если вы используете --dpi-desync-any-protocol,
может понадобится установить badseq increment 0x80000000. Это обеспечит надежную гарантию,
что поддельный пакет не вклинится в tcp window на сервере. Так же было замечено, что badseq ломает логику
некоторых DPI при анализе http, вызывая зависание соединения. Причем на тех же DPI TLS с badseq работает нормально.
* TTL казалось бы - лучший вариант, но он требует индивидуальной настройки под каждого провайдера.
Если DPI находится дальше локальных сайтов провайдера, то вы можете отрезать себе доступ к ним.
Ситуация усугубляется наличием ТСПУ на магистралах, что вынуждает делать TTL достаточно высоким, увеличивая
риск пробоя фейка до сервера.
Необходим ip exclude list, заполняемый вручную. Вместе с ttl можно применять md5sig. Это ничего не испортит,
зато дает неплохой шанс работы сайтов, до которых "плохой" пакет дойдет по TTL.
Если не удается найти автоматическое решение, воспользуйтесь файлом zapret-hosts-user-exclude.txt.
Некоторые стоковые прошивки роутеров фиксируют исходящий TTL, без отключения этой опции через них работать не будет.
КАКИМ СТОИТ ВЫБИРАТЬ TTL : найдите минимальное значение, при котором обход еще работает.
Это и будет номер хопа вашего DPI.
* hopbyhop относится только к ipv6. Добавляется ipv6 extenstion header "hop-by-hop options".
В варианте hopbyhop2 добавляются 2 хедера, что является нарушением стандарта и гарантированно отбрасывается
стеком протоколов во всех ОС. Один хедер hop-by-hop принимается всеми ОС, однако на некоторых каналах/провайдерах
такие пакеты могут фильтроваться и не доходить. Расчет идет на то, что DPI проанализирует пакет с hop-by-hop,
но он либо не дойдет до адресата всилу фильтров провайдера, либо будет отброшен сервером, потому что хедера два.
* datanoack высылает фейки со снятым tcp флагом ACK. Сервера такое не принимают, а DPI может принять.
Эта техника может ломать NAT и не всегда работает с iptables, если используется masquerade, даже с локальной
системы (почти всегда на роутерах ipv4). На системах c iptables без masquerade и на nftables работает без
ограничений. Экспериментально выяснено, что многие провайдерские NAT не отбрасывают эти пакеты, потому
работает даже с внутренним провайдерским IP. Но linux NAT оно не пройдет, так что за домашним роутером эта
техника не сработает, но может сработать с него.
* autottl. Суть режима в автоматическом определении TTL, чтобы он почти наверняка прошел DPI и немного не дошел до
сервера. Берутся базовые значения TTL 64,128,255, смотрится входящий пакет
(да, требуется направить первый входящий пакет на nfqws !).
Вычисляется длина пути, отнимается delta (1 по умолчанию). Если TTL вне диапазона (min,max - 3,20 по умолчанию),
то берутся значения min,max, чтобы вписаться в диапазон. Если при этом полученный TTL больше длины пути,
то автоматизм не сработал и берутся фиксированные значения TTL для атаки.
Техника позволяет решить вопрос, когда вся сеть перегорожена шлагбаумами (DPI, ТСПУ) везде где только можно,
включая магистралов. Но потенциально может давать сбои.
Например, при асимметрии входящего и исходящего канала до конкретного сервера.
На каких-то провайдерах эта техника будет работать неплохо, на других доставит больше проблем, чем пользы.
Где-то может потребоваться тюнинг параметров. Лучше использовать с дополнительным ограничителем.
Режимы дурения могут сочетаться в любых комбинациях. --dpi-desync-fooling берет множество значений через запятую.
Для режимов fake, rst, rstack после фейка отправляем оригинальный пакет.
Режим disorder делит оригинальный пакет на 2 части и отправляет следующую комбинацию в указанном порядке :
1. 2-я часть пакета
2. поддельная 1-я часть пакета, поле данных заполнено нулями
3. 1-я часть пакета
4. поддельная 1-я часть пакета, поле данных заполнено нулями. отсылка 2-й раз.
Оригинальный пакет дропается всегда. Параметр --dpi-desync-split-pos позволяет указать байтовую позицию, на которой
происходит разбивка. По умолчанию - 2. Если позиция больше длины пакета, позиция выбирается 1.
Этой последовательностью для DPI максимально усложняется задача реконструкции начального сообщения,
по которому принимается решение о блокировке. Некоторым DPI хватит и tcp сегментов в неправильном порядке,
поддельные части сделаны для дополнительной надежности и более сложных алгоритмов реконструкции.
Режим disorder2 отключает отправку поддельных частей.
Режим split очень похож на disorder, только нет изменения порядка следования сегментов :
1. поддельная 1-я часть пакета, поле данных заполнено нулями
2. 1-я часть пакета
3. поддельная 1-я часть пакета, поле данных заполнено нулями. отсылка 2-й раз.
4. 2-я часть пакета
Режим split2 отключает отправку поддельных частей.
Он может быть использован как более быстрая альтернатива --wsize.
disorder2 и split2 не предполагают отсылку фейк пакетов, поэтому опции ttl и fooling неактуальны.
seqovl добавляет в начало первой отсылаемой части оригинального пакета (1 часть для split и 2 часть для disorder)
seqovl байт со смещенным в минус sequence number на величину seqovl.
В случае split2 расчет идет на то, что предыдущий отсыл, если он был, уже попал в сокет серверного приложения,
поэтому новая пришедшая часть лишь частично находится в пределах текущего окна (in-window).
Спереди фейковая часть отбрасывается, а оставшаяся часть содержит оригинал и начинается с начала window,
поэтому попадает в сокет.
Серверное приложение получает все, что реально отсылает клиент, отбрасывая фейковую out-of-window часть.
Но DPI не может этого понять, поэтому у него происходит sequence десинхронизация.
Для disorder2 overlap идет на 2-ю часть пакета. Обязательно, чтобы seqovl был меньше split_pos, иначе
все отосланное будет передано в сокет сразу же, включая фейк, ломая протокол прикладного уровня.
При соблюдении этого условия 2-я часть пакета является полностью in-window,
поэтому серверная ОС принимает ее целиком, включая фейк. Но поскольку начальная часть данных из 1 пакета
еще не принята, то фейк и реальные данные остаются в памяти ядра, не отправляясь в серверное приложение.
Как только приходит 1-я часть пакета, она переписывает фейковую часть в памяти ядра.
Ядро получает данные из 1 и 2 части, поэтому далее идет отправка в сокет приложения.
Таково поведение всех unix ОС, кроме solaris - оставлять последние принятые данные.
Windows оставляет старые данные, поэтому disorder с seqovl будет приводить к зависаниям соединения
при работе с Windows серверами. Solaris практически мертв, windows серверов очень немного.
Можно использовать листы при необходимости.
Метод позволяет обойтись без fooling и TTL. Фейки перемешаны с реальным данными.
split/disorder вместо split2/disorder2 по-прежнему добавляют дополнительные отдельные фейки.
Режимы десинхронизации hopbyhop, destopt и ipfrag1 (не путать с fooling !) относятся только к ipv6 и заключается
в добавлении хедера "hop-by-hop options", "destination options" или "fragment" во все пакеты, попадающие под десинхронизацию.
Здесь надо обязательно понимать, что добавление хедера увеличивает размер пакета, потому не может быть применено
к пакетам максимального размера. Это имеет место при передаче больших сообщений.
В случае невозможности отослать пакет дурение будет отменено, пакет будет выслан в оригинале.
Расчет идет на то, что DPI увидит 0 в поле next header основного заголовка ipv6 и не будет скакать по
extension хедерам в поисках транспортного хедера. Таким образом не поймет, что это tcp или udp, и пропустит пакет
без анализа. Возможно, какие-то DPI на это купятся.
Может сочетаться с любыми режимами 2-й фазы, кроме варианта "ipfrag1+ipfrag2".
Например, "hopbyhop,split2" означает разбить tcp пакет на 2 сегмента, в каждый из них добавить hop-by-hop.
При "hopbyhop,ipfrag2" последовательность хедеров будет : ipv6,hop-by-hop,fragment,tcp/udp.
Режим "ipfrag1" может срабатывать не всегда без специальной подготовки. См. раздел "IP фрагментация".
Есть DPI, которые анализируют ответы от сервера, в частности сертификат из ServerHello, где прописаны домены.
Подтверждением доставки ClientHello является ACK пакет от сервера с номером ACK sequence, соответствующим длине ClientHello+1.
В варианте disorder обычно приходит сперва частичное подтверждение (SACK), потом полный ACK.
Если вместо ACK или SACK идет RST пакет с минимальной задержкой, то DPI вас отсекает еще на этапе вашего запроса.
Если RST идет после полного ACK спустя задержку, равную примерно пингу до сервера,
тогда вероятно DPI реагирует на ответ сервера.
DPI может отстать от потока, если ClientHello его удовлетворил и не проверять ServerHello.
Тогда вам повезло. Вариант fake может сработать.
Если же он не отстает и упорно проверяет ServerHello, то можно попробовать заставить сервер высылать ServerHello частями
через параметр --wssize (см. conntrack).
Если и это не помогает, то сделать с этим что-либо вряд ли возможно без помощи со стороны сервера.
Лучшее решение - включить на сервере поддержку TLS 1.3. В нем сертификат сервера передается в зашифрованном виде.
Это рекомендация ко всем админам блокируемых сайтов. Включайте TLS 1.3. Так вы дадите больше возможностей преодолеть DPI.
Хосты извлекаются из Host: хедера обычных http запросов и из SNI в TLS ClientHello.
Субдомены учитываются автоматически. Поддерживаются листы gzip.
iptables для задействования атаки на первый пакет данных :
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp -m multiport --dports 80,443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:6 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
Этот вариант применяем, когда DPI не следит за всеми запросами http внутри keep-alive сессии.
Если следит, направляем только первый пакет от https и все пакеты от http :
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:6 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 200 --queue-bypass
mark нужен, чтобы сгенерированный поддельный пакет не попал опять к нам на обработку. nfqws выставляет fwmark при его отсылке.
хотя nfqws способен самостоятельно различать помеченные пакеты, фильтр в iptables по mark нужен при использовании connbytes,
чтобы не допустить изменения порядка следования пакетов. Процессинг очереди - процесс отложенный.
Если ядро имеет пакеты на отсылку вне очереди - оно их отправляет незамедлительно.
Изменение правильного порядка следования пакетов при десинхронизации ломает всю идею.
Так же были замечены дедлоки при достаточно большой отсылке пакетов из nfqws и отсутствии mark фильтра.
Процесс может зависнуть. Поэтому наличие фильтра по mark в ip/nf tables можно считать обязательным.
Почему --connbytes 1:6 :
1 - для работы методов десинхронизации 0-й фазы и wssize
2 - иногда данные идут в 3-м пакете 3-way handshake
3 - стандартная ситуация приема одного пакета запроса
4-6 - на случай ретрансмиссии или запроса длиной в несколько пакетов (TLSClientHello с kyber, например)
КОМБИНИРОВАНИЕ МЕТОДОВ ДЕСИНХРОНИЗАЦИИ
В параметре dpi-desync можно указать до 3 режимов через запятую.
0 фаза предполагает работу на этапе установления соединения. Может быть synack или syndata.
На 0 фазу не действует фильтр по hostlist.
Последующие режимы отрабатывают на пакетах с данными.
Режим 1-й фазы может быть fake,rst,rstack. Режим 2-й фазы может быть disorder,disorder2,split,split2,ipfrag2.
Может быть полезно, когда у провайдера стоит не один DPI.
РЕЖИМ SYNACK
В документации по geneva это называется "TCB turnaround". Попытка ввести DPI в заблуждение относительно
ролей клиента и сервера.
!!! Поскольку режим нарушает работу NAT, техника может сработать только если между атакующим устройством
и DPI нет NAT. Атака не сработает через NAT роутер, но может сработать с него.
Для реализации атаки в linux обязательно требуется отключить стандартное правило firewall,
дропающее инвалидные пакеты в цепочке OUTPUT. Например : -A OUTPUT -m state --state INVALID -j DROP
В openwrt можно отключить drop INVALID в OUTPUT и FORWARD через опцию в /etc/config/firewall :
config zone
option name 'wan'
.........
option masq_allow_invalid '1'
К сожалению, отключить только в OUTPUT таким образом нельзя. Но можно сделать иначе. Вписать в /etc/firewall.user :
iptables -D zone_wan_output -m comment --comment '!fw3' -j zone_wan_dest_ACCEPT
ip6tables -D zone_wan_output -m comment --comment '!fw3' -j zone_wan_dest_ACCEPT
Лучше делать так, потому что отсутствие дропа INVALID в FORWARD может привести к нежелательным утечкам пакетов из LAN.
Если не принять эти меры, отсылка SYN,ACK сегмента вызовет ошибку и операция будет прервана.
Остальные режимы тоже не сработают. Если поймете, что вам synack не нужен, обязательно верните правило дропа INVALID.
РЕЖИМ SYNDATA
Тут все просто. Добавляются данные в пакет SYN. Все ОС их игнорируют, если не используется TCP fast open (TFO),
а DPI может воспринять, не разобравшись есть там TFO или нет.
Оригинальные соединения с TFO не трогаются, поскольку это их точно сломает.
Без уточняющего параметра добавляются 16 нулевых байтов.
ВИРТУАЛЬНЫЕ МАШИНЫ
Изнутри VM от virtualbox и vmware в режиме NAT не работают многие техники пакетной магии nfqws.
Принудительно заменяется ttl, не проходят фейк пакеты. Необходимо настроить сеть в режиме bridge.
CONNTRACK
nfqws оснащен ограниченной реализацией слежения за состоянием tcp соединений (conntrack).
Он включается для реализации некоторых методов противодействия DPI.
conntrack способен следить за фазой соединения : SYN,ESTABLISHED,FIN, количеством пакетов в каждую сторону,
sequence numbers. conntrack способен "кормиться" пакетами в обе или только в одну сторону.
Соединение попадает в таблицу при обнаружении пакетов с выставленными флагами SYN или SYN,ACK.
Поэтому если необходим conntrack, в правилах перенаправления iptables соединение должно идти на nfqws с самого первого
пакета, хотя затем может обрываться по фильтру connbytes.
Для UDP инициатором попадания в таблицу является первый UDP пакет. Он же и определяет направление потока.
Считается, что первый UDP пакет исходит от клиента к серверу. Далее все пакеты с совпадающими
src_ip,src_port,dst_ip,dst_port считаются принадлежащими этому потоку до истечения времени неактивности.
conntrack - простенький, он не писался с учетом всевозможных атак на соединение, он не проверяет
пакеты на валидность sequence numbers или чексумму. Его задача - лишь обслуживание нужд nfqws, он обычно
кормится только исходящим трафиком, потому нечувствителен к подменам со стороны внешней сети.
Соединение удаляется из таблицы, как только отпадает нужда в слежении за ним или по таймауту неактивности.
Существуют отдельные таймауты на каждую фазу соединения. Они могут быть изменены параметром --ctrack-timeouts.
--wssize позволяет изменить с клиента размер tcp window для сервера, чтобы он послал следующие ответы разбитыми на части.
Чтобы это подействовало на все серверные ОС, необходимо менять window size в каждом исходящем с клиента пакете до отсылки сообщения,
ответ на который должен быть разбит (например, TLS ClientHello). Именно поэтому и необходим conntrack, чтобы
знать когда надо остановиться. Если не остановиться и все время устанавливать низкий wssize, скорость упадет катастрофически.
В linux это может быть купировано через connbytes, но в BSD системах такой возможности нет.
В случае http(s) останавливаемся сразу после отсылки первого http запроса или TLS ClientHello.
Если вы имеете дело с не http(s), то вам потребуется параметр --wssize-cutoff. Он устанавливает предел, с которого действие
wssize прекращается. Префикс d перед номером означает учитывать только пакеты с data payload, префикс s - relative sequence number,
проще говоря количество переданных клиентом байтов + 1.
Если проскочит пакет с http request или TLS ClientHello, действие wssize прекращается сразу же, не дожидаясь wssize-cutoff.
Если ваш протокол склонен к долгому бездействию, следует увеличить таймаут фазы ESTABLISHED через параметр --ctrack-timeouts.
Таймаут по умолчанию низкий - всего 5 минут.
Не забывайте, что nfqws кормится приходящими на него пакетами. Если вы ограничили поступление пакетов через connbytes,
то в таблице могут остаться повисшие соединения в фазе ESTABLISHED, которые отвалятся только по таймауту.
Для диагностики состояния conntrack пошлите сигнал SIGUSR1 процессу nfqws : killall -SIGUSR1 nfqws.
Текущая таблица будет выведена nfqws в stdout.
Обычно в SYN пакете клиент отсылает кроме window size еще и TCP extension "scaling factor".
scaling factor представляет из себя степень двойки, на которую умножается window size : 0=>1, 1=>2, 2=>4, ..., 8=>256, ...
В параметре wssize scaling factor указывается через двоеточие.
Scaling factor может только снижаться, увеличение заблокировано, чтобы не допустить превышение размера окна со стороны сервера.
Для принуждения сервера к фрагментации ServerHello, чтобы избежать просекание имени сервера из сертификата сервера на DPI,
лучше всего использовать --wssize=1:6 . Основное правило - делать scale_factor как можно больше, чтобы после восстановления
window size итоговый размер окна стал максимально возможным. Если вы сделаете 64:0, будет очень медленно.
С другой стороны нельзя допустить, чтобы ответ сервера стал достаточно большим, чтобы DPI нашел там искомое.
--wssize не работает в профилях с хостлистами, поскольку он действует с самого начала соединения, когда еще нельзя
принять решение о попадании в лист. Однако, профиль с auto hostlist может содержать --wssize.
--wssize может замедлять скорость и/или увеличивать время ответа сайтов, поэтому если есть другие работающие способы
обхода DPI, лучше применять их.
--dpi-desync-cutoff позволяет задать предел, при достижении которого прекращается применение dpi-desync.
Доступны префиксы n,d,s по аналогии с --wssize-cutoff.
Полезно совместно с --dpi-desync-any-protocol=1.
На склонных к бездействию соединениях следует изменить таймауты conntrack.
Если соединение выпало из conntrack и задана опция --dpi-desync-cutoff, dpi desync применяться не будет.
РЕАССЕМБЛИНГ
nfqws поддерживает реассемблинг некоторых видов запросов.
На текущий момент это TLS и QUIC ClientHello. Они бывает длинными, если в chrome включить пост-квантовую
криптографию tls-kyber, и занимают как правило 2 или 3 пакета. kyber включен по умолчанию, начиная с chromium 124.
chrome рандомизирует фингерпринт TLS. SNI может оказаться как в начале, так и в конце, то есть
попасть любой пакет. stateful DPI обычно реассемблирует запрос целиком, и только потом
принимает решение о блокировке.
В случае получения TLS или QUIC пакета с частичным ClientHello начинается процесс сборки, а пакеты
задерживаются и не отсылаются до ее окончания. По окончании сборки пакеты проходит через десинхронизацию
на основании полностью собранного ClientHello.
При любой ошибке в процессе сборки задержанные пакеты немедленно отсылаются в сеть, а десинхронизация отменяется.
Есть специальная поддержка всех вариантов tcp сплита для многосегментного TLS.
Если указать позицию сплита больше длины первого пакета или использовать --dpi-desync-split-tls,
то разбивка происходит не обязательно первого пакета, а того, на который пришлась итоговая позиция.
Если, допустим, клиент послал TLS ClientHello длиной 2000, а SNI начинается с 1700,
и заданы опции fake,split2, то перед первым пакетом идет fake, затем первый пакет в оригинале,
а последний пакет разбивается на 2 сегмента. В итоге имеем фейк в начале и 3 реальных сегмента.
ПОДДЕРЖКА UDP
Атаки на udp более ограничены в возможностях. udp нельзя фрагментировать иначе, чем на уровне ip.
Для UDP действуют только режимы десинхронизации fake,hopbyhop,destopt,ipfrag1,ipfrag2,udplen,tamper.
Возможно сочетание fake,hopbyhop,destopt с ipfrag2, fake,fakeknown с udplen и tamper.
udplen увеличивает размер udp пакета на указанное в --dpi-desync-udplen-increment количество байтов.
Паддинг заполняется нулями по умолчанию, но можно задать свой паттерн.
Предназначено для обмана DPI, ориентирующегося на размеры пакетов.
Может сработать, если пользовательский протокол не привязан жестко к размеру udp пейлоада.
Режим tamper означает модификацию пакетов известных протоколов особенным для протокола образом.
На текущий момент работает только с DHT.
Поддерживается определение пакетов QUIC Initial с расшифровкой содержимого и имени хоста, то есть параметр
--hostlist будет работать.
Определяются пакеты wireguard handshake initiation и DHT (начинается с 'd1', кончается 'e').
Для десинхронизации других протоколов обязательно указывать --dpi-desync-any-protocol.
Реализован conntrack для udp. Можно пользоваться --dpi-desync-cutoff. Таймаут conntrack для udp
можно изменить 4-м параметром в --ctrack-timeouts.
Атака fake полезна только для stateful DPI, она бесполезна для анализа на уровне отдельных пакетов.
По умолчанию fake наполнение - 64 нуля. Можно указать файл в --dpi-desync-fake-unknown-udp.
IP ФРАГМЕНТАЦИЯ
Современная сеть практически не пропускает фрагментированные tcp на уровне ip.
На udp с этим дело получше, поскольку некоторые udp протоколы могут опираться на этот механизм (IKE старых версий).
Однако, кое-где бывает, что режут и фрагментированный udp.
Роутеры на базе linux могут самопроизвольно собирать или перефрагментировать пакеты.
Позиция фрагментации задается отдельно для tcp и udp. По умолчанию 24 и 8 соответственно, должна быть кратна 8.
Смещение считается с транспортного заголовка.
Существует ряд моментов вокруг работы с фрагментами на Linux, без понимания которых может ничего не получиться.
ipv4 : Linux дает отсылать ipv4 фрагменты, но стандартные настройки iptables в цепочке OUTPUT могут вызывать ошибки отправки.
ipv6 : Нет способа для приложения гарантированно отослать фрагменты без дефрагментации в conntrack.
На разных системах получается по-разному. Где-то нормально уходят, где-то пакеты дефрагментируются.
Для ядер <4.16 похоже, что нет иного способа решить эту проблему, кроме как выгрузить модуль nf_conntrack,
который подтягивает зависимость nf_defrag_ipv6. Он то как раз и выполняет дефрагментацию.
Для ядер 4.16+ ситуация чуть лучше. Из дефрагментации исключаются пакеты в состоянии NOTRACK.
Чтобы не загромождать описание, смотрите пример решения этой проблемы в blockcheck.sh.
Иногда требуется подгружать модуль ip6table_raw с параметром raw_before_defrag=1.
В openwrt параметры модулей указываются через пробел после их названий в файлах /etc/modules.d.
В традиционных системах посмотрите используется ли iptables-legacy или iptables-nft. Если legacy, то нужно создать файл
/etc/modprobe.d/ip6table_raw.conf с содержимым :
options ip6table_raw raw_before_defrag=1
В некоторых традиционных дистрибутивах можно изменить текущий ip6tables через : update-alternatives --config ip6tables
Если вы хотите оставаться на iptables-nft, вам придется пересобрать патченную версию. Патч совсем небольшой.
В nft.c найдите фрагмент :
{
.name = "PREROUTING",
.type = "filter",
.prio = -300, /* NF_IP_PRI_RAW */
.hook = NF_INET_PRE_ROUTING,
},
{
.name = "OUTPUT",
.type = "filter",
.prio = -300, /* NF_IP_PRI_RAW */
.hook = NF_INET_LOCAL_OUT,
},
и замените везде -300 на -450.
Это нужно сделать вручную, никакой автоматики в blockcheck.sh нет.
Либо можно раз и навсегда избавиться от этой проблемы, используя nftables. Там можно создать netfilter hook
с любым приоритетом. Используйте приоритет -401 и ниже.
При использовании iptables и NAT, похоже, что нет способа прицепить обработчик очереди после NAT.
Пакет попадает в nfqws с source адресом внутренней сети, затем фрагментируется и уже не обрабатывается NAT.
Так и уходит во внешюю сеть с src ip 192.168.x.x. Следовательно, метод не срабатывает.
Видимо единственный рабочий метод - отказаться от iptables и использовать nftables.
Хук должен быть с приоритетом 101 или выше.
МНОЖЕСТВЕННЫЕ СТРАТЕГИИ
nfqws способен по-разному реагировать на различные запросы и применять разные стратегии дурения.
Это реализовано посредством поддержки множества профилей дурения.
Профили разделяются в командной строке параметром --new. Первый профиль создается автоматически.
Для него не нужно --new. Каждый профиль имеет фильтр. По умолчанию он пуст, то есть профиль удовлетворяет
любым условиям.
Фильтр может содержать жесткие параметры : версия ip протокола, ipset и порты tcp/udp.
Они всегда однозначно идентифицируются даже на нулевой фазе десинхронизации, когда еще хост и L7 неизвестны.
В качестве мягкого фильтра могут выступать хост-листы и протокол прикладного уровня (l7).
L7 протокол становится известен обычно после первого пакета с данными.
При поступлении запроса идет проверка профилей в порядке от первого до последнего до
достижения первого совпадения с фильтром.
Жесткие параметры фильтра сверяются первыми. При несовпадении идет сразу же переход к следующему профилю.
Если какой-то профиль удовлетворяет жесткому фильтру и L7 фильтру и содержит авто-хостлист, он выбирается сразу.
Если профиль удовлетворяет жесткому фильтру и L7 фильтру, для него задан хостлист, и у нас еще нет имени хоста,
идет переход к следующему профилю. В противном случае идет проверка по хостлистам этого профиля.
Если имя хоста удовлетворяет листам, выбирается этот профиль. Иначе идет переход к следующему.
Может так случиться, что до получения имени хоста или узнавания L7 протокола соединение идет по одному профилю,
а при выяснении этих параметров профиль меняется на лету. Это может произойти даже дважды - при выяснении L7
и имени хоста. Чаще всего это выяснение совмещается в одно действие, поскольку по одному пакету как правило узнается и L7, и хост.
Поэтому если у вас есть параметры дурения нулевой фазы, тщательно продумывайте что может произойти при переключении стратегии.
Смотрите debug log, чтобы лучше понять что делает nfqws.
Нумерация профилей идет с 1 до N. Последним в цепочке создается пустой профиль с номером 0.
Он используется, когда никакие условия фильтров не совпали.
ВАЖНО : множественные стратегии создавались только для случаев, когда невозможно обьединить
имеющиеся стратегии для разных ресурсов. Копирование стратегий из blockcheck для разных сайтов
во множество профилей без понимания как они работают приведет к нагромождению параметров, которые все равно
не покроют все возможные заблокированные ресурсы. Вы только увязните в этой каше.
ВАЖНО : user-mode реализация ipset создавалась не как удобная замена *nix версии, реализованной в ядре.
Вариант в ядре работает гораздо эффективнее. Это создавалось для систем без подержки ipset в ядре.
Конкретно - Windows и ядра Linux, собранные без nftables и ipset модулей ядра. Например, в android нет ipset.
tpws
-----
tpws - это transparent proxy.
--debug=0|1|2|syslog|@<filename> ; 0,1,2 = логирование на косоль : 0=тихо, 1(default)=подробно, 2=отладка.
--debug-level=0|1|2 ; указать уровень логирования для syslog и @<filename>
--daemon ; демонизировать прогу
--pidfile=<file> ; сохранить PID в файл
--user=<username> ; менять uid процесса
--uid=uid[:gid] ; менять uid процесса
--bind-addr ; на каком адресе слушать. может быть ipv4 или ipv6 адрес
; если указан ipv6 link local, то требуется указать с какого он интерфейса : fe80::1%br-lan
--bind-linklocal=no|unwanted|prefer|force
; no : биндаться только на global ipv6
; unwanted (default) : предпочтительно global, если нет - LL
; prefer : предпочтительно LL, если нет - global
; force : биндаться только на LL
--bind-iface4=<iface> ; слушать на первом ipv4 интерфейса iface
--bind-iface6=<iface> ; слушать на первом ipv6 интерфейса iface
--bind-wait-ifup=<sec> ; ждать до N секунд появления и поднятия интерфейса
--bind-wait-ip=<sec> ; ждать до N секунд получения IP адреса (если задан --bind-wait-ifup - время идет после поднятия интерфейса)
--bind-wait-ip-linklocal=<sec>
; имеет смысл только при задании --bind-wait-ip
; --bind-linklocal=unwanted : согласиться на LL после N секунд
; --bind-linklocal=prefer : согласиться на global address после N секунд
--bind-wait-only ; подождать все бинды и выйти. результат 0 в случае успеха, иначе не 0.
--connect-bind-addr ; с какого адреса подключаться во внешнюю сеть. может быть ipv4 или ipv6 адрес
; если указан ipv6 link local, то требуется указать с какого он интерфейса : fe80::1%br-lan
; опция может повторяться для v4 и v6 адресов
; опция не отменяет правил маршрутизации ! выбор интерфейса определяется лишь правилами маршрутизации, кроме случая v6 link local.
--socks ; вместо прозрачного прокси реализовать socks4/5 proxy
--no-resolve ; запретить ресолвинг имен через socks5
--resolve-threads ; количество потоков ресолвера
--port=<port> ; на каком порту слушать
--maxconn=<max_connections> ; максимальное количество соединений от клиентов к прокси
--maxfiles=<max_open_files> ; макс количество файловых дескрипторов (setrlimit). мин требование (X*connections+16), где X=6 в tcp proxy mode, X=4 в режиме тамперинга.
; стоит сделать запас с коэффициентом как минимум 1.5. по умолчанию maxfiles (X*connections)*1.5+16
--max-orphan-time=<sec>; если вы запускаете через tpws торрент-клиент с множеством раздач, он пытается установить очень много исходящих соединений,
; большая часть из которых отваливается по таймауту (юзера сидят за NAT, firewall, ...)
; установление соединения в linux может длиться очень долго. локальный конец отвалился, перед этим послав блок данных,
; tpws ждет подключения удаленного конца, чтобы отослать ему этот блок, и зависает надолго.
; настройка позволяет сбрасывать такие подключения через N секунд, теряя блок данных. по умолчанию 5 сек. 0 означает отключить функцию
; эта функция не действует на успешно подключенные ранее соединения
--local-rcvbuf=<bytes> ; SO_RCVBUF для соединений client-proxy
--local-sndbuf=<bytes> ; SO_SNDBUF для соединений client-proxy
--remote-rcvbuf=<bytes> ; SO_RCVBUF для соединений proxy-target
--remote-sndbuf=<bytes> ; SO_SNDBUF для соединений proxy-target
--nosplice ; не использовать splice на linux системах
--skip-nodelay ; не устанавливать в исходящих соединения TCP_NODELAY. несовместимо со split.
--local-tcp-user-timeout=<seconds> ; таймаут соединений client-proxy (по умолчанию : 10 сек, 0 = оставить системное значение)
--remote-tcp-user-timeout=<seconds> ; таймаут соединений proxy-target (по умолчанию : 20 сек, 0 = оставить системное значение)
--split-http-req=method|host ; способ разделения http запросов на сегменты : около метода (GET,POST) или около заголовка Host
--split-pos=<offset> ; делить все посылы на сегменты в указанной позиции. единственная опция, работающая на не-http. при указании split-http-req он имеет преимущество на http.
--split-any-protocol ; применять split-pos к любым пакетам. по умолчанию - только к http и TLS ClientHello
--disorder[=http|tls] ; путем манипуляций с сокетом вынуждает отправлять первым второй сегмент разделенного запроса
--oob[=http|tls] ; отправить байт out-of-band data (OOB) в конце первой части сплита
--oob-data=<char>|0xHEX ; переопределить байт OOB. по умолчанию 0x00.
--hostcase ; менять регистр заголовка "Host:". по умолчанию на "host:".
--hostspell=HoST ; точное написание заголовка Host (можно "HOST" или "HoSt"). автоматом включает --hostcase
--hostdot ; добавление точки после имени хоста : "Host: kinozal.tv."
--hosttab ; добавление табуляции после имени хоста : "Host: kinozal.tv\t"
--hostnospace ; убрать пробел после "Host:"
--hostpad=<bytes> ; добавить паддинг-хедеров общей длиной <bytes> перед Host:
--domcase ; домен после Host: сделать таким : TeSt.cOm
--methodspace ; добавить пробел после метода : "GET /" => "GET /"
--methodeol ; добавить перевод строки перед методом : "GET /" => "\r\nGET /"
--unixeol ; конвертировать 0D0A в 0A и использовать везде 0A
--tlsrec=sni|sniext ; разбивка TLS ClientHello на 2 TLS records. режем между 1 и 2 символами hostname в SNI или между байтами длины SNI extension. Если SNI нет - отмена.
--tlsrec-pos=<pos> ; разбивка TLS ClientHello на 2 TLS records. режем на указанной позиции, если длина слишком мелкая - на позиции 1.
--mss=<int> ; установить MSS для клиента. может заставить сервер разбивать ответы, но существенно снижает скорость
--mss-pf=[~]port1[-port2] ; применять MSS только к портам назначения, подпадающим под фильтр. ~ означает инверсию
--tamper-start=[n]<pos> ; начинать дурение только с указанной байтовой позиции или номера блока исходяшего потока (считается позиция начала принятого блока)
--tamper-cutoff=[n]<pos> ; закончить дурение на указанной байтовой позиции или номере блока исходящего потока (считается позиция начала принятого блока)
--hostlist=<filename> ; действовать только над доменами, входящими в список из filename. поддомены автоматически учитываются.
; в файле должен быть хост на каждой строке.
; список читается 1 раз при старте и хранится в памяти в виде иерархической структуры для быстрого поиска.
; по сигналу HUP список будет перечитан при следующем принятом соединении
; список может быть запакован в gzip. формат автоматически распознается и разжимается
; списков может быть множество, они объединяются. пустой общий лист = его отсутствие
; хосты извлекаются из Host: хедера обычных http запросов и из SNI в TLS ClientHello.
--hostlist-exclude=<filename> ; не применять дурение к доменам из листа. может быть множество листов, они объединяются
--hostlist-auto=<filename> ; обнаруживать автоматически блокировки и заполнять автоматический hostlist (требует перенаправления входящего трафика)
--hostlist-auto-fail-threshold=<int> ; сколько раз нужно обнаружить ситуацию, похожую на блокировку, чтобы добавить хост в лист (по умолчанию: 3)
--hostlist-auto-fail-time=<int> ; все эти ситуации должны быть в пределах указанного количества секунд (по умолчанию: 60)
--hostlist-auto-debug=<logfile> ; лог положительных решений по autohostlist. позволяет разобраться почему там появляются хосты.
--new ; начало новой стратегии
--filter-l3=ipv4|ipv6 ; фильтр версии ip для текущей стратегии
--filter-tcp=[~]port1[-port2] ; фильтр портов tcp для текущей стратегии. ~ означает инверсию.
--filter-l7=[http|tls|quic|wireguard|dht|unknown] ; фильтр протокола L6-L7. поддерживается несколько значений через запятую.
--ipset=<filename> ; включающий ip list. на каждой строчке ip или cidr ipv4 или ipv6. поддерживается множество листов и gzip.
--ipset-exclude=<filename> ; исключающий ip list. на каждой строчке ip или cidr ipv4 или ipv6. поддерживается множество листов и gzip.
--debug позволяет выводить подробный лог действий на консоль, в syslog или в файл.
Может быть важен порядок следования опций. --debug лучше всего указывать в самом начале.
Опции анализируются последовательно. Если ошибка будет при проверке опции, а до анализа --debug еще дело не дошло,
то сообщения не будут выведены в файл или syslog.
--debug=0|1|2 позволяют сразу в одном параметре включить логирование на консоль и указать уровень.
Сохранено для совместимости с более старыми версиями. Для выбора уровня в режиме syslog или file используйте
отдельный параметр --debug-level. Если в этих режимах --debug не указывать уровень через --debug-level, то
автоматически назначается уровень 1.
При логировании в файл процесс не держит файл открытым. Ради каждой записи файл открывается и потом закрывается.
Так что файл можно удалить в любой момент, и он будет создан заново при первом же сообщении в лог.
Но имейте в виду, что если вы запускаете процесс под root, то будет сменен UID на не-root.
В начале на лог файл меняется owner, иначе запись будет невозможна. Если вы потом удалите файл,
и у процесса не будет прав на создание файла в его директории, лог больше не будет вестись.
Вместо удаления лучше использовать truncate.
В шелле это можно сделать через команду ": >filename"
Параметры манипуляции могут сочетаться в любых комбинациях.
В случае http запроса split-http-req имеет преимущество над split-pos.
split-pos по умолчанию работает только на http и TLS ClientHello.
Чтобы он работал на любых пакетах, укажите --split-any-protocol.
На прикладном уровне в общем случае нет гарантированного средства заставить ядро выплюнуть
блок данных, порезанным в определенном месте. ОС держит буфер отсылки (SNDBUF) у каждого сокета.
Если у сокета включена опция TCP_NODELAY и буфер пуст, то каждый send приводит к отсылке
отдельного ip пакета или группы пакетов, если блок не вмещается в один ip пакет.
Однако, если в момент send уже имеется неотосланный буфер, то ОС присоединит данные к нему,
никакой отсылки отдельным пакетом не будет. Но в этом случае и так нет никакой гарантии,
что какой-то блок сообщения пойдет в начале пакета, на что собственно и заточены DPI.
Разбиение будет производится согласно MSS, который зависит от MTU исходящего интерфейса.
Таким образом DPI, смотрящие в начало поля данных TCP пакета, будут поломаны в любом случае.
Протокол http относится к запрос-ответным протоколам. Новое сообщение посылается только тогда,
когда сервер получил запрос и полностью вернул ответ. Значит запрос фактически был не только отослан,
но и принят другой стороной, а следовательно буфер отсылки пуст, и следующие 2 send приведут
к отсылке сегментов данных разными ip пакетами.
Резюме : tpws гарантирует сплит только за счет раздельных вызовов send, что на практике
вполне достаточно для протоколов http(s).
tpws может биндаться на множество интерфейсов и IP адресов (до 32 шт).
Порт всегда только один.
Параметры --bind-iface* и --bind-addr создают новый бинд.
Остальные параметры --bind-* относятся к последнему бинду.
Для бинда на все ipv4 укажите --bind-addr "0.0.0.0", на все ipv6 - "::". --bind-addr="" - биндаемся на все ipv4 и ipv6.
Выбор режима использования link local ipv6 адресов (fe80::/8) :
--bind-iface6 --bind-linklocal=no : сначала приватный адрес fc00::/7, затем глобальный адрес
--bind-iface6 --bind-linklocal=unwanted : сначала приватный адрес fc00::/7, затем глобальный адрес, затем link local.
--bind-iface6 --bind-linklocal=prefer : сначала link local, затем приватный адрес fc00::/7, затем глобальный адрес.
--bind-iface6 --bind-linklocal=force : только link local
Если не указано ни одного бинда, то создается бинд по умолчанию на все адреса всех интерфейсов.
Для бинда на конкретный link-local address делаем так : --bind-iface6=fe80::aaaa:bbbb:cccc:dddd%iface-name
Параметры --bind-wait* могут помочь в ситуациях, когда нужно взять IP с интерфейса, но его еще нет, он не поднят
или не сконфигурирован.
В разных системах события ifup ловятся по-разному и не гарантируют, что интерфейс уже получил IP адрес определенного типа.
В общем случае не существует единого механизма повеситься на событие типа "на интерфейсе X появился link local address".
Для бинда на известный ip, когда еще интерфейс не сконфигурирован, нужно делать так : --bind-addr=192.168.5.3 --bind-wait-ip=20
В режиме transparent бинд возможен на любой несуществующий адрес, в режиме socks - только на существующий.
Параметры rcvbuf и sndbuf позволяют установить setsockopt SO_RCVBUF SO_SNDBUF для локального и удаленного соединения.
Если не указан ни один из параметров модификации содержимого, tpws работает в режиме "tcp proxy mode".
Он отличается тем, что в оба конца применяется splice для переброски данных из одного сокета в другой
без копирования в память процесса. Практически - это то же самое, но может быть чуть побыстрее.
TCP проксирование может быть полезно для обхода блокировок, когда DPI спотыкается на экзотических
хедерах IP или TCP. Вы вряд ли сможете поправить хедеры, исходящие от айфончиков и гаджетиков,
но на linux сможете влиять на них в какой-то степени через sysctl.
Когда соединение проходит через tpws, фактически прокси-сервер сам устанавливает подключение к удаленному
узлу от своего имени, и на это распространяются настройки системы, на которой работает прокси.
tpws можно использовать на мобильном устройстве, раздающем интернет на тарифе сотового оператора,
где раздача запрещена, в socks режиме даже без рута. Соединения от tpws неотличимы от соединений
с самого раздающего устройства. Отличить можно только по содержанию (типа обновлений windows).
Заодно можно и обойти блокировки. 2 зайца одним выстрелом.
Более подробную информацию по вопросу обхода ограничений операторов гуглите на 4pda.ru.
Режим "--socks" не требует повышенных привилегий (кроме бинда на привилегированные порты 1..1023).
Поддерживаются версии socks 4 и 5 без авторизации. Версия протокола распознается автоматически.
Подключения к IP того же устройства, на котором работает tpws, включая localhost, запрещены.
socks5 позволяет удаленно ресолвить хосты (curl : --socks5-hostname firefox : socks_remote_dns=true).
tpws поддерживает эту возможность асинхронно, не блокируя процессинг других соединений, используя
многопоточный пул ресолверов. Количество потоков определяется автоматически в зависимости от "--maxconn",
но можно задать и вручную через параметр "--resolver-threads".
Запрос к socks выставляется на паузу, пока домен не будет преобразован в ip адрес в одном из потоков
ресолвера. Ожидание может быть более длинным, если все потоки заняты.
Если задан параметр "--no-resolve", то подключения по именам хостов запрещаются, а пул ресолверов не создается.
Тем самым экономятся ресурсы.
Параметр --hostpad=<bytes> добавляет паддинг-хедеров перед Host: на указанное количество байтов.
Если размер <bytes> слишком большой, то идет разбивка на разные хедеры по 2K.
Общий буфер приема http запроса - 64K, больший паддинг не поддерживается, да и http сервера
такое уже не принимают.
Полезно против DPI, выполняющих реассемблинг TCP с ограниченным буфером.
Если техника работает, то после некоторого количества bytes http запрос начнет проходить до сайта.
Если при этом критический размер padding около MTU, значит скорее всего DPI не выполняет реассемблинг пакетов, и лучше будет использовать обычные опции --split-…
Если все же реассемблинг выполняется, то критический размер будет около размера буфера DPI. Он может быть 4K или 8K, возможны и другие значения.
--disorder - это попытка симулировать режим disorder2 nfqws, используя особенности ОС по реализации stream сокетов.
Однако, в отличие от nfqws, здесь не требуются повышенные привилегии.
Реализовано это следующим образом. У сокета есть возможность выставить TTL. Все пакеты будут отправляться с ним.
Перед отправкой первого сегмента ставим TTL=1. Пакет будет дропнут на первом же роутере, он не дойдет ни до DPI, ни до сервера.
Затем возвращаем TTL в значение по умолчанию. ОС отсылает второй сегмент, и он уже доходит до сервера.
Сервер возвращает SACK, потому что не получил первый кусок, и ОС его отправляет повторно, но здесь уже мы ничего не делаем.
Этот режим работает как ожидается на Linux и MacOS. Однако, на FreeBSD и OpenBSD он работает не так хорошо.
Ядро этих ОС отсылает ретрансмиссию в виде полного пакета. Потому выходит, что до сервера идет сначала второй кусок,
а потом полный запрос без сплита. На него может отреагировать DPI штатным образом.
--disorder является дополнительным флагом к любому сплиту. Сам по себе он не делает ничего.
--tlsrec и --tlsrec-pos позволяют внутри одного tcp сегмента разрезать TLS ClientHello на 2 TLS records.
--tlsrec=sni режет между 1 и 2 символами hostname в SNI, делая невозможным бинарный поиск паттерна без анализа
структуры данных. В случае отсутствия SNI разбиение отменяется.
--tlsrec-pos режет на указанной позиции. Если длина блока данных TLS меньше указанной позиции, режем на позиции 1.
Параметр сочетается с --split-pos. В этом случае происходит сначала разделение на уровне TLS record layer, потом на уровне TCP.
Самая изощрённая атака --tlsrec, --split-pos и --disorder вместе.
--tlsrec ломает значительное количество сайтов. Криптобиблиотеки (openssl, ...) на оконечных http серверах
без проблем принимают разделенные tls сегменты, но мидлбоксы - не всегда. К мидлбоксам можно отнести CDN
или системы ddos-защиты. Поэтому применение --tlsrec без ограничителей вряд ли целесообразно.
В РФ --tlsrec обычно не работает с TLS 1.2, потому что цензор парсит сертификат сервера из ServerHello.
Работает только с TLS 1.3, поскольку там эта информация шифруется.
Впрочем, сейчас сайтов, не поддерживающих TLS 1.3, осталось немного.
--mss устанавливает опцию сокета TCP_MAXSEG. Клиент выдает это значение в tcp опциях SYN пакета.
Сервер в ответ в SYN,ACK выдает свой MSS. На практике сервера обычно снижают размеры отсылаемых ими пакетов, но они
все равно не вписываются в низкий MSS, указанный клиентом. Обычно чем больше указал клиент, тем больше
шлет сервер. На TLS 1.2 если сервер разбил заброс так, чтобы домен из сертификата не попал в первый пакет,
это может обмануть DPI, секущий ответ сервера.
Схема может значительно снизить скорость и сработать не на всех сайтах.
С фильтром по hostlist совместимо только в режиме socks при включенном удаленном ресолвинге хостов.
(firefox network.proxy.socks_remote_dns). Это единственный вариант, когда tpws может узнать имя хоста
еще на этапе установления соединения.
Применяя данную опцию к сайтам TLS1.3, если броузер тоже поддерживает TLS1.3, то вы делаете только хуже.
Но нет способа автоматически узнать когда надо применять, когда нет, поскольку MSS идет только в
3-way handshake еще до обмена данными, а версию TLS можно узнать только по ответу сервера, который
может привести к реакции DPI.
Использовать только когда нет ничего лучше или для отдельных ресурсов.
Для http использовать смысла нет, поэтому заводите отдельный desync profile с фильтром по порту 443.
Работает только на linux, не работает на BSD и MacOS.
--skip-nodelay может быть полезен, чтобы привести MTU к MTU системы, на которой работает tpws.
Это может быть полезно для скрытия факта использования VPN. Пониженный MTU - 1 из способов обнаружения
подозрительного подключения. С tcp proxy ваши соединения неотличимы от тех, что сделал бы сам шлюз.
--local-tcp-user-timeout и --remote-tcp-user-timeout устанавливают значение таймаута в секундах
для соединений клиент-прокси и прокси-сервер. Этот таймаут соответствует опции сокета linux
TCP_USER_TIMEOUT. Под таймаутом подразумевается время, в течение которого буферизированные данные
не переданы или на переданные данные не получено подтверждение (ACK) от другой стороны.
Этот таймаут никак не касается времени отсутствия какой-либо передачи через сокет лишь потому,
что данных для передачи нет. Полезно для сокращения время закрытия подвисших соединений.
Поддерживается только на Linux и MacOS.
МНОЖЕСТВЕННЫЕ СТРАТЕГИИ
Работают аналогично nfqws, кроме некоторых моментов.
Нет параметра --filter-udp, поскольку tpws udp не поддерживает.
Методы нулевой фазы (--mss) могут работать по хостлисту в одном единственном случае :
если используется режим socks и удаленный ресолвинг хостов через прокси.
То есть работоспособность вашей настройки в одном и том же режиме может зависеть от того,
применяет ли клиент удаленный ресолвинг. Это может быть неочевидно.
В одной программе работает, в другой - нет.
Если вы используете профиль с хостлистом , и вам нужен mss, укажите mss в профиле с хостлистом,
создайте еще один профиль без хостлиста, если его еще нет, и в нем еще раз укажите mss.
Тогда при любом раскладе будет выполняться mss.
Используйте `curl --socks5` и `curl --socks5-hostname` для проверки вашей стратегии.
Смотрите вывод --debug, чтобы убедиться в правильности настроек.
Способы получения списка заблокированных IP
-------------------------------------------
!!! nftables не могут работать с ipset-ами. Собственный аналогичный механизм требует огромного количество RAM
!!! для загрузки больших листов. Например, для загона 100K записей в nfset не хватает даже 256 Mb.
!!! Если вам нужны большие листы на домашних роутерах, откатывайтесь на iptables+ipset.
1) Внесите заблокированные домены в ipset/zapret-hosts-user.txt и запустите ipset/get_user.sh
На выходе получите ipset/zapret-ip-user.txt с IP адресами.
Cкрипты с названием get_reestr_* оперируют дампом реестра заблокированных сайтов :
2) ipset/get_reestr_resolve.sh получает список доменов от rublacklist и дальше их ресолвит в ip адреса
в файл ipset/zapret-ip.txt.gz. В этом списке есть готовые IP адреса, но судя во всему они там в точности в том виде,
что вносит в реестр РосКомПозор. Адреса могут меняться, позор не успевает их обновлять, а провайдеры редко
банят по IP : вместо этого они банят http запросы с "нехорошим" заголовком "Host:" вне зависимости
от IP адреса. Поэтому скрипт ресолвит все сам, хотя это и занимает много времени.
Используется мультипоточный ресолвер mdig (собственная разработка).
3) ipset/get_reestr_preresolved.sh. то же самое, что и 2), только берется уже заресолвленый список
со стороннего ресурса.
4) ipset/get_reestr_preresolved_smart.sh. то же самое, что и 3), с добавлением всего диапазона некоторых
автономных систем (прыгающие IP адреса из cloudflare, facebook, ...) и некоторых поддоменов блокируемых сайтов
Cкрипты с названием get_antifilter_* оперируют списками адресов и масок подсетей с сайтов antifilter.network и antifilter.download :
5) ipset/get_antifilter_ip.sh. получает лист https://antifilter.download/list/ip.lst.
6) ipset/get_antifilter_ipsmart.sh. получает лист https://antifilter.network/download/ipsmart.lst.
умная суммаризация отдельных адресов из ip.lst по маскам от /32 до /22
7) ipset/get_antifilter_ipsum.sh. получает лист https://antifilter.download/list/ipsum.lst.
суммаризация отдельных адресов из ip.lst по маске /24
8) ipset/get_antifilter_ipresolve.sh. получает лист https://antifilter.download/list/ipresolve.lst.
пре-ресолвленный список, аналогичный получаемый при помощи get_reestr_resolve. только ipv4.
9) ipset/get_antifilter_allyouneed.sh. получает лист https://antifilter.download/list/allyouneed.lst.
Суммарный список префиксов, созданный из ipsum.lst и subnet.lst.
10) ipset/get_refilter_ipsum.sh.
Список берется отсюда : https://github.com/1andrevich/Re-filter-lists
Все варианты рассмотренных скриптов автоматически создают и заполняют ipset.
Варианты 2-10 дополнительно вызывают вариант 1.