The old question is here. But I still cannot find useful solutions in the question so that I rewrite this question here.
How can i filter (allow, deny etc) outgoing packets in Windows? I want to filter IP packets through particular bits eg. the BPF rule IP[2:2] > 189. And then transmitted these filtered packages to other programs to resolve the packets. But I read the information on Windows Filtering Platform, it allow developers to write a middleware which I think it is hard for me to do.
So is there a relative way to filter packets in Windows xp or 2003 and then transmitted the packets to other applications?
Related
I'm thinking about writing an anti-keylogger/anti RAT application. Basically, what I want it to do is this:
Monitor outgoing ftp traffic (maybe monitor all outgoing traffic and have an option to filter by ftp)
Analyze headers to find potential keyloggers/RATs
Sniff out the FTP address for any such connections
Block (or give user the option to block) connections to these addresses
I think I can handle steps 1-3, and I know I could block all FTP traffic, but how could I go about blocking specific addresses?
On a side note, can anyone suggest some libraries that might make steps 1-3 easier? Or libaries that'll do step 4, if they exist. I don't mind writing code to target multiple OS.
Snort allows you to monitor incoming/outgoing traffic and works based on a set of rules specified in a file. Once you've detected traffic going out that has a certain IP/port/body using snort, use SnortSAM in conjunction with a firewall to block traffic to that IP/port.
I have one question about IP packet trace: is it possible to watch an IP-packet trace in my Windows 7 system? I recieve IP-packets and I want to know - where do this data move: which DLLs do they use, which functions do they call and etc.
Thanks.
Well the most likely solution would be a packetsniffer tool of some kind.
Simply a packet sniffer captures all of the packets of data that pass through a network. Typically, the packet sniffer would only capture packets that were intended for the machine in question. However, if placed different modes, the packet sniffer is also capable of capturing ALL packets travelling over the network regardless of destination.
Hope this helps
Dan
http://www.visualiptrace.com
I'm writing an IPsec implementation for a microcontroller and I want to test it using a standard Linux box running Debian Lenny. Both devices should secure the communication between them using IPsec ESP in tunnel mode. The keys are setup manually using setkey. There's no (or at least should be no) user space program involved in processing an IPsec packet. Now I want to see how my created packets are processed by the Linux kernel. To see the raw packets I capture them using tcpdump and analyze them using wireshark.
What's the best way to obtain debug information about IPsec processing?
How can I figure out whether the packet is accepted by the kernel?
How can I view the reason for a packet to be dropped?
You can instrument the XFRM (or perhaps ipv4/esp.c) kernel code to print out debug messages at the right spots.
For example, in net/ipv4/esp.c there exists a function esp_input() which has some error cases, but you'll see most the interesting stuff is in the xfrm/*.c code.
That said, I didn't have a problem interoperating a custom IPSec with Linux. Following the 43xx specs and verifying the packets came out correctly via wireshark seemed to do well. If you're having issues and don't want to instrument the kernel then you can setup iptables rules and count the number of (various type of) packets at each point.
Finally, be sure you've actually added a security policy (SP) as well as a security association (SA) and setup firewall rules properly.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I want to make an transparent chain-proxy
using a redirect server and chain proxy client written in Qt for Windows.
I've tried ndis+tdi but it's too complicated for me.
I've started to break through the openVPN code.
So the task is to start dummy tap device even if there no need in OpenVPN connection and redirect packets to some addr:port on wich my redirect server will be bound.
Maybe it is better to implement new plugin functions ??...
You can use OpenVPN's TUN/TAP driver ("TAP-Win32") as-is to implement a network device backed by software. I'm not sure what you mean by "rewritten OpenVPN tun/tap driver"; you don't need to modify any existing code - just write your own program which opens TAP-Win32 and reads and writes frames/packets. You don't need any other part of OpenVPN, just TAP-Win32.
However, if you use the TUN/TAP driver, you will have to deal with individual frames/packets. If you will be redirecting just TCP (i.e. you'll redirect connections not packets), it may be useful to have your redirection program only provide a local SOCKS server. With SOCKS you get to work with connections and not packets. If a given network program supports SOCKS, you can simply tell it to use your SOCKS server.
On the other hand, if you want to be able to redirect for all applications, not just those which understand SOCKS (or you don't want to configure each application for SOCKS), you can use a program which will allow you to forward raw TCP connections (on packet level) through your SOCKS server. See my program tun2socks.
Once you have a program operating a TAP-Win32 device, update the routing table to get packets routed into it. You probably want to make it the default route, overriding any previous default routes. But be aware that the routing table applies to the redirection program itself too, so you need to add specific routes for hosts that the redirection program connects to, or they will end up going back into the TAP device. The tun2socks page expains how to do that when using SSH forwarding.
Update: tun2socks deals only with the TUN device and simply forwards all incoming connections. It doesn't decide what you want to forward. Even if it had some policies (like port numbers), it couldn't do anything useful with that info. For example, if it responds with a reject packet, the connection will simply fail - and the OS will not look for an alternative route. (it could forward connections to different SOCKS servers - but I think that would be of no use in your case)
The feature you seem to need is called "policy routing", and it needs to be offered by your operating system. Unfortunately, it appears that Windows does not provide policy routing. If you really need it, you may want to use Linux instead, which provides many more network-related features than Windows (policy routing being one).
Alternatively, instead of using tun2socks, some userspace socksification tool may work for you. These are programs that hook network-related system calls when launching a specific application, in order to make the connections go, for example, through SOCKS. If such an application supports routing rules, it may fit your needs.
An example of such a tool for Windows is ProxyCap (commercial software), which claims support for "flexible routing rules".
How can i filter (allow, deny etc) outgoing packets in Windows? I want to search in TCP or UDP packet types to find in the data segment for example this "387602304fd236e048125453b1fa10c980e9dad4fa7f3f5dd2497c2e8b2b" and drop/block/deny the packet, if it matches the search hex string.
I have already tried WIPFW and PKTFILTER but they only serve IP source, dest, port etc filtering. They don't inspect the packet's data.
I think Berkeley Packet Filter doe's that job, but it's for unix...
Here is some to filter packet in windows:
WinDivert Free open source project work on Windows 7, 2008 or upper. network layer.
WinpkFilter 3.0 Commercial, Windows XP and upper. datalink layer
pcausa, Commercial. datalink layer
Windows Filtering Platform Packet Modification Sample
A sample to create callout driver that WinDivert use, you should now to implement kernel driver. network layer.
you can use SmartSniff in windows.
Starting from version 1.10, you can filter unwanted TCP/IP activity during the capture process (Capture Filter), or when displaying the captured TCP/IP data (Display Filter)
You want application level filtering then, (just changing the payload). If you want to be able to drop, I know you can hook into Winsock, which will allow you to capture packets as they go out and set up a filter there. Windows seven also added to their firewall, so you could use that API to grab outbound packets; I'm not sure if it will allow you to specifically alter the payload data, though.