How to retrieve both TCP and UDP ports with Nmap? [closed] - tcp

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I need to retrieve both TCP and UDP ports in the same scan with Nmap in the fastest way possible. I'll try to explain it better. If I use the most common command:
nmap 192.168.1.1
It retrieves ONLY TCP ports and it is really fast.
If I use the following command:
nmap -sU 192.168.1.1
It retrieves ONLY UDP ports and it is quite fast (well not so fast but still).
My question: is there a combination of the two commands? I tryed:
nmap -sU -sS 192.168.1.1
nmap -sU -sT 192.168.1.1
But they are TERRIBLY slow.
I am using Nmap 5.51, any suggestion?

As you've seen, UDP scanning is slow as open/filtered ports typically don't respond so nmap has to time out and then retransmit whilst closed ports will send a ICMP port unreachable error, which systems typically rate limit.
You can add the -T switch to increase the speed of the scan, though this may reduce accuracy and make it easier to detect.
-T<0-5>: Set timing template (higher is faster)
-PN will turn off the ping scan element
You could also scan more hosts in parallel,
or reduce the number of ports you're scanning with the -p switch or --top-ports , which will scan the highest-ratio ports found in the nmap-services file.
If you were scanning multiple hosts, you could use --host-timeout to skip slow hosts.
Regarding TCP, -sS should be quicker than -sT.
HTH!

You didn't say how slow your scans get, but I think you would benefit from playing with the --min-parallelism option, which adjusts the minimum number of outstanding probes.
I'm seeing 70% reductions in scan time (compared with bare -sT -sU scans) like this. Note that it is possible to set --min-parallelism too high, such that the host (or network) cannot buffer this many queries simultaneously.
[mpenning#Hotcoffee]$ sudo nmap --min-parallelism 100 -sT -sU localhost
Starting Nmap 5.00 ( http://nmap.org ) at 2012-05-10 01:07 CDT
Interesting ports on localhost (127.0.0.1):
Not shown: 1978 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
49/tcp open tacacs
53/tcp open domain
80/tcp open http
111/tcp open rpcbind
631/tcp open ipp
2003/tcp open finger
2004/tcp open mailbox
3389/tcp open ms-term-serv
5901/tcp open vnc-1
5910/tcp open unknown
6001/tcp open X11:1
7002/tcp open afs3-prserver
53/udp open|filtered domain
69/udp open|filtered tftp
111/udp open|filtered rpcbind
123/udp open|filtered ntp
161/udp open|filtered snmp
631/udp open|filtered ipp
1812/udp open|filtered radius
1813/udp open|filtered radacct
Nmap done: 1 IP address (1 host up) scanned in 1.54 seconds
[mpenning#Hotcoffee]$

Related

Cannot Find BACnet Device

I am quite new to the BACnet protocole but I am facing some troubles finding a device on a network.
Basically, I have a setup on a network 128.10.100.XXX/24 where I have multiple devices, as my nmap scan will show
root#xxx:/home/xxx# nmap -sP 128.10.100.120/24
Starting Nmap 7.80 ( https://nmap.org ) at 2022-11-02 05:11 UTC
Nmap scan report for 128.10.100.1
Host is up (0.00076s latency).
MAC Address: 00:50:06:XX:XX:XX (TAC AB)
Nmap scan report for 128.10.100.150
Host is up (0.00059s latency).
MAC Address: 00:80:4F:XX:XX:XX (Daikin Industries)
Nmap scan report for 128.10.100.160
Host is up (0.00024s latency).
MAC Address: 00:50:06:XX:XX:XX (TAC AB)
Nmap scan report for xxx (128.10.100.120)
Host is up.
When I run specific scans for BACnet, all devices have an open 47808 port:
Starting Nmap 7.80 ( https://nmap.org ) at 2022-11-02 13:08 UTC
Nmap scan report for 128.10.100.150
Host is up (0.0093s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
47808/udp open|filtered bacnet
MAC Address: 00:80:4F:XX:XX:XX (Daikin Industries)
However, when I am trying to use BACnet utilities (BACpypes in python or bacnet-stack in node.js), no device is found. I tried multiple libraries and various setups (modifying the broadcast address, etc...) without any success.
I struggle to understand the reason...
Thank you in advance for your help,
A.
Have you validated your setup using 3rd party tools such as YABE ?
Fire up wireshark with a capture filter "port 47808", then look at the who-is from your app vs the who-is from YABE.
Also check the netmask on both devices match... this will affect the broadcast messages.
Speaking of which, try a directed who-is message to the controller from your app to see if the controller responds.
Things worth considering :-
Tools such as YABE, VTS and Wireshark - to learn from the success cases/successful instances of communication.
The network card (NIC) that your tools and/or libraries are using/selecting to send the ('service' request) messages - e.g. definitely don't mix routable addresses with non-routable 'private' addresses (between the BACnet 'client' IP & the 'server' IP).
(UDPv4-only) 'Broadcasts' will only work upon the local network (- if a BBMD is not present & correctly set-up to relay the broadcast on to another part/hop of the "internetwork"/connected networks).
If you're unlucky - with a particular device, your client port just might have to be 47808/0xBAC0; and just possibly for the broadcasts too.
Also try directed/'unicast' traffic/'service' requests too - e.g. attempting to read the device object instance # (DOIN) of a target device; check you've got/are specifying the correct DOIN when targeting/firing a request at a device.
Does the target device have a BACnet router or BACnet gateway in front of it (- therefore would also need the inclusion of a DNET & DADR paired values as part of addressing it)?
If so, are you talking the same variant of BACnet, e.g. IP - as in BACnet/IP between both the (BACnet) 'client' & 'server'/serving device?
If it's a commercial/enterprise device, does it have a IP whitelist - to allow for the processing of incoming requests?

FreeBSD - tcpdump - filtration of certain udp port [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I'm using freebsd 10.4
what argument i can use in tcpdump to match only certain UDP port?
is it -i parameter ?
this is what i already reviewed https://www.freebsd.org/cgi/man.cgi?tcpdump(1)#end
The option -i is for the interface from the man page:
-i interface
--interface=interface
Listen on interface. If unspecified, tcpdump searches the sys-
tem interface list for the lowest numbered, configured up inter-
face (excluding loopback), which may turn out to be, for exam-
ple, ``eth0''.
In the same man page you have some examples like:
To print all IPv4 HTTP packets to and from port 80, i.e. print only
packets that contain data, not, for example, SYN and FIN packets and
ACK-only packets. (IPv6 is left as an exercise for the reader.)
tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
Probably it is not the simplest one but can give you an idea to achieve what you are looking for.
Let's say you want to capture DNS request, UDP port 53 on your main interface em0, this could be a starting point:
tcpdump -i em0 'udp port 53'
Now if you want to go further you could use Wireshark over ssh, give a try to:
wireshark -k -i <(ssh user#host sudo tcpdump -i em0 -U -w - not tcp port 22)
or in another way (in this case using PF interface pflog):
ssh use#server sudo tcpdump -i pflog0 -U -w -| wireshark -k -i -

Will tcpdump capture packets where destination mac address does not match NIC's mac address

I am running some data throughput tests by sending UDP packets using iperf through a VM that does some sort of processing on those packets.
My application runs in promiscuous mode, so it will pick up all packets.
I saw my application drop some packets, but my application counters show that it was not due to any slowdown or failures.
I put some logs in my application and they suggested that the ethernet frame itself may be corrupted.
I was also running tcpdump on the vnics of both the iperf machine and my packet processor but these packets never showed up in the traces. I was hoping to see corrupted packets appear in the traces.
The commands looked like this:
tcpdump -i vnet11 -C 100 -w iperf.pcap
tcpdump -i vnet7 -C 100 -w sgi.pcap
My doubt is, if the ethernet frame is itself corrupted and the destination MAC itself does not match the MAC address of vnet7 or vnet11, will tcpdump capture those packets?
Edit:
It just struck me that if Ethernet frame itself was corrupted which caused destination MAC to mismatch, then the linuxbridge won't send that packet to my packet processor's vnet interface in the first place. So tcpdump does not have anything to capture here. Please ignore this question.
In fact, if the problem is a corrupt Ethernet frame, you will not see it at all. Your network card will discard the frame and your sniffer will never see it.
Running in promiscuous mode will normally disabled the MAC filtering on your network card so that the sniffer will see all packets, regardless of the destination MAC. However, you cannot see packets that are not sent to the NIC (obviously), so in a switched environment, unless you take additional steps to either attack the switch or configure a span or mirror ports, you will only see broadcasts and frames that are destined for a MAC on your system.
Virtual Machines can complicate this further. Different virtualization solutions handle this in different ways. In some, for instance, the administrator can choose to configure whether or not frames that do not match the host address are delivered to the VM, effectively making promiscuous mode moot.

iperf TCP much faster than UDP, why? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I am wondering why iperf shows much better performance in TCP than UDP. This question is very similar to this one.
UDP should be much faster than TCP because there are no acknowledge and congestion detection. I am looking for an explanation.
UDP (807 MBits/sec)
$ iperf -u -c 127.0.0.1 -b10G
------------------------------------------------------------
Client connecting to 127.0.0.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 127.0.0.1 port 52064 connected with 127.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 962 MBytes 807 Mbits/sec
[ 3] Sent 686377 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 960 MBytes 805 Mbits/sec 0.004 ms 1662/686376 (0.24%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
TCP (26.7 Gbits/sec)
$ iperf -c 127.0.0.1
------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 5001
TCP window size: 2.50 MByte (default)
------------------------------------------------------------
[ 3] local 127.0.0.1 port 60712 connected with 127.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 31.1 GBytes 26.7 Gbits/sec
The default length of UDP datagrams is 1470 bytes. You probably need to increase the length with the -l parameter. For 26Gb/s I'd try something like 50000 for your -l parameter and go up or down from there
You also probably need to add a space between your '-b10G' so that it knows 10G is the value to use for the -b parameter. Also I believe the capital G means GigaBYTES. Your maximum achievable bandwidth with a TCP test is 26 GigaBITS which isnt anywhere close to 10GB. I would make your -b parameter value 26g, with a lower-case g.
I suspect you're using the old iperf version 2.0.5 which has known performance problems with UDP. I'd suggest a 2.0.10 version.
iperf -v will give the version
Note 1: The primary issue in 2.0.5 associated with this problem is due to mutex contention between the client thread and the reporter thread. The shared memory between these two threads was increased to address the issue.
Note 3: There are other performance related enhancements in 2.0.10.
Bob
UDP should be much faster than TCP because there are no acknowledge and congestion detection.
That will mostly depending on what you are looking to do. If you need to transfer files between two end-points in the Internet, unless you manually implement a reliable transmission mechanism on UDP at the application level, you will want to use TCP.
In my opinion, it does not make much sense to do a pure UDP bandwidth test with iPerf, as essentially it just results in iPerf trying to put packets on the wire as fast as possible. I would suggest using it for generating UDP flows with a constant data rate, in order to roughly measure what would happen to UDP traffic, such as VoIP, in your network.
TCP is helped with various hadware offloads such as tso/gro where as UDP is not helped by any of those offloads as they don't apply on udp datagrams.

does an ip address have multiple ports? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I have read somewhere that "if you are the remote user connecting to a web server, then your web browser would pick a random TCP port from a certain range of port numbers, and attempt to connect to port 80 on the IP address of the web server". Does that mean that a particular ip address at client side have multiple ports?
Every system which implements TCP/IP has multiple "ports". The IP address refers to the entire system, if that's all we had it would be pretty boring. One program on a system could talk to one program on another system.
Hence the idea of "ports". Ports are just a 16-bit number which "completes" the address. So, your program on system 1.2.3.4 wants to talk to the webserver running on 2.3.4.5. The webserver "binds" itself to port 80. This is an example of a "well known port". But, how is the webserver to get data back to you? Your program needs a "port" of its own. But, it can be any old number, it doesn't need to be well known, so it just tells the OS I need a port and the OS finds one not in use and your program is "bound" to that port. Say it is port 3456.
So now we have all we need: 1.2.3.4:3456 can talk to 2.3.4.5:80
and when the packets of data for port 80 arrive at 2.3.4.5, the OS delivers them to the webserver. And when the packets of data for port 3456 arrive back at your computer (1.2.3.4), your OS delivers them to your web browser.
Whereever you read that, it's wrong. The TCP implementation picks a random local port. Not the browser. There are 65535 TCP ports per IP address, and another 65535 UDP ports.

Resources