Open ports on Linux server

[Patrick Wallek]

Post the output of the following:

netstat -a |grep 15701
netstat -a |grep 15702

If you have lsof installed try running:

lsof -i :15701
lsof -i :15702

If the above commands, either netstat or lsof, do not return anything, then you HAVE NO program or daemon listening on the ports. As Steven has said, there MUST be something listening for a conection before a connection can be made.

[DaJo]

> > -- this is not related to the oracle
> > listener
>
> Ok. So, WHAT _IS_ IT RELATED TO?

I mentioned this briefly earlier, re-pasting it here:

There is a security software agent/service that runs on source machine A (windows), that needs to connect to ports 15701 and 15702 on target machine B (Linux).
This is the only service.

Based on your comments, there needs to be another service running/listening on these ports on Target machine B. I can check on that.

Thanks.

[DaJo]

Patrick W,

netstat -a | grep 15701
netstat -a | grep 15702
produced no output.

I have to check with the BU about "the service" that is supposed to listen on these ports on the target server before the ports can be opened.

[Steven Schweda]

> I mentioned this briefly earlier, re-pasting it here:

Yes, you did, and I missed it. Thanks/sorry.
(Of course, "a security software
agent/service" is not a very detailed
description.)

> [...] there needs to be another service
> running/listening on these ports on Target
> machine B. I can check on that.

That's my claim. There needs to be something
running/registered on "B" which is listening.
Knowing nothing, I'd assume that the
installation instructions for this mystery
product would explain what must be done.

[DaJo]

Thanks Steven S.

We are new to this security product as well, and one of the instructions is to open those ports on the target server "so it can communicate".
They haven't provided any info on the services that need to run on the target server, so we are checking back with them.

I'll assign points to all the folks who provided valuable input. Appreciate the time spent in debugging this issue.

[Steven Schweda]

> [...] one of the instructions is to open
> those ports on the target server "so it
> can communicate".

Certainly, if anyone is blocking access at
those ports, then those blocks should be
removed, but the next obvious question is,
"'so it can communicate' with _what_?"


> We are new to this security product [...]

At least you know what its name is, and you
have some instructions to read. The rest of
us are still in the dark.

[DaJo]

Steven S.

The name is Defiance DPS (security) software.

They have asked me to check if the ports are open(/allowed) at the network switch level.
I think therein lies the problem.

It looks like: "telnet machine 15701" should work once the switch related work is complete (maybe ACLs?)

[Steven Schweda]

> The name is Defiance DPS (security) software.

Ok, but they don't seem to have any
easy-to-find installation instructions on the
Web. But feel free to lead me to a useful
document.

> I think therein lies the problem.

I doubt it.

> It looks like: "telnet machine 15701"
> should work once the switch related work is
> complete (maybe ACLs?)

Why does it look that way? (What are you
looking at?) If you expect anything to talk
to these ports on "machine B", then, so far
as I know, there must be some software
installed on "machine B" which listens at
those ports.

A Telnet client (normally) talks to port
23. An SSH client normally talks to port
22. A Web browser normally talks to port 80.
In each case, there must be s server program
running (or registered with [x]inetd) which
is listening at the appropriate port, or else
when a client tried to connect, it would fail
with that "Connection refused" complaint.

Look through your "netstat -an" output for
these (and similar) ports. I predict that
for every service which works, you'll see a
"LISTEN" line in there. And for any other
port, with no "LISTEN" line in there, you'll
get a "Connection refused" complaint if you
try to talk to it.

So far as I know, ACLs are related to files,
not IP ports. Regarding any network switch,
what happens if you try to Telnet to these
ports from "machine B" itself (so that no
external network hardware is involved)?

Did you install any software on "machine B"?
If so, then how, exactly? If not, then to
whom do you expect "machine A" to be talking
(on these ports)?