Здравствуйте!Есть вопрос следующего характера. Каким образом в NetBSD можно захватывать пакеты на уровне IP, например, (не копии, а целиком), чтобы они не передавальсь дальше вверх по стеку (аля divert во FreeBSD)?
>Здравствуйте!
>
>Есть вопрос следующего характера. Каким образом в NetBSD можно захватывать пакеты на
>уровне IP, например, (не копии, а целиком), чтобы они не передавальсь
>дальше вверх по стеку (аля divert во FreeBSD)?libpcap?
raw socket?
>>Здравствуйте!
>>
>>Есть вопрос следующего характера. Каким образом в NetBSD можно захватывать пакеты на
>>уровне IP, например, (не копии, а целиком), чтобы они не передавальсь
>>дальше вверх по стеку (аля divert во FreeBSD)?
>
>libpcap?
>raw socket?тогда уж вкорее BPF
man bpfps: хотя я не уверен в том, что даже через BPF можно фильтровать пакеты без их передачи дальше по стеку. собственно именно в этом я так понимаю задача.
// wbr
>>>Здравствуйте!
>>>
>>>Есть вопрос следующего характера. Каким образом в NetBSD можно захватывать пакеты на
>>>уровне IP, например, (не копии, а целиком), чтобы они не передавальсь
>>>дальше вверх по стеку (аля divert во FreeBSD)?
>>
>>libpcap?
>>raw socket?
>
>тогда уж вкорее BPF
>man bpf
>
>ps: хотя я не уверен в том, что даже через BPF можно
>фильтровать пакеты без их передачи дальше по стеку. собственно именно в
>этом я так понимаю задача.
>
>// wbr
Да, Вы правильно поняли задачу. Через BPF можно, но нужно оригинал пакета дропать - неэстетично как-то :-). Есть ли еще варианты?
>Да, Вы правильно поняли задачу. Через BPF можно, но нужно оригинал пакета
>дропать - неэстетично как-то :-). Есть ли еще варианты?man tun
первое, что приходит в голову. если вы поставите свой сервис между реальным и tun интерфейсом, то вы можете по понятным причинам делать с потоком пакетов абсолютно все, что пожелаете. схема типа:
клиент -> ip стек -> tun -> ваш сервис -> допустим, rtk0 -> ip стек
ps: подобным образом tun используется в OpenVPN (openvpn.sourceforge.net) -> живой пример с кодом etc.
pps: это не единственный выход. просто, первое, что пришло в голову конкретно взятого человека [меня] :)
// wbr
>>Да, Вы правильно поняли задачу. Через BPF можно, но нужно оригинал пакета
>>дропать - неэстетично как-то :-). Есть ли еще варианты?
>
>man tun
>
>первое, что приходит в голову. если вы поставите свой сервис между реальным
>и tun интерфейсом, то вы можете по понятным причинам делать с
>потоком пакетов абсолютно все, что пожелаете. схема типа:
>
>клиент -> ip стек -> tun -> ваш сервис -> допустим, rtk0 -> ip стек
>
>ps: подобным образом tun используется в OpenVPN (openvpn.sourceforge.net) -> живой пример с кодом etc.
>
>pps: это не единственный выход. просто, первое, что пришло в голову конкретно
>взятого человека [меня] :)
>
>// wbr
Спасибо, в принципе, более или менее подходит
>pps: это не единственный выход. просто, первое, что пришло в голову конкретно
>взятого человека [меня] :)
>
>// wbrЕсли это первое пришедшее в голову, то, если не трудно, подскажите еще какие- либо варианты :-)))
>Если это первое пришедшее в голову, то, если не трудно, подскажите еще
>какие- либо варианты :-)))man ipf
// wbr
TCP/IP hijacking is a clever technique that uses spoofed packets to take over a connection between a victim and a host machine. The victim's connection hangs, and the attacker is able to communicate with the host machine as if the attacker were the victim. This technique is exceptionally useful when the victim uses a one-time password to connect to the host machine. A one-time password can be used to authenticate once, and only once, which means that sniffing the authentication is useless for the attacker. In this case, TCP/IP hijacking is an excellent means of attack.As mentioned earlier in the chapter, during any TCP connection, each side maintains a sequence number. As packets are sent back and forth, the sequence number is incremented with each packet sent. Any packet that has an incorrect sequence number isn't passed up to the next layer by the receiving side. The packet is dropped if earlier sequence numbers are used, or it is stored for later reconstruction if later sequence numbers are used. If both sides have incorrect sequence numbers, any communications that are attempted by either side aren't passed up by the corresponding receiving side, even though the connection remains in the established state. This condition is called a desynchronized state, which causes the connection to hang.
To carry out a TCP/IP hijacking attack, the attacker must be on the same network as the victim. The host machine the victim is communicating with can be anywhere. The first step is for the attacker to use a sniffing technique to sniff the victim's connection, which allows the attacker to watch the sequence numbers of both the victim (system A in the following illustration) and the host machine (system B). Then the attacker sends a spoofed packet from the victim's IP address to the host machine, using the correct sequence number, as shown on the facing page.
The host machine receives the spoofed packet and, believing it came from the victim's machine, increments the sequence number and responds to the victim's IP. Because the victim's machine doesn't know about the spoofed packet, the host machine's response has an incorrect sequence number, so the victim ignores the response packet. And because the victim's machine ignored the host machine's response packet, the victim's sequence number count is off. Therefore any packet the victim tries to send to the host machine will have an incorrect sequence number as well, causing the host machine to ignore the packet.
The attacker has forced the victim's connection with the host machine into a desynchronized state. And because the attacker sent out the first spoofed packet that caused all this chaos, the attacker can keep track of sequence numbers and continue spoofing packets from the victim's IP address to the host machine. This lets the attacker continue communicating with the host machine while the victim's connection hangs.