ncat --ssl cloudflare.com 443 --- 0 bytes received - ssl

I just try to send raw HTTP request to arbitrary domains with https and found that the following command does not work for domains under Cloudflare.
$ printf 'GET / HTTP/1.1\r\nHost: cloudflare.com\r\n\r\n' | ncat -v --ssl cloudflare.com 443 > a
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: SSL connection to 104.16.132.229:443. Cloudflare, Inc.
Ncat: SHA-1 fingerprint: 3A51 2349 F9F9 7F93 DF88 48C4 2269 D35D 88EF B97B
Ncat: 40 bytes sent, 0 bytes received in 0.11 seconds.
But it works great for github.com and google.com:
$ printf 'GET / HTTP/1.1\r\nHost: github.com\r\n\r\n' | ncat -v --ssl github.com 443 > a
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: SSL connection to 140.82.121.3:443. GitHub, Inc.
Ncat: SHA-1 fingerprint: 1E16 CC3F 842F 65FC C0AB 932D 638A C64A 95C9 1B7A
Ncat: 36 bytes sent, 178023 bytes received in 0.28 seconds.
$ printf 'GET / HTTP/1.1\r\nHost: www.google.com\r\n\r\n' | ncat -v --ssl www.google.com 443 > a
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: SSL connection to 142.250.186.164:443.
Ncat: SHA-1 fingerprint: BE7B 2FFD 064B 94CD 2968 33EA DB41 8F0B 8275 5AD1
Ncat: 40 bytes sent, 50303 bytes received in 0.30 seconds.
Why there is no output for such domains? What makes them special? (curl or wget for them works fine)

Related

Exim4 GnuTLS error (gnutls_handshake): An unexpected TLS packet was received

I have Exim4-heavy, GunTLS
it was configured correctly and the mails was working fine
suddenly I not be able to use TLS however the SSL certificates is verified
when I telnet to port 465 it gives
# telnet localhost 465
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
ehlo foo
Connection closed by foreign host.
but when I telnet to port 587
# telnet localhost 587
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 box01.xxxxxxxxx.com ESMTP Exim 4.90_1 Ubuntu Wed, 29 Apr 2020 15:49:41 +0200
ehlo foo
250-box01.xxxxxxxxx.com Hello foo [127.0.0.1]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250-STARTTLS
250-PRDR
250 HELP
starttls
220 TLS go ahead
ehlo foo
Connection closed by foreign host.
I didn't update anything in the configuration and it was working before 5 days
also I got a lot of this error in log
2020-04-29 15:50:02 TLS error on connection from (foo) [127.0.0.1]:55212 I=[127.0.0.1]:587 (gnutls_handshake): An unexpected TLS packet was received.
I had the similar problems with exim4. I'll share some of the configurations i made to get it to work.
echo "IGNORE_SMTP_LINE_LENGTH_LIMIT='true'" >> /etc/exim4 exim4.conf.localmacros
echo "REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = *">> /etc/exim4/exim4.conf.localmacros
echo "REQUIRE_PROTOCOL = smtps">> /etc/exim4/exim4.conf.localmacros
echo "MAIN_HARDCODE_PRIMARY_HOSTNAME = localhost" >> /etc/exim4/exim4.conf.localmacros
echo "MAIN_TLS_ENABLE = 1">> /etc/exim4/exim4.conf.localmacros
echo "MAIN_TLS_CERTIFICATE=/opt/ssl/localhost.pem" >> /etc/exim4/exim4.conf.localmacros
echo "MAIN_TLS_PRIVATEKEY=/opt/ssl/localhost-key.pem" >> /etc/exim4/exim4.conf.localmacros
echo "daemon_smtp_ports = 25 : 465" >> etc/exim4/exim4.conf.localmacros
echo "tls_on_connect_ports = 465" >> /etc/exim4/exim4.conf.localmacros
echo "dc_other_hostnames='localhost'" >> /etc/exim4/update-exim4.conf.conf
echo "dc_eximconfig_configtype='satellite'" >> /etc/exim4/update-exim4.conf.conf
echo "dc_smarthost='localhost::465'" >> /etc/exim4/update-exim4.conf.conf
I also made sure exim is allowed to read the certificates.
chown root:Debian-exim /opt/ssl/key.pem
chown root:Debian-exim /opt/ssl/cert.pem
chmod 640 /opt/ssl/key.pem
chmod 640 /opt/ssl/cert.pem

curl does not have same result as browser

I am trying to download the following URL using from command line using curl. If the same URL is requested through the browser, it is able to fetch the image. But for curl, the server terminates the SSL handshake. Just to use exact same parameters; I tried the curl commands from 'developer tools' from google-chrome and firefox. But both fails with following error.
This question was asked before here here but there is no answer that works. I tried -http1.1 as suggested but did not work.
https://floridakeyswebcams.tv/sloppycam/camarchive/0807.jpg
(base) (15:39 test#testcomp ~) > curl -v 'https://floridakeyswebcams.tv/sloppycam/camarchive/0807.jpg' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: en-US,en;q=0.9,hi;q=0.8,mr;q=0.7' -H 'If-None-Match: "90cbf2d5a81d51:da782"' -H 'If-Modified-Since: Fri, 03 May 2019 12:07:53 GMT' --compressed
* Trying 74.209.245.140...
* TCP_NODELAY set
* Connected to floridakeyswebcams.tv (74.209.245.140) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /home/sagham/anaconda2/ssl/cacert.pem
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to floridakeyswebcams.tv:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to floridakeyswebcams.tv:443
it appears that floridakeyswebcams.tv requires TLS1.3 support, use the --tlsv1.3 argument,
curl --tlsv1.3 -v 'https://floridakeyswebcams.tv/sloppycam/camarchive/0807.jpg'
here is what i get when using --tlsv1.2:
$ ./CURL.EXE https://floridakeyswebcams.tv/sloppycam/camarchive/0807.jpg --tlsv1.2 -vv
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 74.209.245.140...
* TCP_NODELAY set
* Connected to floridakeyswebcams.tv (74.209.245.140) port 443 (#0)
* schannel: next InitializeSecurityContext failed: SEC_E_ALGORITHM_MISMATCH (0x80090331) - The client and server cannot communicate, because they do not possess a common algorit
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Closing connection 0
* schannel: shutting down SSL/TLS connection with floridakeyswebcams.tv port 443
curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ALGORITHM_MISMATCH (0x80090331) - The client and server cannot communicate, because they do not possess a common algorit
and here is (roughly, it was printed in the wrong order for some reason) what i get if i use --tlsv1.3:
./CURL.EXE https://floridakeyswebcams.tv/sloppycam/camarchive/0807.jpg --tlsv1.3 -v
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
* TCP_NODELAY set
* Connected to floridakeyswebcams.tv (74.209.245.140) port 443 (#0)
> GET /sloppycam/camarchive/0807.jpg HTTP/1.1
> Host: floridakeyswebcams.tv
> User-Agent: curl/7.64.1
> Accept: */*
>
▒▒▒▒
\▒.▒:\▒.▒:▒▒
▒▒
%&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
-truncated jpg binary-
question still remains about why this wasn't auto-negotiated tho, i'm not sure but i guess your TLS backend doesn't support tlv1.3, and that probably has something to do with why you just got a cryptic error..

Access my AWS EC2 server index.html from external browser

I've been setting up an AWS EC2 server this week, and I'm almost there with what I want to do. But opening up as a web server is proving to be a stumbling block.
MY SETUP
I have an AWS EC2 instance running Red Hat EL7.
I have an Apache server running on my instance:
[ec2-user#ip-172-xx-xx-xx ~]$ ps -ef | grep -i httpd
root 18162 1 0 18:02 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 18163 18162 0 18:02 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 18164 18162 0 18:02 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 18165 18162 0 18:02 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 18166 18162 0 18:02 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 18167 18162 0 18:02 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
ec2-user 21345 20507 0 19:03 pts/1 00:00:00 grep --color=auto -i httpd
It seems to be listening on port 80:
[root#ip-172-xx-xx-xx ~]# netstat -lntp | grep 80
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 18162/httpd
I added inbound rules to the "launch-wizard-1" security group (which is shown as the security group for the instance) for port 80 (HTTP) and 443 (HTTPS) with sources of "0.0.0.0/0" and "::/0"
And finally, for testing my setup, I created an index.html file in my document root (/var/www/html):
<html>
<h1>TEST!</h1>
</html>
THE PROBLEM
From my chrome browser on my computer, when I try to hit:
http://ec2-18-xxx-xxx-xx.us-east-2.compute.amazonaws.com/index.html
I just get:
This page isn’t working
ec2-18-xxx-xxx-xx.us-east-2.compute.amazonaws.com didn’t send any data.
ERR_EMPTY_RESPONSE
(I get the same when I hit one of my domain names which I've set up on there, which is what I'm really trying to do of course!)
I've tried connecting from Chrome on 2 different computers, and from Safari on my phone ("Safari cannot open the page because it could not connect to the server")
CHECKS I'VE PERFORMED
I don't believe I have any server firewall preventing this:
[root#ip-xx-xx-xx-xx conf]# /sbin/iptables -L -v -n
Chain INPUT (policy ACCEPT 3575 packets, 275K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 2215 packets, 350K bytes)
pkts bytes target prot opt in out source destination
Testing with telnet from a terminal session on my mac, port 80 appears to be open. Firstly using the IPv2 Public IP:
telnet 18.xxx.xxx.xx 80
Trying 18.xxx.xxx.xx...
Connected to ec2-18-xxx-xxx-xx.us-east-2.compute.amazonaws.com.
Escape character is '^]'.
Connection closed by foreign host.
and using the Public DNS (IPv4):
telnet ec2-18-xxx-xxx-xx.us-east-2.compute.amazonaws.com 80
Trying 18.xxx.xxx.xx...
Connected to ec2-18-xxx-xxx-xx.us-east-2.compute.amazonaws.com.
Escape character is '^]'.
Connection closed by foreign host.
And again, the same goes for my domain names - telnet to port 80 shows "Connected".
- Is the fact that the "foreign host" closes the connection immediately significant? Should it stay open if everything is working as it should?
Running curl on the host correctly returns my simple index.html file:
[ec2-user#ip-172-xx-xx-xx ~]$ curl localhost
<html>
<h1>TEST!</h1>
</html>
However, running a curl on my local computer - to the server - returns:
curl -v http://ec2-18-xxx-xxx-xx.us-east-2.compute.amazonaws.com:80
* Rebuilt URL to: http://ec2-18-xxx-xxx-xx.us-east-2.compute.amazonaws.com:80/
* Trying 18.xxx.xxx.xx...
* Connected to ec2-18-xxx-xxx-xx.us-east-2.compute.amazonaws.com (18.xxx.xxx.xx) port 80 (#0)
> GET / HTTP/1.1
> Host: ec2-18-xxx-xxx-xx.us-east-2.compute.amazonaws.com
> User-Agent: curl/7.43.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host ec2-18-xxx-xxx-xx.us-east-2.compute.amazonaws.com left intact
curl: (52) Empty reply from server
I also tested the webserver "internally" by running google chrome (headless) on the server to create a screenshot, downloaded to my local computer and it shows TEST! (i.e. its working):
google-chrome-stable --headless --disable-gpu --screenshot http://localhost
One more thing to add - when I attempt the hit the webserver from my local machine, nothing shows in the webserver logs (error_log or access_log) on the server.
So, my opinion is that the web server is up and running, works locally, but is not working correctly for anything coming from "outside". I'm stumped now though.
Doh! I rebooted the instance and.. all working now!
22 years working with computers and it took me 22 hrs to resort to a reboot. Fool!
Connect to your EC2 instance using ssh on terminal
Install python if not installed
Start a python server using nohup to continuously use the server
nohup python -m http.server &
This usually open port 8000, goto EC2 Security Group Make source anywhere or as needed.
Navigate to the folder having index.html, file path will look like below
http://ec2---.compute-1.amazonaws.com:8000/folder/website/
You will be able to develop and see your changes as needed.

Nagios CHECK_NRPE Could not complete SSL handshake

I checked all over, there are many answers to this issue, but none worked.
I am following this tutorial:
https://www.digitalocean.com/community/tutorials/how-to-install-nagios-4-and-monitor-your-servers-on-ubuntu-16-04
The Nagios host is ubuntu 16.04, the client is ubuntu 18.04
Nagios® Core™ 4.3.4
The Nagios server and web is running ok, I can see the localhost status us 'up' in the dashboard.
Something very weird: I installed NRPE 3.2.1 on both the host and the client, but for some reason on the host is 2.15
Host:
root#nagios-1:/tmp/nrpe-nrpe-3.2.1# /usr/local/nagios/libexec/check_nrpe -H 10.142.0.50
NRPE v2.15
Client:
$ /usr/local/nagios/libexec/check_nrpe -H 127.0.0.1
NRPE v3.2.1
Just to make sure, when running check_nrpe from client to server I am using '-2' option to force v2 packets, but I am still getting to error
I added the client ip to the nrpe.cnf (on server), and to be sure also the server ip to the client nrpe.cfg file.
I enabled debug to see the messages in the syslog. this is the response:
Dec 4 00:35:47 nagios-1 check_nrpe: Remote 10.142.0.50 accepted a Version 2 Packet
Dec 4 00:35:51 nagios-1 nrpe[9953]: Connection from 10.142.0.11 port 49889
Dec 4 00:35:51 nagios-1 nrpe[9953]: Host address is in allowed_hosts
Dec 4 00:35:51 nagios-1 nrpe[9953]: Handling the connection...
Dec 4 00:35:51 nagios-1 nrpe[9953]: Error: Could not complete SSL handshake. 1
Dec 4 00:35:51 nagios-1 nrpe[9953]: Connection from closed.
On the host, port 5666 is open and listening
# netstat -at | grep nrpe
tcp 0 0 *:nrpe *:* LISTEN
tcp6 0 0 [::]:nrpe [::]:* LISTEN
I compiled nrpe with --
I am not using xinetd. I use the daemon
# ps aux | grep nrpe
nagios 9866 0.0 0.1 23960 2680 ? Ss 00:35 0:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
Host nrpe conf file:
# grep -o '^[^#]*' /etc/nagios/nrpe.cfg
log_facility=daemon
pid_file=/var/run/nagios/nrpe.pid
server_port=5666
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts=127.0.0.1, 10.142.0.50, 10.142.0.0/20,10.142.0.11
dont_blame_nrpe=1
allow_bash_command_substitution=0
debug=1
command_timeout=60
connection_timeout=300
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200
include=/etc/nagios/nrpe_local.cfg
include_dir=/etc/nagios/nrpe.d/
If you need more info let me know and I will add it.
I found the answer!
I had two versions of NRPE on the host. The deamon was running 2.15. I had to kill this version, and I manually run the 3.2.1 version from its other location
/usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -f
After that I was able to get a response in the client

ssh-keyscan fails for ipv6 addresses

I can't get ssh-keyscan to work for ipv6 addresses. Can someone help me?
$ ssh-keyscan -6v -t rsa FE80:0000:021B:21FF:FEDA:62AD
getaddrinfo FE80:0000:021B:21FF:FEDA:62AD: Name or service not known
$ ssh-keyscan -6v -t rsa [FE80:0000:021B:21FF:FEDA:62AD]
getaddrinfo [FE80:0000:021B:21FF:FEDA:62AD]: Name or service not known
but this works:
$ ping6 -I bond0 fe80::21b:21ff:feda:62ad
PING fe80::21b:21ff:feda:62ad(fe80::21b:21ff:feda:62ad) from fe80::21b:21ff:feda:64a9 bond0: 56 data bytes
64 bytes from fe80::21b:21ff:feda:62ad: icmp_seq=1 ttl=64 time=0.571 ms
64 bytes from fe80::21b:21ff:feda:62ad: icmp_seq=2 ttl=64 time=0.165 ms
64 bytes from fe80::21b:21ff:feda:62ad: icmp_seq=3 ttl=64 time=0.145 ms
^C
--- fe80::21b:21ff:feda:62ad ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2206ms
rtt min/avg/max/mdev = 0.145/0.293/0.571/0.197 ms
You specified a link-local IPv6 address but forgot the scope. Add the scope ID to it.
You also are missing some octets in the address as you originally gave it.
Correct both of these problems:
ssh-keyscan -6v -t rsa FE80::021B:21FF:FEDA:62AD%bond0