Is there a practical way to find an open port?

[root]

In a previous thread I learned how to create a port-forward
on a remote machine so that I could ssh into that machine.

I have done what I can to ensure that even if someone
knew what port is open they would not be able to pry
into the machine.

Nevertheless, I am trying to assess how difficult it would
be for an intruder who does not know the open port. For
example, if I had created an open port 22363 on the remote
machine, I know that I can use telnet to verify the
port is open:

telnet remote-host 22263

Which connects if the port is open and hangs otherwise.

I want to know how an intruder can:
1. select a particular remote-host for attention
2. given that host, find one or more of the 65,000 ports
that may give access.

I have tried nmap which seems only to scan the first 1024
ports. As I read man nmap I tried a number of things
like -PU or -PY with no success.

I tried:
nc -z remote-host 22260-22265
but even when the port range includes the open port the
command hangs.

There are many ways to probe ports when I am logged
into the machine, but this isn't what I want. I
want to pretend to be an intruder and see how much
trouble it would be to even find an opening.

If you know such a way, but fear that revealing this
information might turn me into a cracker: I am pretty
sure those bent on the crime already know how to do it.

Thanks for any help.

[J.O. Aho]

On 21/05/13 16:24, root wrote:
> In a previous thread I learned how to create a port-forward
> on a remote machine so that I could ssh into that machine.
>
> I have done what I can to ensure that even if someone
> knew what port is open they would not be able to pry
> into the machine.
>
> Nevertheless, I am trying to assess how difficult it would
> be for an intruder who does not know the open port. For
> example, if I had created an open port 22363 on the remote
> machine, I know that I can use telnet to verify the
> port is open:
>
> telnet remote-host 22263
>
> Which connects if the port is open and hangs otherwise.
>
> I want to know how an intruder can:
> 1. select a particular remote-host for attention

They use nmap and run over an ip-range, many times just the standard
ports, unless they are looking at a specific machine, then they run a
full port scan.

> 2. given that host, find one or more of the 65,000 ports
> that may give access.

You don't telnet to each of them, you use an automated tool, see above.

> I have tried nmap which seems only to scan the first 1024
> ports. As I read man nmap I tried a number of things
> like -PU or -PY with no success.

you have to specify the range: -p1-65000



--

//Aho

[root]

That does the trick. So I ran an experiment to scan just 10 ports which
included the open port. It took 1.7 seconds. At that rate it would
take a little over 3 hours to scan all the ports.

I also limited the ssh login attempts to 3, then imposed a 1 minute
wait before additional logins could be tried. I think that defeats
any brute force break in.

Thanks.
>
>
>

[J G Miller]

On Tuesday, May 21st, 2013, at 14:24:26h +0000, Root wrote:

> There are many ways to probe ports when I am logged
> into the machine, but this isn't what I want. I
> want to pretend to be an intruder and see how much
> trouble it would be to even find an opening.

I hesitate to recommend proprietary software, but you could
consider using the free for home use version of Nessus to
give your host a thorough security check including port
scans which it does with nmap.

<http://www.tenable.COM/products/nessus>

For just GPL software, take a look at the different utilities
at

<http://www.yolinux.COM/TUTORIALS/LinuxSecurityTools.html>

which includes a section on port scanners.

If I recall correctly, the general advice is do not bother
with chkrootkit, and if I do not say that, Moe Trin will be
posting to say how useless it is. ;)

[root]

J G Miller <mil...@yoyo.ORG> wrote:
> On Tuesday, May 21st, 2013, at 14:24:26h +0000, Root wrote:
>
>> There are many ways to probe ports when I am logged
>> into the machine, but this isn't what I want. I
>> want to pretend to be an intruder and see how much
>> trouble it would be to even find an opening.
>
> I hesitate to recommend proprietary software, but you could
> consider using the free for home use version of Nessus to
> give your host a thorough security check including port
> scans which it does with nmap.
>
><http://www.tenable.COM/products/nessus>

Thanks, I have bookmarked this to take a look.

>
> For just GPL software, take a look at the different utilities
> at
>
> <http://www.yolinux.COM/TUTORIALS/LinuxSecurityTools.html>

Ditto.

>
> which includes a section on port scanners.
>
> If I recall correctly, the general advice is do not bother
> with chkrootkit, and if I do not say that, Moe Trin will be
> posting to say how useless it is. ;)

The sites I am connecting to are just ordinary people's houses.
The are all friends, and I have no reason to expect they
would be a target for an attack.

Thanks.

[Tauno Voipio]

Google for portscan. In principle, the attacker crafts SYN segments
for all ports he's interested in, and records any SYN-ACK segments
received.

There are tools, but I'd not like to point directly to them.
If you get one, please use ti responsibly.

--

Tauno Voipio

[Chris Davies]

root <NoE...@home.org> wrote:
> Nevertheless, I am trying to assess how difficult it would
> be for an intruder who does not know the open port.

Trivial. See below

> For example, if I had created an open port 22363 on the remote machine,
> I know that I can use telnet to verify the port is open:
> telnet remote-host 22263

> I want to know how an intruder can:
> 1. select a particular remote-host for attention
> 2. given that host, find one or more of the 65,000 ports
> that may give access.

> I have tried nmap which seems only to scan the first 1024
> ports.

That's the default setting. You can specify a port range like this:
nmap -p 0-65535 remotehost

Chris

[crankypuss]

On 05/21/2013 01:09 PM, root wrote:
> I also limited the ssh login attempts to 3, then imposed a 1 minute
> wait before additional logins could be tried. I think that defeats
> any brute force break in.

If you can afford the overhead for tracking, rather than imposing a
fixed 1-minute delay, consider imposing a geometrically expanding
delay... for example, from 1 minute to 5, from 5 to 25, from 25 to 125,
and so forth. Depending on just how you set it up, you can effectively
convert brute-force breakin to "your first 10 guesses" or whatever you
feel comfortable with. Of course that can result in transforming a
brute-force breakin attack into a denial-of-service attack, and if you
have legitimate-but-stoopid users you'll get more support requests, but
depending on the situation it's something to consider.

[Richard Kettlewell]

root <NoE...@home.org> writes:
> J.O. Aho <us...@example.net> wrote:
>> On 21/05/13 16:24, root wrote:

>>> I have tried nmap which seems only to scan the first 1024
>>> ports. As I read man nmap I tried a number of things
>>> like -PU or -PY with no success.
>>
>> you have to specify the range: -p1-65000
>
> That does the trick. So I ran an experiment to scan just 10 ports which
> included the open port. It took 1.7 seconds. At that rate it would
> take a little over 3 hours to scan all the ports.

It’s not really safe to assume it scales like that. Scanning all 64k
TCP ports over ethernet takes 2.6s for me. With a narrower connection
to the attack the elapsed time would presumably be longer, but not
necessarily by very much. Even with a 1Mbit/s connection I wouldn’t be
surprised if it could take less than a minute.

> I also limited the ssh login attempts to 3, then imposed a 1 minute
> wait before additional logins could be tried. I think that defeats
> any brute force break in.

I would want to know how the limitation coped with concurrent login
attempts before being too sure. IMHO a better approach is to make it a
matter of computation rather than configuration, either by using a very
expensive password hashing algorithm or by disabling password login
altogether and using keys instead. (I use the latter approach for
Internet-facing logins.)

--
http://www.greenend.org.uk/rjk/

[root]

Richard Kettlewell <r...@greenend.org.uk> wrote:
> root <NoE...@home.org> writes:
>> J.O. Aho <us...@example.net> wrote:
>>> On 21/05/13 16:24, root wrote:
>
>>>> I have tried nmap which seems only to scan the first 1024
>>>> ports. As I read man nmap I tried a number of things
>>>> like -PU or -PY with no success.
>>>
>>> you have to specify the range: -p1-65000
>>
>> That does the trick. So I ran an experiment to scan just 10 ports which
>> included the open port. It took 1.7 seconds. At that rate it would
>> take a little over 3 hours to scan all the ports.
>

> It?s not really safe to assume it scales like that. Scanning all 64k

> TCP ports over ethernet takes 2.6s for me. With a narrower connection
> to the attack the elapsed time would presumably be longer, but not

> necessarily by very much. Even with a 1Mbit/s connection I wouldn?t be

> surprised if it could take less than a minute.
>
>> I also limited the ssh login attempts to 3, then imposed a 1 minute
>> wait before additional logins could be tried. I think that defeats
>> any brute force break in.
>
> I would want to know how the limitation coped with concurrent login
> attempts before being too sure. IMHO a better approach is to make it a
> matter of computation rather than configuration, either by using a very
> expensive password hashing algorithm or by disabling password login
> altogether and using keys instead. (I use the latter approach for
> Internet-facing logins.)
>

I set up what I am sure are uncrackable passwords at each of the
remote sites. Within those networks I transferred ssh keys to
the target machine so that their access is not hampered. Likewise
I have transferred my public keys to the target machine.

I got my iptables implementation of the 1 minute rule from a
search of the net. It has a disadvantage, however. It limits
the time between scp file transfers. I changed the delay down
to 15 seconds.

As far as file transfers go, I learned about a remarkable
package sshfs.