how can i change OS CPE in ubuntu.
this is my CPE: OS CPE: cpe:/o:linux:linux_kernel:3
when scanning with nmap leakage all my OS properties . but I need to change the original information to fake information.
My main goal is that the nmap scanner can not identify the type of operating system
This question should be more for Security StackExchange. Anyway...
There are ways to "trick" nmap fingerprinting but is not an easy task.
Nmap sends a series of TCP and UDP packets to the remote host and examines practically every bit in the responses. After performing dozens of tests such as TCP ISN sampling, TCP options support and ordering, IP ID sampling, and the initial window size check, Nmap compares the results to its nmap-os-db database of more than 2,600 known OS fingerprints and prints out the OS details if there is a match.
You can mock some tools detection spoofing the banner or signature. But if you want to mock the OS fingerprinting is not an easy task. You must have a pretty comprehensive set of TCP frame sizes, keepalive functionality, packet number sequences, service banners, etc. Is a though task.
Methods to defeat Nmap OS Fingerprinting in Linux are written as kernel modules, or at least, as patches to the Linux kernel.
Look at the nmap documentation about this topic.
Related
Ubuntu 16.04 server, proxy raised on the server (3proxy). When connected via a proxy with macbook, OS Fingerprint is defined as Linux 3.11 and never [fuzzy] (http://witch.valdikss.org.ru/)
At the moment, using non-complex manipulations with the /etc/sysctl.conf kernel settings, it turns out to change to Android (Linux 2.2.x-3.x [generic] [fuzzy]) and Windows NT.
Need to change the OS Fingerprint, so that http://witch.valdikss.org.ru/ defines the connection as Mac OS X [generic] [fuzzy]
According to p0f README "one of the most valuable TCP fingerprinting signal" is TCP options layout. Applied to MacOS and Linux fingerprint entries this means we should change layout from:
mss,sok,ts,nop,ws
to
mss,nop,ws,nop,nop,ts,sok,eol+1
This cannot be done by sysctl since Linux kernel hardcode this order into tcp_connect syscall: https://github.com/torvalds/linux/blob/bab5c80b211035739997ebd361a679fa85b39465/net/ipv4/tcp_output.c#L458
So you must write netfilter kernel module to mangle TCP options later like TCPMSS module does:
https://github.com/torvalds/linux/blob/master/net/netfilter/xt_TCPMSS.c.
Either patching tcp_connect or writing custom netfilter module requires strong kernel programming skills.
Another option is to somehow intercept TCP SYN/SYN+ACK packets by user-space program (maybe nfqueue or tproxy with raw sockets can help), mangle it and write back to kernel. This can significantly hurt performance but easier to implement.
UPD: I've googled some working and dirty example of this technique based on nfqueue/python: https://forums.hak5.org/topic/33532-p0f-mangler/
I am working with the Xilinx distribution of Linux on a Zynq 7000 board. This has two ARM processors, some L2 cache, a DRAM interface, and a large amount of FPGA fabric. Our appliance collects data being processed by the FPGA and then sends it over the gigabit network to other systems.
One of the services we need to support on this appliance is SNMP, which relies on UDP datagrams, and although SNMP does have TCP support, we cannot force the clients to use that.
What I am finding is that this system is losing almost all SNMP requests.
It is important to note that neither the network nor the CPUs are being overloaded. The data rate isn't particularly high, and the CPUs are usually somewhere around 30% load. Plus, we're using SNMP++ and Agent++ libraries for SNMP, so we have control over those, so it's not a problem with a system daemon breaking. However, if we do stop the processing and network activity, SNMP requests are not lost. SNMP is being handled in its own thread, and we've made sure to keep requests rare and spread-out so that there really should be no more than one request buffered at any one time. With the low CPU load, there should be no problem context-switching to the receiving process to service the request.
Since it's not a CPU or ethernet bandwidth problem, my best guess is that the problem lies in the Linux kernel. Despite the low network load, I'm guessing that there are limited network stack buffers being overfilled, and this is why it's dropping UDP datagrams.
When googling this, I find examples of how to use netstat to report lost packets, but that doesn't seem to work on this system, because there is no "-s" option. How can I monitor these packet drops? How can I diagnose the cause? How can I tune kernel parameters to minimize this loss?
Thanks!
Wireshark or tcpdump is a good approach.
You may want to take a look at the settings in /proc/sys/net/ipv4/ or try an older kernel (3.x instead of 4.x). We had an issue with tcp connections on the Zynq with the 4.4 kernel but this could be seen in the system logs (A warning regarding SYN cookies and possible flooding).
is there any way to check on which point (on which router) port (e.g. 22 - ssh) is blocked. In other words I'm looking for something like ping / traceroute to specified port.
See NMAP:
Nmap ("Network Mapper") is a free and open source (license) utility for network discovery and security auditing. Many systems and network administrators also find it useful for tasks such as network inventory, managing service upgrade schedules, and monitoring host or service uptime. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics. It was designed to rapidly scan large networks, but works fine against single hosts. Nmap runs on all major computer operating systems, and official binary packages are available for Linux, Windows, and Mac OS X. In addition to the classic command-line Nmap executable, the Nmap suite includes an advanced GUI and results viewer (Zenmap), a flexible data transfer, redirection, and debugging tool (Ncat), a utility for comparing scan results (Ndiff), and a packet generation and response analysis tool (Nping).
http://nmap.org/
I have the following requirment,
I have a Linux PC connected directly to an embedded board.
The Linux PC receives IP traffic from the Internet - it needs to forward this to the embedded board. However the embedded board does not have ability to reassemble IP fragments. Currently what we do is receive the reassembled packet in the linux pc and then sendto() to the emmbeded board. However given the high load of traffic this consumes too much CPU cycles in the Linux PC - since this invovles a copy from kernel space to user space and again the same packet is copied from user space to kernel space.
Is there a way for the kernel to reassemble the fragements and IP forward it to the embedded board without the packet having to come to user space? Note: I have the flexibility to make the destination IP of the IP packets as either the Linux PC or the embedded board.
Thanks
Broadly speaking, no this is not built into the kernel, particularly if your reassembled packet exceeds the MTU size and therefore cannot be transmitted to your embedded board. If you wanted to do it, I'd suggest routing via a tun device and reassembling in user space, or (if you are just using tcp) using any old tcp proxy. If written efficiently it's hard to see why a linux PC would not be able to keep up with this if the embedded board can manage to process the output. If you insist on using the kernel, I think there is a tcp splice technique (see kernel-based (Linux) data relay between two TCP sockets) though whether that works at a segment level and thus does not reassemble, I don't know.
However, do you really need it? See:
http://en.wikipedia.org/wiki/Path_MTU_Discovery
Here tcp sessions are sent with the DF bit set precisely so no fragmentation occurs. This means that most such tcp sessions won't actually need to support fragmentation.
Based on the title of the question, it appears you need to perform reassembly on the intermediate node (linux device). This doesn't mean you have to do it in the kernel space.
Take a look at DPDK. It is an opensource dataplane development kit. It may sound complicated, but all it does is use Poll Mode Drivers to get packets up to the user space with out the copying and interrupt overhead.
Please not, it uses poll mode drivers and will take up CPU cycles. You can use dpdk on a x86_64 hardware if you are ready to give up a couple of cores assuming you also want to fragment the packets in the reverse path.
Take a look at the sample application guide of DPDK for packet fragmentation and reassembly.
I need to find the type of OS installed in a Remote Machine.
I know that, I can use OS Finger Printing Tools like NMap to detect the OS specific details of the Remote Machine.
But I can't use such tool, since there are some licensing issues.
I need to implement my own logic to detect OS.
On my search I have found a link that we can find the OS type based on TTL.
But using TTL is not always accurate. It is based on hop calculation.
There will be some open ports in a machine. By scanning that we can somehow manage to find the OS.
Is there any such Port which might give some idea about OS type?
I need to implement a logic to run a Script based on OS. If there are some conditions which is useful to detect the OS type then It might save some time.
if(IsOpen(Some_Port_Number))
{
//This machine might be a windows based one so
if(Run_WindowsBasedScript()==False)
{
Run_LinuxBasedScript();
}
}
else
{
if(Run_LinuxBasedScript()==False)
{
Run_WindowsBasedScript();
}
}
So I need to reduce the run time by identifying the OS type.I thought based on open ports we can find OS. Any Help would be appreciated.
There is not "just one port" you can scan to determine the OS. If you can't use NMAP you'll need to emulate it's mechanism to detect the OS.
Of course you could get lucky with a telnet command (on port 23) giving you the operating system back or a curl -I microsoft.com giving you the web-server Microsoft-IIS/7.5 (classical techniques) but don't count on it.
You'll need to use complicated techniques. You can read in this old article about some of the techniques. There are also some mention of others who use different techniques.
First you need to find out which family the machine belongs to. (You already mentioned the TTL-method) After that you can read in the article above what steps you can take to determine versions.
Another fact is that NMAP uses not just one port, but is best effective if there is at least one open and one closed TCP port found. (It says so when it doesn't find them) So it also determines the OS by combinations of ports found open and closed.
For some further reading:
Chapter 8. Remote OS Detection
OS Detection on Wikipedia
From the other side :) Intrusion Detection Level Analysis of Nmap and Queso