I have two CentOS servers running SSH on two different non-standard ports. So far as I can tell, they have identical /etc/ssh/sshd_config files with the exception of the different port (both are 22xx). However, when running nmap on them, one betrays the port that SSH is running on, and the other does not. I have shut down iptables on both machines and the behaviour remains this way. What could be the cause? Specifically, how can I hide the port that SSH is running on?
I'm sorry that I cannot provide the IP addresses, the owner of the servers doesn't want that! I also know how silly it is to do "stealth" ports but I'm not the one making the decision!
Thanks!
On 10/11/2010 04:21 PM, Dotan Cohen wrote:
However, when running nmap on them, one betrays the port that SSH is running on, and the other does not. I have shut down iptables on both machines and the behaviour remains this way. What could be the cause?
You're probably not running a full port scan with nmap. One of the systems is using a port that nmap includes in its quick scan set, and the other does not.
Specifically, how can I hide the port that SSH is running on?
You can't. If that port is open, a full nmap scan will reveal it.
However, when running nmap on them, one betrays the port that SSH is running on, and the other does not.
What does betray mean?
I have shut down iptables on both machines and the behaviour remains this way. What could be the cause?
Public facing machines w/ iptables off?
Specifically, how can I hide the port that SSH is running on?
So if you want it hidden, you want it not to accept connections from other machines? #iptables -L
See what's allowed, then if you're not iptable savvy, install/run system-config-security. Then do not permit connections to that port, unless you provide more info, like do you Have internal trusted interfaces etc, you will be locked out.
I'm sorry that I cannot provide the IP addresses, the owner of the servers doesn't want that! I also know how silly it is to do "stealth" ports but I'm not the one making the decision!
Probably good thing you haven't exposed a possibly bad config.
On 10/11/2010 7:44 PM, Joseph L. Casale wrote:
Specifically, how can I hide the port that SSH is running on? I'm sorry that I cannot provide the IP addresses, the owner of the servers doesn't want that! I also know how silly it is to do "stealth" ports but I'm not the one making the decision!
One method to obscure the presence of the ssh daemon would be to use port knocking:
http://dotancohen.com/howto/portknocking.html
Honestly (and this is mere opinion), the other person (who wants to hide ssh-the owner) is being paranoid. Use strong passwords, run ssh on an alternate port, don't expose unneeded services to the outside world, and install something like fail2ban to block ssh attackers.
If they need higher security then set up openvpn.
2010/10/12 Ryan Manikowski jeenam@gmail.com:
On 10/11/2010 7:44 PM, Joseph L. Casale wrote:
Specifically, how can I hide the port that SSH is running on? I'm sorry that I cannot provide the IP addresses, the owner of the servers doesn't want that! I also know how silly it is to do "stealth" ports but I'm not the one making the decision!
One method to obscure the presence of the ssh daemon would be to use port knocking:
http://dotancohen.com/howto/portknocking.html
Honestly (and this is mere opinion), the other person (who wants to hide ssh-the owner) is being paranoid. Use strong passwords, run ssh on an alternate port, don't expose unneeded services to the outside world, and install something like fail2ban to block ssh attackers.
Just disable password authentication on ssh and use only keyfiles ..
-- Eero
Ryan Manikowski wrote on 10/11/2010 07:49 PM: ...
One method to obscure the presence of the ssh daemon would be to use port knocking:
Somehow I suspect the OP may have seen that one. :-D
Phil
On Tuesday, October 12, 2010 06:56:27 pm Phil Schaffner wrote:
Ryan Manikowski wrote on 10/11/2010 07:49 PM:
Somehow I suspect the OP may have seen that one. :-D
Yeah, nothing quite like being directed to a howto you wrote yourself (getting flattered and insulted at the same time!).... I can remember a few cases of that, back when I was maintaining the PostgreSQL RPM set (and its README for the rpm packaging) and would post advice to folks about the way the RPM's work, and then get private e-mail back pointing me to my own README..... and, honestly, there was once that the advice I gave in the post and the advice I gave in the README was different, and I corrected the README for the next release.
As to the ssh business, if a full nmap scan doesn't see things differently, and the ssh connections are still working properly from clients, I would have no idea how that could be accomplished on the host itself (barring an IDS), other than perhaps a hosts.allow or hosts.deny difference, assuming that's set up for sshd. The first thing I would think of otherwise is to check to make sure the selinux policy is set for the sshd to actually bind the port, but if that's the problem, ssh connections aren't going to work at all.
That is, if the ssh client can connect so can nmap, unless you're doing something proactive and IDS-like (perhaps a PacketFence in the line, or similar automatic intrusion detection mechanism activating for one server but not the other). Even a small Cisco router with the IDS feature set can do this sort of thing on a port-by-port basis, so the nmap scan might be getting blocked that way. That fact should be logged somewhere if that's the case.
With Dotan's background and experience, and the statement about iptables being turned off, I would make an educated assumption that there is another firewall somewhere to let iptables be turned off temporarily for testing; perhaps that firewall is not set up to pass both of the ports?
These days one can't assume that the network is transparent, even between switch ports (packet-level ACLs on the data plane have been available in switches for 12 years or more; I have some Cisco Catalyst 8540 hardware that does data plane ACL's in hardware, and they're that old). And with VLAN ACL's and deep inspection firewalling being available even in a transparent bridging mode (Linux Journal ran a series not long ago about a transparent bridging Linux firewall using, IIRC, OpenWRT on a Linksys) even layer 2 adjacency is no guarantee of transparency.
Then I'd look to make sure the ssh client's outgoing access is allowed on both ports (while that sounds obvious, it's time to check the obvious, it sounds like). Run the client in debug mode and see what it spits out; also use a port-configurable tcp-using traceroute equivalent on both port numbers to see where blockages might be happening.
When things get this paranoid, my experience has been that fat-fingered port numbers and/or IP addresses and/or access-list numbers or names are the typical culprits in broken connectivity. At least those have been my areas of mysterious network non-transparency, typically.
Dotan, can you share the nmap command-line you're using with the IP range sanitized?
-
Dotan Cohen -
Eero Volotinen -
Gordon Messmer -
Joseph L. Casale -
Lamar Owen -
Phil Schaffner -
Ryan Manikowski -
Sean Hart