After a small amount of research it seems that TCP MD5 Signatures are enabled on CentOS, but our PCI security software has indicated that our machines are not actually using it. How do I configure CentOS to use TCP MD5 Signatures?
Edit:
I was thinking that this was a global setting, but it is actually a per-socket setting. This means the application that is creating the socket (in this case Sun Application Server) has to be the one to specify this option.
TCP-MD5 is part of the Linux kernel; you will only have the capability if your kernel is compiled with the option enabled (you may be able to dump /proc/config.gz and if so, grep for CONFIG_TCP_MD5SIG) - the second part is an application that will actually perform the setsockopt() to enable TCP_MD5 for that connection.
If CentOS is anything like RHEL, the kernel config should be under /boot.
grep TCP_MD5 /boot/config-*
Otherwise, yes, it's a somewhat undocumented option to setsockopt().
Perhaps you are referring to TCP SYN cookies. To enable them:
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
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 have installed the multipath TCP connection and have 2 interfaces active in my pc. H want to see the mptcp connection working on my device. How do I check that subflows are actually created ?
I tried to connect with multipath-tcp.org and used iperf to check if infact subflows were created but I could see only a single entry in its result. I have seen the related questions, but they don't answer my question i.e. how exactly could i see the subflows in action.
You must connect to a mptcp enabled server to have subflows created otherwise mptcp just falls back to normal tcp. Also, you have to configure the kernel at runtime (you can select fullmesh option) as mentioned in the official website. And, obviolusly, you must have at least 2 interfaces active.
Then tools like iptraf, ifstat can be used to monitor bandwidth in/out.
I found this to be helpful.
1) Open two CLI at Linux environment;
2) Set Wireshark on for capture your packets:
Use option to filter TCP connections, that's make it easy to understand the TCP behavior.
3) Use first CLI to porform iperf as server (iperf -s) and the second to perform as client (iperf -c 127.0.0.1)
After all, you can check the subflows in the Wireshark. Further, you can explore it deeper :)
I have an embeeded system that I like to add zeroconf to it. The aim is:
Auto assign an IP to itself if there is no dhcp available.
It respond to mdns request and identify itself correctly.
It responds to dns-ds and broadcast its capability correctly.
Is there any library that can help me on this?
I found Avahi (http://avahi.org/) but it seems there is no development on it for some years. Is it still a good solution?
My device has Linux 2.x on it.
Avahi seems to be the de-facto standard implementation of Zeroconf for Linux and it is used pretty much everywhere. The last release is from 2012 but this does not mean it is dead -- it may just mean that it is mature and stable enough and there has been no need for additional releases yet.
Is it safe to assume that the loopback network adapter on a Linux system will always be called 'lo' - is this just a naming convention that may not be adhered to, or must it always be the case?
I don't know of any Linux system that has a loopback interface anything other than lo. I would rely on this naming convention, if I write a system-specific script, but not when writing a portable program. For example loopback in OSX is lo0.
A reliable way in C is calling a SIOCGIFCONF ioctl on a socket, iterating over the interfaces, calling SIOCGIFFLAGS ioctl on each one, and checking which interfaces have a IFF_LOOPBACK flag set (see /usr/include/linux/if.h).
SIOCGIFCONF will also give you interface names.
In my experience it is a common name, although you shouldn't always trust in it being so. Maybe enumerating the interfaces and looking for the one with an address of 127.0.0.1 would be the way to go?
It's a pretty old convention, in fact I have not seen a Linux box/distro yet that didn't call it 'lo'.
However, device names in *nix systems are so diverse it can be assumed they will change. Use the standards if you want portability (in this case, 127.0.0.1).
Interfaces can be renamed to anything you want - but anyone who renames the loopback interface is being extremely silly and deserves to have a nonworking system :)
Yes, you can enumerate the interfaces, and get their names. But perhaps it's just as easy to just assume it's going to be "lo".
Using 127.0.0.1 is probably the failsafe way to go about it.
RFC3330 defines 127.0.0.0/8 to always be the loopback subnet.
The use of localhost however, defined on Windows in c:\windows\system32\drivers\etc\hosts and Linux in /etc/hosts is purely convention. Furthermore the name lo is the typical name given to the localhost interface in Linux.
If you must be absolutely certain, use 127.0.0.1.
I need to store persistent reference to third party device on an arbitrary IP network where the IP address of the devices may be static or randomly assigned by DHCP. I don't control the devices on the network and I can't rely on DNS and other ad-hoc networking protocols existing or working with the devices.
So I have been instructed to investigate using hardware addresses and ARP. This will work but I don't want to duplicate code. The kernel must manage an ARP table. On Windows you can access it using GetIpNetTable etc.
I am hoping there is an API to answer these two questions:
How do I translate from IP to MAC address? (ARP)
How do I translate from MAC to IP address? (InARP)
If not then I may have to do it more manually:
How do I read the kernel's ARP table?
How do I add an entry if I have the determined a mapping myself?
/proc/net/arp
K
ARP tables tend to be fairly local and short-lived. If you examine the protocol, the real MAC addresses are generally only provided when the given IP address is in the local subnet.
Otherwise, the packet is forwarded to the local router, which is then responsible for forwarding it.
If you do "arp -g" on Windows or "arp -a" on UNIX, you'll see the table, but I don't think it will do you any good, due to the reasons mentioned above. That command and
That's really what DNS is for but, as you say, it may not be an option for you.
You may well have to write your own 'ARP' database at your application level.
As for ARP:
You could use system("/usr/bin/arp -option_of_choice"); and parse the output, but that's an ugly hack. -- Not my recommendation.
Take a look at /usr/include/linux/sockios.h -- At the SIOCGARP, SIOCDARP, and SIOCSARP details. Those are ioctls that you can perform to manage the ARP table on linux. Of course, you'll have to perform these ioctls on a socket fd.
Here's some examples: SIOCGARP examples
I'm sure you can find many other examples in several other languages as well. As I'm assuming that you're using C.
As for RARP:
A quote from the linux rarp manpage:
" This program is obsolete. From version 2.3, the Linux kernel no longer
contains RARP support. For a replacement RARP daemon, see ftp://ftp.demen-
tia.org/pub/net-tools"
So you'll have to install rarpd on the target system.