I'm using RawCap to capture packets sent from my dev machine (one app) to itself (another app). I can get it to write the captures to a file like so:
RawCap.exe 192.168.125.50 piratedPackets.pcap
...and then open the *.pcap file in Wireshark to examine the details. This worked when I called my REST method from Postman, but when using Fiddler's Composer tab to attempt the same, the *.pcap file ends up being empty. I think this may be because my way of shutting down RawCap was rather raw itself - I simply closed the command prompt. Typing "exit" does nothing while it's busy capturing.
How can I make like a modern-day Mansel Alcantra if I the captured packets sink to the bottom of the ocean before I can plunder the booty? How can I gracefully shut RawCap down so that it (hopefully) saves its contents to the log (*.pcap) file?
RawCap is gracefully closed by hitting Ctrl + C. Doing so will flush all packets from memory to disk.
You can also tell RawCap to only capture a certain number if packets (using -c argument) or end sniffing after a certain number of seconds (using -s argument).
Here's one example using -s to sniff for 60 seconds:
RawCap.exe -s 60 192.168.125.50 piratedPackets.pcap
Finally, if none of the above methods is available for you, then you might wanna use the -f switch. By using -f all captured packets will be flushed to disk immediately. However, this has a performance impact, so you run a greater risk of missing/dropping packets when sniffing with the -f switch.
You can run RawCap.exe --help to show the available command line arguments. They are also documented here:
http://www.netresec.com/?page=RawCap
Related
I'm trying to run Pktgen and record packet data to a pcap file. When I'm running this command:
./usr/local/bin/pktgen --no-telemetry -l 4,6,8 -n 4 -a 0000:03:02.0 -m 1024 -- -T -P -m [6:8].0 -s 0:pcap/captured_packets.pcap
It returns the following error message:
_pcap_open: failed to read the file header
!ERROR!: Invalid PCAP filename (0:pcap/captured_packets.pcap) must include port number as P:filename
What is wrong with the command? It seems to like the syntax of the command should be correct, so maybe it has something to do with the ports? If I run it without -s 0:pcap/captured_packets.pcap Pktgen works as it should.
I have also checked out a previous thread on this (Sending pcap file via packetgen dpdk), but it didn't give any further input into how to solve the issue.
For pktgen, the -s <port>:<pcap file> is only used for playback. It has a couple of drawbacks, including that it doesn't honor pcap timestamps and will just play at whatever rate is configured by the user. The other drawback is that I believe pktgen does not send jumbo packets in their entirety, but will limit any sent packet to the size of the payload section in a single rte_membuf.
If you're interested in using DPDK to record pcaps, you may look into dpdk-pdump and dumpcap.
I've also had good performance in the past when building my own packet recorder, especially since I know I can program it to receive and record any jumbo packets and run across any number of queues and threads.
I am trying to build a perl based server that will accept incoming requests and, based on that request, read/write data to server's STDIN/OUT. So I need to accept data from the client STDIN, write it to the server's STDIN (where it is handled by another process), capture the results of that request from the server's STDOUT and then ship it to the client.
I was hoping to build this off of Net::Server but I cannot, for the life of me, figure out how to direct data specifically to the server's STDIN. In my ideal world I'd have a set of file handles like CLISTDIN, CLISTDOUT, SRVSTDIN, and SRVSTDOUT that I could discretely address and manage. I'm just at a loss of how to go about it in Net::Server.
I don't have to use Net::Server so other suggestions are welcome. Net::Server just has a number of other features I would like to use.
Thanks for any insight.
Have you thought about just using ssh? With ssh your can run commands on a remote computer (server) which redirects your stdin to that command, and the stdout from that command to yours. Simple demo:
$ echo "hello, world" | md5sum
22c3683b094136c3398391ae71b20f04 -
$ echo "hello, world" | ssh myserver.com md5sum
22c3683b094136c3398391ae71b20f04 -
Or
$ echo "hello, world" | ssh user#myserver.com "/path/any/command --with --args x y z"
(You can set up ssh for automatic login with ip check by ssh-keygen and ~/.ssh/authorized_keys wont say more about that here)
Turns out I could do this by overloading post_accept to change how STDIN/STDOUT were being used. I was able to create two distinct filehandles so I could refer to the client IN/OUT without breaking the servers IO. That said, Net::Server kept getting in the way of what IO wanted to do so I abandoned it and just rolled my own forking server. Ended up being easier overall.
Is there a way to skip a host while it is being scanned. I am providing a list of hosts to nmap and while it is scanning from that list, I would like to skip one host because the scripts keep running on that host hence delaying my scan. Please suggest.
Thanks
There is not a way during runtime to stop scanning a host. However, you can impose time limits on how long Nmap spends on a particular host. The --host-timeout option will cause Nmap to drop all results and stop scanning a target when the timeout expires. Unfortunately, this means all that work is lost. But there is a better way, if NSE scripts are slowing you down.
Nmap 7.30 added the --script-timeout option, which puts a time limit on each NSE script that runs against a target. Any script that exceeds the time limit will be terminated and will produce no output, but any other scripts will be allowed to run. No port scan, OS detection, or traceroute data will be lost.
Your last option if NSE is taking too long is to find out which script is causing the problem. Most NSE scripts are designed to run quickly; even most of the brute-force password guessing scripts enforce a 10-minute time limit. But sometimes there are bugs, and other times you may select a script with an intentionally long run time. In debug mode (-d or press d during runtime), printing a status line (by pressing any key during execution) will show a list of running scripts when there are 5 or fewer running. At debug level 2 (-dd or press d twice), a full stack trace of each running script thread is produced, which can help Nmap developers debug delays. If you suspect a misbehaving script, you can file a bug report on Github or send it to dev#nmap.org.
nmap has a host timeout option which will give up on any host that takes longer than the provided value. So, the below option would give up on any host that takes longer than 10 minutes. You can read more about the various timing related options here.
nmap --host-timeout 10m
I'am about to build an automatic intrusion detection system (IDS) behind my FritzBox Router in my home LAN.
I'm using a Raspberry Pi with Raspbian Jessie, but any dist would be ok.
After some searches and tryouts I found ntop (ntopng to be honest, but I guess my questions aims to any version).
ntop can capture network traffic on its own, but thats not what I want because I want to get all the traffic without putting the Pi between the devices or let him act as a gateway (for performance reasons). Fortunately my FritzBox OS has a function to simulate a mirror port. You can download a .pcap which is continously written in realtime. I do it with a script from this link.
The problem is that I can't pipe the wget download to ntop like I could do it with e.g. tshark.
I'm looking for:
wget -O - http://fritz.box/never_ending.pcap | ntopng -f -
While this works fine:
wget -O - http://fritz.box/never_ending.pcap | tshark -i -
Suggestions of other analyzing software is ok (if pretty enough ;) ) but I want to use the FritzBox-pcap-thing...
Thanks for saving another day of mine :)
Edit:
So I'm comming to this approaches:
Make chunks of pcaps an run a script to analyse every pcap after another. Problem ntop do not merge the results, and I could get a storage problem if traffic running hot
Pipe wget to tshark and overwrite one pcap every time. Then analyse it with ntop. Problem again, the storage
Pipe wget to tshark cut some information out and store them to a database. Problem which info should I store and what programm likes dbs more than pcaps ?
The -i option in tshark is to specify an interface, whereas the -f option in ntop is to specify a name for the dump-file.
In ntopng I didn't even know there was a -f option!?
Does this solve your problem?
I am on an embedded platform (mipsel architecture, Linux 2.6 kernel) where I need to monitor IPC between two closed-source processes (router firmware) in order to react to a certain event (dynamic IP change because of DSL reconnect). What I found out so far via strace is that whenever the IP changes, the DSL daemon writes a special message into a UNIX domain socket bound to a specific file name. The message is consumed by another daemon.
Now here is my requirement: I want to monitor the data flow through that specific UNIX domain socket and trigger an event (call a shell script) if a certain message is detected. I tried to monitor the file name with inotify, but it does not work on socket files. I know I could run strace all the time, filtering its output and react to changes in the filtered log file, but that would be too heavy a solution because strace really slows down the system. I also know I could just poll for the IP address change via cron, but I want a watchdog, not a polling solution. And I am interested in finding out whether there is a tool which can specifically monitor UNIX domain sockets and react to specific messages flowing through in a predefined direction. I imagine something similar to inotifywait, i.e. the tool should wait for a certain event, then exit, so I can react to the event and loop back into starting the tool again, waiting for the next event of the same type.
Is there any existing Linux tool capable of doing that? Or is there some simple C code for a stand-alone binary which I could compile on my platform (uClibc, not glibc)? I am not a C expert, but capable of running a makefile. Using a binary from the shell is no problem, I know enough about shell programming.
It has been a while since I was dealing with this topic and did not actually get around to testing what an acquaintance of mine, Denys Vlasenko, maintainer of Busybox, proposed as a solution to me several months ago. Because I just checked my account here on StackOverflow and saw the question again, let me share his insights with you. Maybe it is helpful for somebody:
One relatively easy hack I can propose is to do the following:
I assume that you have a running server app which opened a Unix domain listening socket (say, /tmp/some.socket), and client programs connect to it and talk to the server.
rename /tmp/some.socket -> /tmp/some.socket1
create a new socket /tmp/some.socket
listen on it for new client connections
for every such connection, open another connection to /tmp/some.socket1 to original server process
pump data (client<->server) over resulting pairs of sockets (code to do so is very similar to what telnetd server does) until EOF from either side.
While you are pumping data, it's easy to look at it, to save it, and even to modify it if you need to.
The downside is that this sniffer program needs to be restarted every time the original server program is restarted.
This is similar to what Celada also answered. Thanks to him as well! Denys's answer was a bit more concrete, though.
I asked back:
This sounds hacky, yes, because of the restart necessity, but feasible.
Me not being a C programmer, I keep wondering though if you know a
command line tool which could do the pass-through and protocolling or
event-based triggering work for me. I have one guy from our project in
mind who could hack a little C binary for that, but I am unsure if he
likes to do it. If there is something pre-fab, I would prefer it. Can it
even be done with a (combination of) BusyBox applet(s), maybe?
Denys answered again:
You need to build busybox with CONFIG_FEATURE_UNIX_LOCAL=y.
Run the following as intercepting server:
busybox tcpsvd -vvvE local:/tmp/socket 0 ./script.sh
Where script.sh is a simple passthrough connection
to the "original server":
#!/bin/sh
busybox nc -o /tmp/hexdump.$$ local:/tmp/socket1 0
As an example, I added hex logging to file (-o FILE option).
Test it by running an emulated "original server":
busybox tcpsvd -vvvE local:/tmp/socket1 0 sh -c 'echo PID:$$'
and by connecting to "intercepting server":
echo Hello world | busybox nc local:/tmp/socket 0
You should see "PID:19094" message and have a new /tmp/hexdump.19093 file
with the dumped data. Both tcpsvd processes should print some log too
(they are run with -vvv verbosity).
If you need more complex processing, replace nc invocation in script.sh
with a custom program.
I don't think there is anything that will let you cleanly sniff UNIX socket traffic. Here are some options:
Arrange for the sender process to connect to a different socket where you are listening. Also connect to the original socket as a client. On receipt of data, notice the data you want to notice and also pass everything along to the original socket.
Monitor the system for IP address changes yourself using a netlink socket (RTM_NEWADDR, RTM_NEWLINK, etc...).
Run ip monitor as an external process and take action when it writes messages about added & removed IP addresses on its standard output.