0

I'm running a personal ssh server on a nonstandard port. If someone tries to log into my ssh server thru the standard port 22, it seems that the server sends "Connection refused" message.

$ ssh localhost
ssh: connect to host localhost port 22: Connection refused

How can I make it so that it doesn't send such message and it behaves like it's not running?

drAlberT
  • 10,871
  • 7
  • 38
  • 52
RamyenHead
  • 311
  • 3
  • 6
  • 11

5 Answers5

7

You've already done it -- the connection refused response is sent by the operating system when an attempt is made to connect to a port which doesn't have anything listening on it.

Stephen Veiss
  • 486
  • 2
  • 6
7

The server is not sending anything, it's the client telling you the server refused the connection. That's the expected behaviour if a TCP port is closed when you try to connect.

If you want your system to silently drop packets without sending a "this port is closed" TCP answer (a so-called stealth port), you need to use a firewall on the system and/or in between it and the client.

Massimo
  • 68,714
  • 56
  • 196
  • 319
  • 5
    This is not correct! The server network stack is sending packets. When a client program sends a TCP SYN packet to request a connection, a reply packet with the ACK and RST flags set, according to examination of captured packets, is classified as a connection refused error. No server is listening on the port, and the port is closed as you said correctly. – drAlberT Sep 01 '09 at 08:32
  • 1
    I was meaning that "connection refused" message was not sent by the server, as the original poster thought; it was the client application stating that the server had refused the connection. I think those three downvotes were a bit too much. – Massimo Sep 01 '09 at 13:29
3

What you see is most likely your client's reaction to an ICMP port-unreachable sent by the server upon receiving the first TCP SYN-packet for a port that does not accept connections. This is correct behavior and allows the client to quickly tell you so.

If you actually mean stealth as in "this host is non-existing, dead or offline and doesn't send anything at all", configure your firewall to drop (as opposed to reject) any packets to this port. Assuming netfilter/iptables:

iptables -I INPUT -p tcp --dport 22 -j DROP

This leads to the client hanging for a while as it cannot decide if a response is in transit or non-existant.

Note: This will actually kill all connections instantly, including the running ones. Molly switch alert!

Paul
  • 1,890
  • 3
  • 18
  • 24
3

The server network stack is sending packets in response to the client TCP connect attempt.

When a client program sends a TCP SYN packet to request a connection, a reply packet with the ACK and RST flags set, according to examination of captured packets, is classified as a connection refused error. No service is listening on the port, and the port is closed.

  • if you want a "stealth" port my suggestion is to do nothing, as this is the expected behavior of a closed port with no service behind.
  • if you would DROP packets on this port you will have a "filtered" port at nmap scan, making an attacker to think that a service is listening and a firewall is denying access to him

  • furthermore DROP is not a "polite target", as it makes the net obscure to clients. DROP should be used with care.

  • if you really want a port to be a nice attacker enemy you could be interested in the tarpit iptables module

  • if you want to disorient your attacker you can join the REJECT target and play with exotics combination of ICMP error codes and --reject-type:

REJECT
--reject-with type
The type given can be
icmp-net-unreachable
icmp-host-unreachable
icmp-port-unreachable
icmp-proto-unreachable
icmp-net-prohibited
icmp-host-prohibited or
icmp-admin-prohibited

drAlberT
  • 10,871
  • 7
  • 38
  • 52
1

You can completely stealth your ssh port with fwknop in conjunction with setting a default deny policy in iptables to silently drop packets. All nmap will see are the public services.

With fwknop deployed, anyone using nmap to look for SSHD can't even tell that it is listening - it makes no difference if they want to run a password cracker against SSHD or even if they have a 0-day exploit.

See my guide for fwknop & the accompanying pages for secure ssh ciphers.

Stuart Cardall
  • 531
  • 4
  • 7