wrote in message
news:1142555379.927279.286290@u72g2000cwu.googlegr oups.com

> It is the last 2 entries that concern me. I really don't know what
> port 1863 and 5190 being open indicates. Using:
>
> netstat -lnp | grep ":1863"
> netstat -lnp | grep ":5190"
> Nothing shows up.

On the machine in question, as root:
# lsof -i :1863,5190

Ynotssor,
The command is silent.

Old guy and Ynotssor:

Thanks for the reply. Good info.

> Scans, from where?

There were two series of scans, but both behind the gateway/router. The
first from within the DMZ and the second from a private network behind
a wireless router scanning the DMZ. Both indicated that ports 1863 and
5190 are open.

Curiously, I had a friend run nmap from the internet ( outside my
gateway/router ) and ports 1863 and 5190 do NOT show up in his scan.

Interestingly, today, I got a clean set of fileutils and chkrootkit and
ran it from CDROM. Chkrootkit comes up clean.

Also, interesting he said my gateway/router (a netopia product) is
running telnet.d. Don't know if that is a security risk?

> 'tcptraceroute' or 'hping2'

Thanks for the tip. I'll give it a try. But I think my system is ok,
but I remain paranoid.

On Thu, 16 Mar 2006 16:29:39 -0800, anon9878@hotmail.com wrote:

> Hello:
>
> For all three webservers on my DMZ, when they are scanned by nmap they
> show this:
>
> 22/tcp open ssh OpenSSH 4.0 (protocol 2.0) 80/tcp open
> http Apache httpd 2.0.54 443/tcp open ssl/http Apache httpd
> 2.0.54 1863/tcp open unknown
> 5190/tcp open aol?
>
>
> It is the last 2 entries that concern me. I really don't know what port
> 1863 and 5190 being open indicates. Using:
>
> netstat -lnp | grep ":1863"
> netstat -lnp | grep ":5190"
> Nothing shows up.
>
> Connections to the ports via telnet/ssh/ftp/sftp/http are denied.
>
> Nothing seems to be listening from inside the boxes, which are stripped
> down as much as possible.
>
> These are Linux machines and I'm not aware of any chat software running on
> them, which I'm told are sometimes associated with those ports.
>
> Can someone provide some advice?


Hello.

Since deamon / network applications can be configured to listen / talk on
almost any ports (depending on availability / access level privileges),
it's quite hard to identify with certainty what is running on a port.

List of standard port can help but can also mislead...

Amongst things I would like to check is to try to check with iptables
if there is a special rule for that port. Maybe a redirection.

Now to identify the "real" use of a port can be a daunting task.
But we could start by listening/connecting at the traffic on that port.
Seems easy at first. But if you do suspect your box to be rooted, then
you cannot thrust this box no more. Period.

Then the next step is to use another computer to try to listen at the
traffic on your interesting ports. If another computer is not available,
I would recommend rebooting one of your 3 web servers with a boot CD.
Helix or Knoppix would do fine. And you can look for tcpdump and ngrep
for looking at traffic. Look for these at
http://distrowatch.com

For the boxes you think could be rooted, you could check these softwares :

rkhunter
http://www.rootkit.nl

chkrootkit
http://freshmeat.net/projects/chkrootkit/

These will check for file signature/presence to try to identify the
rootkit.

Then look for File integrity checkers.
These will calculate the checksum of a file and redo it the next night.
A report will let you see if some files changed... Suspiciously...

Check for :

Tripwire

AIDE

But I would recommend a good backup.

Because if a hacker own your box, he might decide to reformat them before
letting you investigate them.





Hope it help.

Noted, thanks.

noEMA wrote:
> On Thu, 16 Mar 2006 16:29:39 -0800, anon9878@hotmail.com wrote:
>
> > Hello:
> >
> > For all three webservers on my DMZ, when they are scanned by nmap they
> > show this:
> >
> > 22/tcp open ssh OpenSSH 4.0 (protocol 2.0) 80/tcp open
> > http Apache httpd 2.0.54 443/tcp open ssl/http Apache httpd
> > 2.0.54 1863/tcp open unknown
> > 5190/tcp open aol?
> >
> >
> > It is the last 2 entries that concern me. I really don't know what port
> > 1863 and 5190 being open indicates. Using:
> >
> > netstat -lnp | grep ":1863"
> > netstat -lnp | grep ":5190"
> > Nothing shows up.
> >
> > Connections to the ports via telnet/ssh/ftp/sftp/http are denied.
> >
> > Nothing seems to be listening from inside the boxes, which are stripped
> > down as much as possible.
> >
> > These are Linux machines and I'm not aware of any chat software running on
> > them, which I'm told are sometimes associated with those ports.
> >
> > Can someone provide some advice?
>
>
> Hello.
>
> Since deamon / network applications can be configured to listen / talk on
> almost any ports (depending on availability / access level privileges),
> it's quite hard to identify with certainty what is running on a port.
>
> List of standard port can help but can also mislead...
>
> Amongst things I would like to check is to try to check with iptables
> if there is a special rule for that port. Maybe a redirection.
>
> Now to identify the "real" use of a port can be a daunting task.
> But we could start by listening/connecting at the traffic on that port.
> Seems easy at first. But if you do suspect your box to be rooted, then
> you cannot thrust this box no more. Period.
>
> Then the next step is to use another computer to try to listen at the
> traffic on your interesting ports. If another computer is not available,
> I would recommend rebooting one of your 3 web servers with a boot CD.
> Helix or Knoppix would do fine. And you can look for tcpdump and ngrep
> for looking at traffic. Look for these at
> http://distrowatch.com
>
> For the boxes you think could be rooted, you could check these softwares :
>
> rkhunter
> http://www.rootkit.nl
>
> chkrootkit
> http://freshmeat.net/projects/chkrootkit/
>
> These will check for file signature/presence to try to identify the
> rootkit.
>
> Then look for File integrity checkers.
> These will calculate the checksum of a file and redo it the next night.
> A report will let you see if some files changed... Suspiciously...
>
> Check for :
>
> Tripwire
>
> AIDE
>
> But I would recommend a good backup.
>
> Because if a hacker own your box, he might decide to reformat them before
> letting you investigate them.
>
>
>
>
>
> Hope it help.

On 17 Mar 2006, in the Usenet newsgroup comp.os.linux.security, in article
<1142652548.865583.129920@i40g2000cwc.googlegroups. com>, anon9878@hotmail.com
wrote:

>There were two series of scans, but both behind the gateway/router. The
>first from within the DMZ and the second from a private network behind
>a wireless router scanning the DMZ. Both indicated that ports 1863 and
>5190 are open.

tcpdump or equal - on the server as well as on the scanning system. On
the server, do the SYNs even reach the server? If so, how does it respond.
On the scanning box, look at the IP and TCP headers. Do the "SYN/ACK"
packets match those from known open ports - specifically in the TTLs and
flags. You could also try using nmap to really probe the apparent
responder - perhaps using the O/S identification options.

>Curiously, I had a friend run nmap from the internet ( outside my
>gateway/router ) and ports 1863 and 5190 do NOT show up in his scan.

The responses _could_be_ getting blocked/dropped, etc., either by your
gateway, or an intermediate router. That's a reason I like to use a
packet sniffer at the target (or "teed" off the target's network cable), so
I can verify that it's the target that is responding.

>Interestingly, today, I got a clean set of fileutils and chkrootkit and
>ran it from CDROM. Chkrootkit comes up clean.

'chkrootkit' and the similar 'rkhunter' (http://www.rootkit.nl/) are only
going to find old rootkits/exploits. They look for specific signs - often
files or directories - and you have to hope that the author of the rootkit
hasn't changed this/that name from '/tmp/.../a' to '/tmp/.../b' (the first
being the tested indication of a '55808.A' worm).

>Also, interesting he said my gateway/router (a netopia product) is
>running telnet.d. Don't know if that is a security risk?

If you didn't know about it, you certainly do want to find out more. No,
that's not the safest service. I don't like the idea of my gateway, router
or firewall accepting ANY connections from outside. To get in, you have
to SSH or tunnel into an internal host, and run a SSH connection from there
out to the gateway.

>Thanks for the tip. I'll give it a try. But I think my system is ok,
>but I remain paranoid.

There is nothing wrong with that!

Old guy

On Fri, 17 Mar 2006, in the Usenet newsgroup comp.os.linux.security, in article
, noEMA wrote:

>Now to identify the "real" use of a port can be a daunting task.
>But we could start by listening/connecting at the traffic on that port.
>Seems easy at first. But if you do suspect your box to be rooted, then
>you cannot thrust this box no more. Period.

All to true

>For the boxes you think could be rooted, you could check these softwares :
>
>rkhunter
>http://www.rootkit.nl
>
>chkrootkit
>http://freshmeat.net/projects/chkrootkit/
>
>These will check for file signature/presence to try to identify the
>rootkit.

Have you audited these tools? I find that they are only good for finding
old rootkits, because they are looking for signs (as noted upthread - file
or directory names) seen in the past. They are also subject to false alarms.

>Then look for File integrity checkers.
>These will calculate the checksum of a file and redo it the next night.
>A report will let you see if some files changed... Suspiciously...

When you think you are r00ted, it's a little late to be doing this. You
need a "clean" set of signatures to know when things have changed. Using
the tools of the package manager (rpm, or debsums) may help, but you have
to know that the tool itself hasn't been compromised. Additionally, they
only test files that they installed - thus, an extra 'root' equivalent
account in /etc/passwd won't be found, because the package manager doesn't
test that file.

>But I would recommend a good backup.

Always. We go a bit further, in that all of our exposed systems are run
from read-only media (not just mounted read-only - but something like CDs).
It's more of a pain to update, but is much less vulnerable.

Old guy

Great info. I'll progress in these directions and I'm sure others will
benefit.

"anon9878@hotmail.com" (06-03-16 16:29:39):

> Can someone provide some advice?

As an addition to the useful hints given by others already, I suggest
plugging the machine in question off from the network and scanning
again. Do this by unplugging the cable instead of merely deactivating
the network interface. You might be surprised finding the ports still
open, even though your machine is effectively offline. If that's the
case, then there is some other host, which claims to be your machine.
Maybe all this is just an IP address conflict. Linux doesn't detect
such issues on its own.

I've heard that at least some commercial gateway devices or software do
have that issue. I might be wrong, though.


Regards.