as you can see here I am in the same network as my metsploitable2 machine and I am also doing no ping scan but it is not showing any report.
Related
I would like to scan for available networks, but I ran always into a timeout, no matter how high the timeout is.
My settings:
Raspberry Pi CM3
Quectel EC21
mmcli 1.14.2
multiroaming sim card
Output of the command:
# mmcli -m 0 --3gpp-scan --timeout=120
error: couldn't scan networks in the modem: 'Timeout was reached'
The modem is connected and the internet connection works.
I tried different timeouts (< 5 mins) but none of them work.
Background:
I have the feeling, that the operator of the sim card prefers his own networks even if there are better networks available. To test this I need to scan the networks and afterwards connect to them.
Could it be, that the scanning is disabled (by default?). And if so how the modem decides which network will be preferred?
EDIT: I tried the same command on my laptop (different modem + mmcli 1.20.2) and it worked without problems.
I've got some problem using Snort here. I have some topologies that run under GNS3 for my research. I try to penetration testing to my topology that have IDS Snort in Windows 7 using NMAP (scan) and hping3 (TCP syn flood dos). When I try to scan and dos IP address of my IDS Server (192.168.10.4) it appears alert. But when I try to penetration testing to User 2 IP (192.168.10.2) it's doesn't appear alert. Is there something wrong with my snort.conf in windows 7?
Click here "My Snort Config"
I try to change my ipvar HOME_NET, but still, no luck when I try to pentest
ipvar HOME_NET 192.168.10.0/24
change to
ipvar HOME_NET 192.168.10.1/24,192.168.10.2/24,192.168.10.3/24,192.168.10.4/24,192.168.10.5/24
I expect that when I try to penetration testing in other IP except for my IDS Server. it would give me some alert too...
#Hanif
I believe the question to be posed is where do you want to install snort sensors and what are your desired results.
Some insight from the early 2000s. http://www.informit.com/articles/article.aspx?p=21778&seqNum=9
To me it looks like you have installed the IDS on its own host and you anticipate it to cover the other three, well two host running windows. You want to "pentest" the windows machines and see what IDS alerts show for such attacks.
I would urge you to install snort on the two windows hosts and have all the alerts aggregate into something like Elasticsearch. Some further direction for you here: https://blog.snort.org/2017/11/snort-30-with-elasticsearch-logstash.html
I used nmap to look up my Raspis on my local lan and I made a mistake defining the IP-Range. Instead of
nmap -sn 192.168.2.0/24
I typed
nmap -sn 192.168.2./24
Nmap returned external IP-addresses:
Starting Nmap 7.01 ( https://nmap.org ) at 2017-10-14 10:09 CEST
Nmap scan report for dns1.hadcs.de (62.138.238.1)
Host is up (0.023s latency).
Nmap scan report for cmdb.hadcs.de (62.138.238.10)
Host is up (0.032s latency).
Nmap scan report for monitoring.hadcs.de (62.138.238.15)
Host is up (0.026s latency).
Nmap scan report for confluence.hadcs.de (62.138.238.16)
...
I want to understand what's happening here. In combination with nse-options this behavior may result in serious legal problems (at least in Germany).
Probably neither of those is what you wanted, which is 192.168.2.0/24.
When you enter 192.168.2./24, the final . makes the address be interpreted as a hostname to be looked up via DNS. Your ISP (or someone) is intercepting NXDOMAIN (name not found) responses and injecting its own answers. So instead of Failed to resolve "192.168.2." which is expected, you get an answer that is something like 62.138.238.16. Nmap then applies the CIDR bitmask to expand that into the network of 256 adjacent addresses.
Using 192.168.2/24, the base address is expanded via inet_aton according to some unusual rules detailed in the man page for that function. Specifically, it is expanded to 192.168.0.2, so you end up scanning the equivalent of 192.168.0.0/24, which is also not what you wanted to scan.
The solution is to always use all 4 octets of an IPv4 address to avoid odd interpretations.
Executing following command "sudo nmap -sP 123.00.0.00" depending on the network might return:
Nmap scan report for 123.00.0.00
Host is up (0.28s latency).
MAC Address: 84:38:35:XX:XX:XX (Apple)
or (let's assume it's the same IP but different network)
Nmap scan report for Tomas-Mac-Book (123.00.0.00)
Host is up (0.28s latency).
MAC Address: 84:38:35:XX:XX:XX (Apple)
I'm guessing this depends on the network settings. Is there a way to get the device name in cases where only IP is returned with the above command?
With the -sP option, NMAP makes a DNS request to resolve the names of the IPS's:
. By default, Nmap still does reverse-DNS resolution on the hosts to
learn their names
From NMAP Host discovery options
So, if the network DNS is able to resolve the names of the hosts, NMAP returns the network names of each IP.
To avoid this DNS resolution, if you add a 'n', it is disabled so -snP, would never try to make a DNS resolution.
scan types, begin with -s, such as nmap -s* target_host
ping options, begin with -P, such as nmap -P* target_host
I have used wireshark and nmap to see underlying actions options -P*.
When I run both command
nmap -p9527 target_host
and
nmap -sP target_host
I found that the only distinction is that -sP cannot be used with port scan option, such as -p9525.
I wanna to clarify, whether both of two option -s* and -P* are used to detect the liveness of target host.
By the way, my environment is on kali which is running on virtual host. I used tcpdump to catch packets and wireshark to analyze.And I run commands as root user.
There are many phases to an Nmap scan, and the two that these options refer to are host discovery and port or protocol scan.
The -P* family of options are all different ways to do host discovery. The default scan (if none of these is chosen) performs host discovery using the best method available. The -Pn option tells Nmap to skip this phase altogether. It used to be documented as -PN, but we changed it to conform with the other "turn this feature off" options. Before that, it was -P0, but there was confusion between that and -PO.
The -s* family of options are all different types of port and protocol scans. The default scan is a TCP port scan with either -sS or -sT, depending on privilege level. The -sn option tells Nmap to skip this phase altogether. It used to be documented as -sP (for "Ping scan"), but that caused the kind of confusion that you and others have reported.
Usually aping scan of some sort is done first, and then the hosts that have been found to be up are scanned for open ports.
You can turn the ping scan off (-Pn). There are also many types of ping scans, including TCP on an optionally specified port. Which varieties of scan are availabledepends on whether you have root privileges. IF you are not root, then ICMP echo ping is not available.
nmap -p9527 target_host with no other options will first ping the target, and then scan TCP port 9527.
A ping scan with sP (i.e. ping only) is only for testing which hosts are up. The port scan is omitted. So yeah, it's incompatible with specifying which ports should be scanned.