Open ports on Linux server

[DaJo]

Hi,

I have a RHEL 5 Server, and would like to open the following ports:
15701
15702
1521

I tried a few things, including:
1. iptables -A INPUT -p tcp --dport 1521 -j ACCEPT
2. service iptables save
3. service iptables restart

Output:
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]
Applying iptables firewall rules: [ OK ]
Loading additional iptables modules: ip_conntrack_netbios_ns [ OK ]

However, when I try telnet to this machine on port 1521 (remotely), it doesn't work:
remote machine%
telnet: Unable to connect to remote host: Connection refused

remote machine% telnet 22
This works.

Please help.

Thanks.

[Steven Schweda]

> [...] would like to open the following
> ports:
> [...]

I never know what peopke mean when they say
this.

> [...] Connection refused

This normally means that there's no server
program listening (or registered to listen)
at the requested port. If you want some
server program to listen at this port, then
you need to install and configure it. Whom
do you expect to be listening at these ports?

[Michal Kapalka (mikap)]

hi,

normally the port 1521 is used for oracle listener, did you start the listener ???

mikap

[Ivan Ferreira]

Use netstat -an | grep LISTED to identify if the port 1521 is in the LISTEN state. If don't, then you won't be able to connect as the service for that port is not started (oracle listener).

As we don't know your previous rules, you may want to try just stopping the service for troubleshoot purposes.

service iptables stop
telnet host 1521

If that works, then your firewall is the problem, if don't, then the firewall is not related.

[DaJo]

Thanks for the input. The stmt "open port" might sound quite generic, but here are some more details:

Source machine A (windows server)

Runs a service that connects to machine B on port 15701
-- this is not related to the oracle listener

Target machine B (Linux server)

Needs to allow connections via port 15701 from Source machine A

I'm trying to find out the best way to achieve this, and the first thought is to make sure "machine B" is equipped to allow connections on port 15701

[Steven Schweda]

> Target machine B (Linux server)
>
> Needs to allow connections via port 15701
> from Source machine A

Ok. Who's stopping it?

> However, when I try telnet to this machine
> on port 1521 [...]

I see where you tried to get to port 1521.
I see nothing about any test of port 15701.

> [...] Whom do you expect to be listening at
> these ports?

Still wondering...

> -- this is not related to the oracle
> listener

Ok. So, WHAT _IS_ IT RELATED TO?

> [...] the first thought is to make sure
> "machine B" is equipped to allow
> connections on port 15701

_My_ first thought would be to make sure that
someone (server program) on "machine B" is
listening on port 15701. Then, if I got an
error message other than "Connection
refused", I might start worrying about some
firewall (like, say, iptables) getting in the
way.

[Steven E. Protter]

Shalom,

Diagnostic:

nmap hostname

This will show open ports.

iptables -L

This will show current firewall configuration after your changes.

Note:
remote machine% telnet 22
Should not work. Port 22 is not open.

SEP

[DaJo]

Steven S and Steven P

Thanks for working on this with me. I'll try my best to convey more details, hopefully it helps.
Here's the output for the two commands:

# nmap hostname

Not shown: 1675 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
111/tcp open rpcbind
631/tcp open ipp
926/tcp open unknown

Nmap finished: 1 IP address (1 host up) scanned in 0.068 seconds

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

With regards to error msgs, I get the same "connection refused" for all three ports via telnet: 15701, 15702 and 1521. I just mentioned one error msg with 1521.
I just chose telnet since I understand that's the sure fire way of testing if a port is open.

There is a security software agent/service that runs on source machine A, that needs to connect to ports 15701 and 15702 on target machine B.

From source machine A, when I try a
# telnet machine B 22

Escape character is '^]'.
SSH-2.0-OpenSSH_4.3

basically it works...in the sense that the port looks open. Also, I can ssh from machine A to machine B, so the port is open I presume.

If the ports are open on machine B, shouldn't we see the same result for:
# telnet machine B 15701
and
# telnet machine B 15702

telnet: Unable to connect to remote host: Connection refused

Are you saying that a corresponding service has to run on machine B as well? in order for the ports to be open on machine B?
We actually don't have a service defined that way on machine B, rather everything is handled by the service on machine A. It needs the port open on machine B so it can connect to machine B, complete some process (say sending log/audit info) and then closes it.

Thanks for your help.

[Steven E. Protter]

Shalom again,

Try testing port 22 with ssh, instead of telnet.

ssh -vvv hostname.

SEP

[Steven Schweda]

> Try testing port 22 with ssh, instead of telnet.

Why? The Telnet test works just fine. And,
there's apparently a working SSH server
listening at port 22 (as usual).

> If the ports are open on machine B, [...]

That depends on what you mean by "the ports
are open". As I tried to explain before,
"Connection refused" normally means that you
can talk to the server system, but that
there's no server program listening at the
requested port number. It doesn't matter if
no one is blocking the network traffic, if
no one is listening at the far end. For
example, if you kill the "sshd" process on
the server, then your SSH test should also
fail with a "Connection refused" complaint.

> > [...] Whom do you expect to be listening at
> > these ports?
>
> Still wondering...
>
> > -- this is not related to the oracle
> > listener
>
> Ok. So, WHAT _IS_ IT RELATED TO?

I'm tired of asking.

[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)?