We are running our java application on RHEL 8.5 OS platform. We are using the Apache 2.4.35 version. And we made the changes in ssl.conf file like below,
SSLProtocol -ALL +TLSv1.2
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:AES256-CCM:DHE-RSA-AES256-CCM
We used some commands to verify whether we are using TLS1.0 and TLs1.1 protocols or not. As expected, we got positive results that both protocols are disabled. Please find the below commands which we used to verify,
1. openssl s_client -connect <IP_ADDRESS>:8443 -tls1
2. nmap -sV --script ssl-enum-ciphers -p 8443 <IP_ADDRESS>
Starting Nmap 7.70 ( https://nmap.org ) at 2022-09-20 20:02 IST
mass_dns: warning: Unable to open /etc/resolv.conf. Try using --system-dns or specify valid servers with --dns-servers
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for XXXXX (IP_ADDRESS)
Host is up (0.00067s latency).
PORT STATE SERVICE VERSION
8443/tcp open ssl/http Apache httpd
|_http-server-header: Apache
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
MAC Address: 00:50:56:A7:92:7B (VMware)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.90 seconds
But during the vulnerability scan (Nessus scan), we got that a port (4567) is using TLS1.0 version.
Please let me know how to block the TLS1.0 on that specific port?
Related
For my own sanity, does anyone know why rpcbind (linux) is opening a seemingly random port every time it's restarted? I know it uses port 111, but what is this other port that keeps opening up with it? Thanks.
[root#testmachine ~]# nmap -sU -p 0-65535 127.0.0.1
Starting Nmap 5.51 ( http://nmap.org ) at 2016-03-03 16:00 EST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000080s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
111/udp open|filtered rpcbind
819/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 3.11 seconds
[root#testmachine ~]# service rpcbind restart
Stopping rpcbind: [ OK ]
Starting rpcbind: [ OK ]
[root#testmachine ~]# nmap -sU -p 0-65535 127.0.0.1
Starting Nmap 5.51 ( http://nmap.org ) at 2016-03-03 16:00 EST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000080s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
111/udp open|filtered rpcbind
846/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 2.97 seconds
[root#testmachine ~]# service rpcbind restart
Stopping rpcbind: [ OK ]
Starting rpcbind: [ OK ]
[root#testmachine ~]# nmap -sU -p 0-65535 127.0.0.1
Starting Nmap 5.51 ( http://nmap.org ) at 2016-03-03 16:05 EST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000070s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
111/udp open|filtered rpcbind
892/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 2.86 seconds
More than likely, it's an RPC service. Try the rpcinfo command to see what it is.
Unlike most other network services (FTP, HTTP, SMTP, etc), RPC services are bound to dynamic ports. Instead of connecting directly to the server, an RPC client first sends a request to the RPC port mapper (UDP/111 by default) to find out what port the server is on (a similar is used on Windows).
On a related note, nmap is great, but there are much easier ways to learn about the listening ports on your computer. Try this instead: sudo netstat -anp | grep LISTEN. It's much faster and will even give you the process name and number.
Also, nmap 5.51 is about five years old now. If you use it often, it's worth upgrading to get some new features.
The Debian man page for rpcbind tells me that:
All RPC servers must be restarted if rpcbind is restarted.
The OP didn't mention that they'd done that, so how would any of the RPC services have reregistered? Imagine my surprise, then, on repeating the OP's experiment and applying the rpcinfo -p suggestion from #SArcher to see that all the RPC services were still registered... and on their original ports, suggesting that #SArcher wasn't quite on the money.
If, however, we also apply the other great suggestion from #SArcher, namely to sudo netstat -anp, we get something more interesting. Now we can't |grep LISTEN as suggested because the OP's post says udp and UDP sockets are never in state LISTEN. What we do find is that rpcbind doesn't just have sockets on port 111 - its job - but also another "reserved" port picked seemingly at random when rpcbind starts, just as the OP says.
So "what is this other port for?" you ask. Sorry to tease but I just answered that in my description of:
Debian bug 870579: rpcbind callit replies from a random reserved udp port, making firewalling hard
On redhat there is a separate service called rpcbind.socket. This gets started with rpcbind.service. rpcbind.service first checks if port 111 is available, if it is not available then it chooses a port and starts listening on that port.
In redhat the rpcbind.socket is started first and it startes using port 111. In netstat the port 111 will be displayed as used by systemd. When rpcbind is started it finds that port 111 is already used by systemd and hence it chooses a different port. If you mask the rpcbind.socket service and then start rpcbind.service, rpcbind will start listening on port 111.
I am running centos 5.7 with the openssl-0.9.8e-22.el5_11 and it's affected by poodle vulnerability. So to address this I have upgraded my openssl version to openssl-0.9.8e-31.el5_11.
I have confirmed like the fix for poodle vulnerability is available in the above version by using changelog.
[root]# rpm -qa --changelog openssl | grep CVE
- add support for fallback SCSV to partially mitigate CVE-2014-3566
- fix CVE-2014-0221 - recursion in DTLS code leading to DoS
- fix CVE-2014-3505 - doublefree in DTLS packet processing
- fix CVE-2014-3506 - avoid memory exhaustion in DTLS
- fix CVE-2014-3508 - fix OID handling to avoid information leak
But however, still my system is using SSLv3 as per the below test.
[root]# nmap --script ssl-enum-ciphers -p 443 10.197.65.190
Starting Nmap 5.51
Nmap scan report for 10.197.65.190
Host is up (0.00071s latency).
PORT STATE SERVICE
443/tcp open
| ssl-enum-ciphers:
| SSLv3
| Ciphers (
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_RC4_128_MD5
| TLS_RSA_WITH_RC4_128_SHA
| Compressors (1)
| uncompressed
| TLSv1.0
| Ciphers (
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_RC4_128_MD5
| TLS_RSA_WITH_RC4_128_SHA
| Compressors (1)
|_ uncompressed
Nmap done: 1 IP address (1 host up) scanned in 1.28 seconds
I am getting little bit confused here.Whether really poodle vulnerability is fixed in openssl-0.9.8e-31.el5_11.
Any help on this will be highly appreciatable.
No upgrade for openssl will fix POODLE, because POODLE is a design flaw in SSL 3.0 and not a bug in OpenSSL. All the upgrade does is to add an option which might be used be servers to detect protocol downgrade attempts of the client.
The real fix is to disable SSL 3.0 in all applications which use the OpenSSL library.
I've looked at several similar questions here, but none of them have helped me. I want to connect to a web service that uses single-sign-on via an RSA SecurID keyfob. I start by trying to load any cookies provided by the initial GET request. Here's my command:
curl -A "Mozilla/5.0" -L -b cookies.txt -c cookies.txt -v -X GET \
https://sso.example.com/sso/login.htm
I get this in response:
* About to connect() to sso.example.com port 443 (#0)
* Trying 23.12.245.199... connected
* Connected to sso.example.com (23.12.245.199) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to sso.example.com:443
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to sso.example.com:443
Here's what I'm using:
# curl --version
curl 7.19.7 (x86_64-suse-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8j zlib/1.2.7 libidn/1.10
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
# more /etc/*-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3
# uname -r
3.0.101-0.21-default
Any ideas?
This is OpenSSL in your client that has a problem to understand what the server is saying and it errors out because of that.
You can sometimes work around these kinds of issues by forcing curl to speak SSLv3 (-3), TLS1.0 (-1) or even SSLv2 (-2)
... it is also conceivable that your severely outdated versions of curl and OpenSSL simply have a bug or two that cause this and that you can fix this problem by upgrading to modern versions (and then also fix the numerous security problems your versions contain).
I am trying to connect to one of our staging Cassandra servers on port 9042 and 9160 here in our company from a dev box.. Through the code, I am not able to connect to it... The program gets hanged at my SELECT query..
So I am wondering is there any way to figure out from my dev box whether these two ports are either blocked on my Cassandra staging servers or not?
Below is the Cassandra staging server url which I am trying to connect from my dev box -
sc-host01.vip.slc.qa.host.com
And my dev box machine url is -
username-dyn-vm1-4.phx-os1.tratus.dev.host.com
Can anyone tell me how to figure out what can be the possible reason to which I am not able to connect to it..
How to check from my dev box whether these ports are opened or not on my Cassandra staging servers?
Update:-
ubuntu#username-dyn-vm1-4:~/build$ traceroute sc-host01.vip.slc.qa.host.com
traceroute to sc-host01.vip.slc.qa.host.com (10.109.107.64), 30 hops max, 60 byte packets
1 10.9.209.1 (10.9.209.1) 4.594 ms 6.628 ms 8.299 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 stgcass01-1.vip.slc.qa.host.com (10.109.107.64) 7.907 ms 3.312 ms 3.950 ms
This is what I got when I ran nmap -
ubuntu#username-dyn-vm1-4:~/build$ nmap -p T:9160 sc-host01.vip.slc.qa.host.com
Starting Nmap 6.00 ( http://nmap.org ) at 2013-10-13 20:01 UTC
Nmap scan report for sc-host01.vip.slc.qa.host.com (10.109.107.64)
Host is up (0.0037s latency).
rDNS record for 10.109.107.64: stgcass01-1.vip.slc.qa.host.com
PORT STATE SERVICE
9160/tcp open apani1
Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds
ubuntu#username-dyn-vm1-48493:~/build$ nmap -p T:9042 sc-host01.vip.slc.qa.host.com
Starting Nmap 6.00 ( http://nmap.org ) at 2013-10-13 20:02 UTC
Nmap scan report for sc-host01.vip.slc.qa.host.com (10.109.107.64)
Host is up (0.0049s latency).
rDNS record for 10.109.107.64: stgcass01-1.vip.slc.qa.host.com
PORT STATE SERVICE
9042/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
Does that mean port is opened correctly and there is no problem?
And with telnet I get this -
ubuntu#username-dyn-vm1-4:~/build$ telnet sc-host01.vip.slc.qa.host.com 9042
Trying 10.109.107.64...
Connected to stgcass01-1.vip.slc.qa.host.com.
Escape character is '^]'.
^CConnection closed by foreign host.
ubuntu#username-dyn-vm1-4:~/build$ telnet sc-host01.vip.slc.qa.host.com 9160
Trying 10.109.107.64...
Connected to stgcass01-1.vip.slc.qa.host.com.
Have you tried telnet from the dev box?
telnet sc-host01.vip.slc.qa.host.com 9042
telnet sc-host01.vip.slc.qa.host.com 9160
if you get a telnet prompt back, you have connectivity, if it hangs there the connection may be timing out, if the command fails outright you may have firewall rules preventing access. You can try 'traceroute sc-host01.vip.slc.qa.host.com' to see the path the connection is trying to take.
I have a vm in vmware workstation, it's bridged network and DHCP. The IP assigned by DHCP server is 10.21.245.22. Here is my /etc/hosts looks like:
127.0.0.1 hadoop-namenode-01 localhost
I am running command A and B on the box itself.
Command A:
root#hadoop-namenode-01:~# nmap -sT -sU -p- localhost
Starting Nmap 5.21 ( http://nmap.org ) at 2012-08-10 09:32 PDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00029s latency).
rDNS record for 127.0.0.1: hadoop-namenode-01
Not shown: 131058 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
631/tcp open ipp
8020/tcp open unknown
9000/tcp open cslistener
9001/tcp open tor-orport
50070/tcp open unknown
53/udp open|filtered domain
68/udp open|filtered dhcpc
123/udp open ntp
5353/udp open|filtered zeroconf
47982/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 12.45 seconds
Command B:
root#hadoop-namenode-01:~# nmap -sT -sU -p- 10.21.245.22
Starting Nmap 5.21 ( http://nmap.org ) at 2012-08-10 09:28 PDT
Nmap scan report for wn7x64-3jql0q1.dub.emea.dell.com (10.21.245.22)
Host is up (0.00029s latency).
Not shown: 131065 closed ports
PORT STATE SERVICE
22/tcp open ssh
68/udp open|filtered dhcpc
123/udp open ntp
5353/udp open|filtered zeroconf
47982/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 12.20 seconds
My question is :
since I have no firewall or anything like that blocking ports, why nmap shows more ports open when it's running against localhost while less ports are shown when it's running against the ip.
why nmap shows more ports open when it's running against localhost
while less ports are shown when it's running against the ip
Some applications decided to explicitly listen (bind actually) only on localhost, i.e. 127.0.0.1. You can do a netstat to check things out.
Most of system running process in Linux use loopback (127.0.0.1) ip address to communicate with each other. It doesn't require to send packet outside network.