In order to check that all the servers across a fleet aren't supporting deprecated algorithms, I'm (programmatically) doing this:
telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.0p1 Ubuntu-6build1
SSH-2.0-Censor-SSH2
4&m����&F �V��curve25519-sha256,curve25519-sha256#libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1Arsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519lchacha20-poly1305#openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.comlchacha20-poly1305#openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com�umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1�umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1none,zlib#openssh.comnone,zlib#openssh.comSSH-2.0-Censor-SSH2
Connection closed by foreign host.
Which is supposed to be a list of supported algorithms for the various phases of setting up a connection. (kex, host key, etc). Every time I run, I get a different piece of odd data at the start - always a different length.
There's an nmap plugin - ssh2-enum-algos - which returns the data in it's complete form, but I don't want to run nmap; I have a go program which opens the port, and sends the query, but it gets the same as telnet. What am I missing, and how do I fix it?
For comparison, here's the top few lines from the output of nmap script:
$ nmap --script ssh2-enum-algos super
Starting Nmap 7.80 ( https://nmap.org ) at 2019-12-27 22:15 GMT
Nmap scan report for super (192.168.50.1)
Host is up (0.0051s latency).
rDNS record for 192.168.50.1: supermaster
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
| ssh2-enum-algos:
| kex_algorithms: (12)
| curve25519-sha256
| curve25519-sha256#libssh.org
| ecdh-sha2-nistp256
| ecdh-sha2-nistp384
| ecdh-sha2-nistp521
Opening a tcp connection to port 22, (in golang, with net.Dial) then accepting and sending connection strings leaves us able to Read() from the Reader for the connection. Thence the data is in a standard format described by the RFC. From this, I can list the algorithms supported in each phase of an ssh connection. This is very useful for measuring what is being offered, rather than what the appears to be configured (it's easy to configure sshd to use a different config file).
It's a useful thing to be able to do from a security POV.
Tested on every version of ssh I can find from 1.x on a very old solaris or AIX box, to RHEL 8.1.
In some cases you can specify an algorithm to use, and if you specify one that is not supported the server will reply with a list of supported algorithms.
For example, to check for supported key exchange algorithms you can use:
ssh 127.0.0.1 -oKexAlgorithms=diffie-hellman-group1-sha1
diffie-hellman-group1-sha1 is insecure and should be missing from most modern servers. The server will probably respond with something like:
Unable to negotiate with 127.0.0.1 port 22: no matching key exchange method found. Their offer: curve25519-sha256,curve25519-sha256#libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
Exit 255
Typing: "ssh -Q cipher | cipher-auth | mac | kex | key"
will give you a list of the algorithms supported by your client
Typing: "man ssh"
will let you see what options you can specify with the -o argument, including Cipher, MACs, and KexAlgorithms
I'm using WFPSampler to redirect all traffic to a specific interface by using command:
WFPSampler.exe -s PROXY -l FWPM_LAYER_ALE_BIND_REDIRECT_V4 -pla 10.0.2.15 -v -in
This works just fine, traffic from all of the processes is redirected as expected. The only problem is that it binds 127.0.0.1 to 10.0.2.15 as well and then some applications fail to connect.
For example, I've created simple Python HTTP server on 127.0.0.1:8000 and I can not access it over the browser using this address.
I know that on FWPM_LAYER_ALE_BIND_REDIRECT_V4 it is only possible to filter by local address, but I have somehow to filter by remote address at this point to avoid binding localhost to 10.0.2.15
You could redirect the outgoing traffic from 10.0.2.15 to 127.0.0.1 at the same time, with the command like:
WFPSampler.exe -s PROXY -l FWPM_LAYER_ALE_CONNECT_REDIRECT_V4 -ipra 10.0.2.15 -pra 127.0.0.1 -v -in
The comments of this answer has metioned it.
I am trying to ping a hostname "win-2k12r2-addc.阿伯测阿伯测ad.hai.com" from a linux client.
I see that DNS requests go over the wire with hostname being sent in utf-8 format
and i get a response from the DNS server also with the correct IP address.
But ping fails with the following error :
ping: unknown host win-2k12r2-addc.阿伯测阿伯测ad.hai.com
If i add an entry into /etc/hosts, it works fine
I have the following entries in /etc/hosts when it works.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
127.0.0.1 localhost ava-dev
::1 localhost
10.141.33.93 win-2k12r2-addc.阿伯测阿伯测ad.hai.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The /etc/nsswitch.conf file has the following entries for hosts.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
hosts: files dns
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I somewhat suspect that getaddrInfo() call fails when we try to resolve the address i.e it is not able to handle the DNS responses correctly for hostnames
containing unicode characters.
Has anyone faced this issue before ?
Or has anyone tried resolving a unicode hostname from a linux client ?
The reason i m suspecting getaddrinfo() is because of the following.
Apart from ping, i m trying the following ldap command to the same host and it fails with the below mentioned error
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ldapsearch -d 255 -x -h win-2k12r2-addc.阿伯测阿伯测ad.hai.com
ldap_create
ldap_url_parse_ext(ldap://win-2k12r2-addc.%E9%98%BF%E4%BC%AF%E6%B5%8B%E9%98%BF%E4%BC%AF%E6%B5%8Bad.hai.com)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP win-2k12r2-addc.阿伯测阿伯测ad.hai.com:389
ldap_connect_to_host: getaddrinfo failed: Name or service not known
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In both the scenarios (ping / ldap), i see the DNS query request going to the DNS server and the correct response from the DNS server back to the linux client.
The following is the value of the hostname sent in the DNS query
win-2k12r2-addc.\351\230\277\344\274\257\346\265\213\351\230\277\344\274\257\346\265\213ad.hai.com: type A, class IN
It looks like you are trying to use UTF-8 or unicode within the DNS system while the DNS system really doesn't like that. It wants ascii (See RFCs 5890, 5891, 5892, 5893 - but mostly 5891). Escaping the utf-8 characters does not turn them into the required ascii encoding, called punycode (prefixed by "xn--"). You want to use the version of your IDN that has punycode instead of the UTF-8:
ping win-2k12r2-addc.xn--ad-tl3ca3569aba8944eca.hai.com
On Windows Does anyone know why "netstat -an -p tcp" doesn't display IPv6 addresses, but why "netstat -an" does display them?
I highly doubt it's resolving IPv6 addresses to IPv4s, but this is puzzlibg the hell out of me.
From netstat /? in console (or [MS.Docs]: Netstat):
-p proto Shows connections for the protocol specified by proto; proto
may be any of: TCP, UDP, TCPv6, or UDPv6. If used with the -s
option to display per-protocol statistics, proto may be any of:
IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6.
So, when specifying -p tcp, it only displays the TCPv4 connections (by filtering out all the rest), while not specifying any protocol, it displays them all (doesn't filter anything).
I'm trying to get dnsmasq to push multiple search prefixes to windows machines. If I look in the MS dhcp server, it looks to be using dhcp option 135, but any attempt to configure that eg
dhcp-option=135,domain.local1,domain.local2
doesnt get pushed at all (I'm using tcpdump -i br0 -lenx -s 1500 port bootps or port bootpc | dhcpdump to view wat dnsmasq is sending)
I have minor success using dhcp option 15, but it only pushes a single name into the search prefix as displayed by ipconfig /all on windows
Any suggestions ?
Checking the ISC dhcp option list I found this:
119 Domain Search domain-search
One or more domain names, each enclosed in quotes and separated by commas
But note that dnsmasq actually provides you special option (although I'm not sure from which version it starts)
dhcp-option=option:domain-search,eng.apple.com,marketing.apple.com
Our client machines (Ubuntu 18 server using netplan/systemd-resolve) were not requesting DHCP option 119, but I could solve the problem by forcing the server (dnsmasq) to sentd that option in the reply anyway:
dhcp-option-force=option:domain-search,internal,maindomain.com
dhcp-option=option:domain-name,maindomain.com
Using the dhcp-option-force parameter makes sure that the list is sent to the clients regardless of what they ask for.