topic Re: Open ports on Linux server in Operating System - Linux

Open ports on Linux server

DaJo — Wed, 14 Jul 2010 22:31:12 GMT

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.

Re: Open ports on Linux server

Steven Schweda — Thu, 15 Jul 2010 00:38:27 GMT

> [...] 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?

Re: Open ports on Linux server

Michal Kapalka (mikap) — Thu, 15 Jul 2010 04:40:31 GMT

hi,

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

mikap

Re: Open ports on Linux server

Ivan Ferreira — Thu, 15 Jul 2010 12:43:31 GMT

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.

Re: Open ports on Linux server

DaJo — Thu, 15 Jul 2010 16:10:15 GMT

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

Re: Open ports on Linux server

Steven Schweda — Thu, 15 Jul 2010 16:47:42 GMT

> 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.

Re: Open ports on Linux server

Steven E. Protter — Thu, 15 Jul 2010 17:14:09 GMT

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

Re: Open ports on Linux server

DaJo — Thu, 15 Jul 2010 18:17:34 GMT

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.

Re: Open ports on Linux server

Steven E. Protter — Thu, 15 Jul 2010 19:02:50 GMT

Shalom again,

Try testing port 22 with ssh, instead of telnet.

ssh -vvv hostname.

SEP

Re: Open ports on Linux server

Steven Schweda — Thu, 15 Jul 2010 19:50:55 GMT

> 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.

Re: Open ports on Linux server

Patrick Wallek — Thu, 15 Jul 2010 20:35:28 GMT

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.

Re: Open ports on Linux server

DaJo — Thu, 15 Jul 2010 21:38:08 GMT

> > -- 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.

Re: Open ports on Linux server

DaJo — Thu, 15 Jul 2010 21:43:30 GMT

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.

Re: Open ports on Linux server

Steven Schweda — Thu, 15 Jul 2010 21:44:11 GMT

> 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.

Re: Open ports on Linux server

DaJo — Thu, 15 Jul 2010 22:05:03 GMT

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.

Re: Open ports on Linux server

Steven Schweda — Fri, 16 Jul 2010 00:05:28 GMT

> [...] 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.

Re: Open ports on Linux server

DaJo — Fri, 16 Jul 2010 20:32:26 GMT

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

Re: Open ports on Linux server

Steven Schweda — Fri, 16 Jul 2010 21:34:21 GMT

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