How do I use Windump using Cuckoo in Windows10 - networking

When I analyze a file using Cuckoo
These error I have.
File "c:\python27\lib\site-packages\cuckoo\auxiliary\sniffer.py", line 157, in stop
(out, err, faq("permission-denied-for-tcpdump"))
CuckooOperationalError: Error running tcpdump to sniff the network traffic during the analysis; stdout = '' and stderr = 'tcpdump.exe: listening on VirtualBox Host-Only Ethernet Adapter\r\ntcpdump.exe: Error opening adapter: \xbd\xc3\xbd\xba\xc5\xdb\xc0\xcc \xc1\xf6\xc1\xa4\xb5\xc8 \xc0\xe5\xc4\xa1\xb8\xa6 \xc3\xa3\xc0\xbb \xbc\xf6 \xbe\xf8\xbd\xc0\xb4\xcf\xb4\xd9. (20)\r\n'. Did you enable the extra capabilities to allow running tcpdump as non-root user and disable AppArmor properly (the latter only applies to Ubuntu-based distributions with AppArmor, see also https://cuckoo.sh/docs/faq/index.html#permission-denied-for-tcpdump)?
My Virtualbox network(guest) name is VirtualBox Host-Only Ethernet Adapter
and my Windows10(host) is installed Windump(renamed as tcpdump.exe), Path is C:\tools\tcpdump.exe
also I set auxiliary.conf file.
# Specify the path to your local installation of tcpdump. Make sure this
# path is correct.
tcpdump = C:/tools/tcpdump.exe
My question is that why I'm getting an error like listening on VirtualBox Host-Only Ethernet Adapter\r\ntcpdump.exe: even though setting a tcpdump.exe path currectly.

I found the answer.
Confugured this line in sniffer.py.
From
err_whitelist_start = (
"tcpdump: listening on ",
"C:/tools/tcpdump.exe: listening on",
)
To
err_whitelist_start = (
"tcpdump: listening on ",
"C:\\tools\\tcpdump.exe: listening on",
)
And my virtualbox interface is wrong. So changed this
virtualbox.conf
From
interface = virtualBox Host-Only Ethernet Adapter
To
interface= \Device\NPF_{ED29CFE9-25EB-4AD9-B2EA-C09A93D465BF}

Related

Using vector.dev to generate syslog from other lxc containers

I am wondering how to configure vector.dev to recieve syslog from other lxc containers. I have docker-compose running and vector installed on one container. The other containers host PBX and I'm wondering how I would go about configuring this to have one syslog central server using vector?
I believe I have to create a socket but my current configuration is just this in the vector.toml file:
[sources.syslog]
type = "syslog"
address = "0.0.0.0:514"
max_length = 102_400
mode = "udp"
path = "/vector.socket"
[sources.in]
type = "stdin"
[sinks.out]
inputs = ["in"]
type = "console"
encoding.codec = "text"
This is on the host currently. I believe I'm suppose to install vector on the instances I want to get logs from too ?

gitlab-runner Could not resolve host: gitlab.com

I have a raspberry pi with gitlab-runner installed (linux version) and a git repository on gitlab.com (not self hosted).
At the beginning of pipeline, gitlab-runner on raspberry try to fetch the .git repo but I get :
Could not resolve host: gitlab.com
I tried :
ping gitlab.com is ok on the raspberry
Add extra_host = ['localhost:my.ip.ad.ress] --> No changes
Add netword_mode = "gitlab_default" like this, And get :
This error :
Error response from daemon: network gitlab_default not found (exec.go:57:1s)
I am in the simplest configuration with repo on gitlab.com and a gitlab-runner on raspberry. How can I deal with it ?
Here is the config.toml :
concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "gitlab runner on raspberryPi"
url = "https://gitlab.com/"
token = "XXXX"
executor = "docker"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.docker]
tls_verify = false
image = "node:latest"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
I had same issue , my gitlab-runner was running on my local. I restarted my docker
systemctl restart docker
and error went away.
Not being able to resolve the host name can have multiple root-causes:
IP forwarding disabled?
Routing might be disabled on your system. Check if IP forwarding is enabled (== 1).
cat /proc/sys/net/ipv4/ip_forward
1
If it's disabled, it will return 0, please enable it by editing a sysctl file. For example edit and add: /etc/sysctl.d/99-sysctl.conf:
net.ipv4.conf.all.forwarding = 1
net.ipv4.ip_forward = 1
Apply the setting without rebooting: sudo sysctl --system
Important Note: Even if the system is reporting that IP forwarding is currently enabled, you might want to set to explicitly and correctly in your sysctl configs. Since Docker will run sysctl -w net.ipv4.ip_forward=1 when the Daemon starts-up. But that is not a persistent setting, and might cause very random issues!! Like you have.
DNS missing / invalid?
You can try if setting a DNS server to 8.8.8.8 might fix the problem:
[runners.docker]
dns = ["8.8.8.8"]
Add extra_host?
You can also try to add an extra host, which might be mainly relevant within a local network (so not with gitlab.com domain).
[runners.docker]
extra_hosts = ["gitlab.yourdomain.com:192.168.xxx.xxx"]
Using host network
I really do not advise this, but you could configure the Docker container to run with network_mode as "host". Again, only do this for debugging reasons:
[runners.docker]
network_mode = "host"

NT_STATUS_IO_TIMEOUT when trying to connect with samba client

I am trying to connect to a windows machine in my local network from ubuntu with samba client. To send a message I type :
smbclient -M 192.168.1.10
But I get
Connection to 192.168.1.10 failed. Error NT_STATUS_IO_TIMEOUT
This is most likely because the box your trying to do smbclient uses an outdated (and insecure) version of SMB such as SMBv1.
You'll need to edit the smb.conf in your machine and specify the client min protocol into CORE. You'll also need to specify the client max protocol into SMB3.
More information here: https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html
Steps:
On your host machine:
sudo nano /etc/samba/smb.conf
Add the following settings under Global Settings:
client min protocol = CORE client max protocol = SMB3
Write (Ctrl + O) and Exit (Ctrl + X) nano text editor.
Retry smbclient

How can I access a VM console from the command line of another machine

I have a VMWare vSphere 5.5 Hypervisor with a RHEL VM running on it.
From my understanding of the documentation at http://libvirt.org/drvesx.html, I believe I should be able to interact fully with the VM using libvirt, via virsh.
However, after connecting to the hypervisor, when I attempt to start a console via:
virsh -c esx://$USER#$HOST?no_verify=1 console VMNAME
I receive the following:
Connected to domain VMNAME
Escape character is ^]
error: this function is not supported by the connection driver: virDomainOpenConsole
Am I doing something wrong or does libvirt not allow access to the VM console via an ESX Hypervisor?
By the error message, it looks like the ESX driver doesn't allow the user to open a VM console. There's not much to do then...

Solaris. xterm display problem

I connect to a solaris (10) server through SSH from my linux machine.
However, when I attempt to open another terminal using " xterm" , then it does not work.
I set the DISPLAY env variable to 127.0.0.1:0.0, but it gives the following error:xterm Xt
error: Can't open display: 127.0.0.1:0.0
Please suggest a solution to rectify this.
Thanks
-Mike
That's the address of the X server on the target machine. You need to address the X server on the client machine on which you're working. The easiest way is to just use ssh -X or -Y, (see man ssh(1)) as
client: ssh -Y solaris
in order to connect to the remote machine; you need login info too
This just sets up an X connection, tunneled through ssh.
Otherwise, you can do it by hand as
client:
$ echo $DISPLAY
client:3:4
remember it's not *always* 0.0
$ xhost +solaris
You have to allow connections from the remote machine
$ ssh solaris
sets up a remote shell, you still need ssh login info
solaris:
$ export DISPLAY client:3.4
make sure its the server on 'client' you're using
$ xterm
This should now give you a 'solaris' xterm window on 'client'
As Charlie mentioned, use ssh -X hostname when connecting.
If all else fails enter xhost + on your remote machine. Hope that helps.
Set the display to your linux IP address, not localhost.
127.0.0.1 is localhost : therefore on the Solaris server, it's the server itself.

Resources