I need to dump some incoming packets and then prevent them from going up the stack, so that applications won't process them.
Now, tcpdump works at layer 2, right? So ideally I should find some tool that I'd use right after tcpdump that drops selected packets. The filter I apply in tcpdump and when I drop packets is going to be the same.
Anything that already does this?
Now, tcpdump works at layer 2, right? So ideally I should find some tool that I'd use right after tcpdump that drops selected packets.
Tcpdump captures from a network at the link layer, yes. However, "captures", in this case, means "passively taps into the network, getting copies of all packets received and sent". It does not tap into the network in a fashion that allows it to prevent those packets from being processed by the network stack. Think of it as being similar to tapping a phone line - whoever's tapping the line can listen to the conversation, but they can't prevent somebody on one side of the conversation from hearing what the person on the other side says.
Anything that already does this?
There might be, but the mechanism that it would use to do so is probably going to be very dependent on the operating system it's running on. What operating system is the machine on which you need to trap the packets running.
Related
I do have two computers which are used to control an industrial plant. One of them controls the plant, the other is used as a failsafe. They are directly connected over ethernet, and the inactive" one just mirrors the display of the main controller.
I did capture the network traffic between the two and when i open it up in wireshark i see its all X11 traffic. It does include the initial connection request and also includes all the "draw calls" in plain text.
I now want to "replay" this captured stream and recreate the screen content from it. Is there any program available which can do so? Ideally directly from the wireshark capture file
My thoughts so far:
I can easily replay the network data itself and send it to some socket, but the communication is specific to the session, e.g. some commands refer to specific handle values set up earlier. Its unlikely a new session would work with the same values so i cant just pipe it into some program
What you see from your connection is only your connection requests + events relevant to the windows created by you ( or other's client windows where your connection sets an event mask ), and because of that quite a lot is lost. I'm not aware of the programs that can reconstruct best possible version of the screen from one client traffic but it's certainly not possible to have 100% accurate copy of the screen and best possible model will be far away from real screen (unless your connection periodically polls for backing store content of each mapped window).
I am making a CAN simulator for GPS trackers, they only record CAN data and doesn't send ACK. Is it possible to send CAN data with raspberry, using mcp2515/tja1050, without any device on bus that would trigger ACK?
This will usually generate a continuous retransmit.
Some devices have a "one-shot" transmit mode when just sends the CAN frame and does not attempt a retransmission. If you transmitter has this mode you can do what you describe, otherwise you will get a lot of retransmissions.
No it isn't possible, you need at least 2 nodes that are actively participating in the communication. This can however be fixed by just providing another CAN controller on the bus, which doesn't have to do anything intelligent except the ACK part.
For development/debug/test purposes you can however put your own node in "loopback mode", meaning it will speak to itself. Can be handy if you have to proper hardware available yet.
You can try to set the controlmode presume-ack to on.
Assuming you are using the ip command for creating your can sockets that would be something like
ip link set <DEVICE> type can presume-ack on
This will ignore missing ACKs. However I am not sure whether this works with all controllers.
I'm trying to improve the usefulness of the error reporting in a server I am working on. The server uses TCP sockets, and it runs on Windows.
The problem is that when a TCP link drops due to some sort of network failure, the error code that I can get from WSARecv() (or the other Windows socket APIs) is not very descriptive. For most network hiccups, I get either WSAECONNRESET (10054) or WSAETIMEDOUT (10060). But there are about a million things that can cause both of these: the local machine is having a problem, the remote machine or process is having a problem, some intermediate router has a problem, etc. This is a problem because the server operator doesn't have a definitive way to investigate the problem, because they don't necessarily even know where the problem is, or who might be responsible.
At the IP level, it's a different story. If the server operator happens to have a network sniffer attached when something bad happens, it's usually pretty easy to sort of what went wrong. For instance, if an intermediate router sent an ICMP unreachable, the router that sent it will put its IP address in there, and that's usually enough to track it down. Put another way, Windows killed the connection for a reason, probably because it got a specific packet that had a specific problem.
However, a large number of failures are experienced in the field, unexpected. It is not realistic to always have a network sniffer attached to a production server. There needs to be a way to track down problems that happen only rarely, intermittently, or randomly.
How can I solve this problem programmatically?
Is there a way to get Windows to cough up a more specific error message? Is there some easy way to capture and mine recent Windows events (perhaps the one Microsoft Network Monitor uses)? One way I've "solved it" before is to keep dumpcap (from Wireshark) running in ring buffer mode, and force it to stop capturing when a bad event happens, that I can mine later.
I'm also open to the possibility that this is not the right way to solve this problem. For instance, perhaps there is some special Windows mode that can be turned on to cause it to log useful information, that a network administrator could use to track this down after-the-fact.
I am trying to find a solution to monitor the traffic (in and out) through a specific port. It is not required to capture the packets, or do anyting else. What it does is to be a traffic listener to make sure there are messages sent to or received from this port every 10 minutes. It has to be running at the background all the time (like a daemon), and without significant performance impact. Based on my research, one choice is to use an existing tool to do that. There are a bunch of tools out there to monitor or sniff the traffic, such as wireshark. Well, seems most of them monitor the traffic passing through a interface, instead of a port, or they can't run as a daemon. Another choice to write a program to do this. SharpPcap seems to be a good choice, but I still need to capture and analyze the packets to know whether such traffic exist. Could somebody suggest what I should do?
SharpPcap handles packet capturing in the same manner as Wireshark, so you can set filters to limit the packet being captured to a specific port the same way in SharpPcap as you can in wireshark. Except, SharpPcap will be a much lighter weight option vs wireshark.
Download the SharpPcap source tree and look at the Example05.SetFilter.
To narrow down the results so you capture only the packets you want to see you'll need to employ a few filters.
Pcap uses a common language across all applications that use it do specify the filters to set. Capture programs that use winpcap (windows) or libpcap (*nix) include, sharppcap, wireshark, pcap.net, winpcap, libpcap, tcpdump, etc... For a great resource on how to use pcap filters see this link.
Here are the filters you need:
ether host ehost
port port
Where the ehost is the MAC address of the computer sending/receiving the packets and the port is the port you want to monitor. So the full filter string would be.
SetFilter("ether host ff:ff:ff:ff:ff:ff and port 60");
The MAC and port here are for illustration purposes only, you'd obviously change them with the values that pertain to your specific setup.
This, used in the SetFilter example will simply print out a line of info with the time of when the packet was captured to the command line every time a packet is captured and meets the criteria if your filter.
If you want more detailed info about the packet, such as info from the headers or the packet's payload, you'll need to parse the incoming raw packet. Be sure to ask for help on the sourceforge project's forum if you need some tips on how to do this. The project developers are very active and always willing to help.
The best way that will limit the impact your tool will have on performance is via an ETW (Event Tracing for Windows) Real-time Consumer (i.e. a tool that activates an ETW trace and reads it immediately instead of saving it to a file). This MSDN sample is a great way to see how to do this via C# and it gives you some code to get started.
If,for example,The socket in my compiled application is designed to connect to 123.456.789.0.
How do I check if its connected to 123.456.789.0? Is there a way to do this?
The idea is this:I want to prevent other people editing my program and changing the address to,for example, 127.0.0.1 and make it connect through a proxy.
Is there any function/way/trick to check the address after the socket is connected?
Use the getpeername function to retrieve the address of the remote host.
If someone edits your program like you mention, they'll probably alter such a check as well though.
nos's comment about the insecurity of this approach is correct, but incomplete. You wouldn't even need to change the program's code to circumvent your proposed mechanism.
The easiest way around it would be to add an IP alias to one of the machine's network interfaces. Then a program can bind to that interface on the port your program connects to, and the OS's network stack will happily send connections to the attacker's local program, not your remote one.
So, now you say you want to know how to list the computer's interfaces so you can detect this sort of subversion. Your opponent counterattacks, launching your program as a sub-process of theirs after installing a Winsock hook that routes Winsock calls back through the parent process.
We then expect to find you asking how to read the executable code section of a particular DLL loaded into your process space, so you can check that the code is what you expect. Now your opponent drops the Winsock shim, switching to an NDIS layer filter, rewriting packets from your program right before they hit the NIC.
Next we find you looking for someone to tell how to list the drivers installed on a Windows system, so you can check that one of these filters isn't present. Your opponent thinks for about 6 seconds and decides to start screwing with packet routing, selecting one of at least three different attacks I can think of off the top of my head. (No, wait, four.)
I'm not a security expert. Yet, I've spent five minutes on this and already have your security beat seven different ways.
Are you doomed? Maybe, maybe not.
Instead of you coming up with fixes to the risks you can see, better to post a new question saying what it is you're trying to protect, and have the experts comment on risks and possible fixes. (Don't add it here. Your question is already answered, correctly, by nos. This is a different question.)
Security is hard. Expertise counts for far more in that discipline than in most other areas of computer science.