port 8000 clash in /etc/services. Splunk and iRDMI. Do I need to change ports?

[Rahul]

I just opened some ports in my firewall to allow me to connect to the
Splunk web interface on port 8000 (the splunk docs had this as the default
port)

iptables -I INPUT 1 -s mm0xx.foo.bar.edu -d xyxyx.foo.bar.edu -p tcp --
dport 8000 -j ACCEPT

iptables had gotten me all confused since I saw a line of the sort:

ACCEPT tcp -- mm0xx.foo.bar.edu xyxyx.foo.bar.edu tcp dpt:irdmi

I couldn't correlate the term "irdmi" with my port 8000 and thought I was
doing something wrong with iptables.

Finally I solved this mystery by noticing that in /etc/services I had
lines:

irdmi 8000/tcp # iRDMI
irdmi 8000/udp # iRDMI

(1) Is it safe for me to change those to corrosponding lines for splunk?
How are these defaults assigned and do I have a potential clash situation?

(2) Further, are there central repos that try to avoid port-clashes of this
sort when someone comes up with a new mackage or are services clashing all
the time?

[Maxwell Lol]

Post by Rahul
(2) Further, are there central repos that try to avoid port-clashes of this
sort when someone comes up with a new mackage or are services clashing all
the time?

The IANA registers port numbers for well know services.

http://www.iana.org/assignments/port-numbers. A snip of the file:

# 7981-7998 Unassigned
irdmi2 7999/tcp iRDMI2
irdmi2 7999/udp iRDMI2
irdmi 8000/tcp iRDMI
irdmi 8000/udp iRDMI

Using 8000 for your own need is fine, as long as only touplan to use
it.

Frankly, you should block all services except the ones you need. And
then use some odd port on the firewall for a special service (and not
the default one). (I'd only make it available from the inside).

Using odd port numbers only adds a little security through obscurity,
and can delay script kiddies, but not real hackers.
So it adds just a smidgen more security......

[Rahul]

Post by Maxwell Lol
Using 8000 for your own need is fine, as long as only touplan to use
it.
Frankly, you should block all services except the ones you need. And
then use some odd port on the firewall for a special service (and not
the default one). (I'd only make it available from the inside).

Thanks Maxwell! I'll use 8000 then. I am just surprised that splunk, a
pretty popular service it seems, did not bother to request a non-clashing
port from IANA.

[The Natural Philosopher]

Post by Rahul
I just opened some ports in my firewall to allow me to connect to the
Splunk web interface on port 8000 (the splunk docs had this as the default
port)
iptables -I INPUT 1 -s mm0xx.foo.bar.edu -d xyxyx.foo.bar.edu -p tcp --
dport 8000 -j ACCEPT
ACCEPT tcp -- mm0xx.foo.bar.edu xyxyx.foo.bar.edu tcp dpt:irdmi
I couldn't correlate the term "irdmi" with my port 8000 and thought I was
doing something wrong with iptables.
Finally I solved this mystery by noticing that in /etc/services I had
irdmi 8000/tcp # iRDMI
irdmi 8000/udp # iRDMI
(1) Is it safe for me to change those to corrosponding lines for splunk?
How are these defaults assigned and do I have a potential clash situation?
(2) Further, are there central repos that try to avoid port-clashes of this
sort when someone comes up with a new mackage or are services clashing all
the time?

/etc/services is a name to number mapping file only. It is helpfully
populated with the known registered services.

You can do what you like with it.

I have no idea what IRDMI is.

A friend of mine was puzzled when I told him 'you are using the gopher port'

Unaware that once upon a time, Gopher was nearly a world wide web..

[Mike Bleiweiss]

On Tue, 27 Jan 2009 08:49:39 +0000

Post by The Natural Philosopher
A friend of mine was puzzled when I told him 'you are using the gopher port'
Unaware that once upon a time, Gopher was nearly a world wide web..

Hehe... remember Veronica, the great ancestor to google? Or "Very Easy
Rodent-Oriented Net-wide Index to Computer Archives".

Gopher kicks ass.

[Moe Trin]

On Tue, 27 Jan 2009, in the Usenet newsgroup comp.os.linux.misc, in article

Post by Rahul
I just opened some ports in my firewall to allow me to connect to the
Splunk web interface on port 8000 (the splunk docs had this as the
default port)

As long as no OTHER application you have (or plan to have) is using that
port, that's fine.

Post by Rahul
I couldn't correlate the term "irdmi" with my port 8000 and thought I
was doing something wrong with iptables.
Finally I solved this mystery by noticing that in /etc/services I had
irdmi 8000/tcp # iRDMI
irdmi 8000/udp # iRDMI

http://www.iana.org/assignments/port-numbers

Post by Rahul
(1) Is it safe for me to change those to corrosponding lines for splunk?

If you wish - it really doesn't matter.

Post by Rahul
How are these defaults assigned and do I have a potential clash situation?

See RFC4340 section 19.2

4340 Datagram Congestion Control Protocol (DCCP). E. Kohler, M.
Handley, S. Floyd. March 2006. (Format: TXT=318830 bytes)
(Status: PROPOSED STANDARD)

As for a clash - are you running the (defunct) "Intel Remote Desktop
Management Interface"? If so, where did you get the application? Port
8000 was _registered_ to Intel some time between October 1994 and
May 2001, but the service was never standardized. While the IANA web
page noted above says you shouldn't use a port without registering it,
this really only applies if you are going to offer that port to the
Internet as a whole. No Internet Police will come to your house or
business and beat the crap out of you if you decide to use the port.
The port list is used to allow OTHERS to find where you "should" be
operating a service. If you choose to use a different port for a
service, or a different service on a given port, it only means that the
world at large will have some difficulty finding this. Does that
matter to you?

Post by Rahul
(2) Further, are there central repos that try to avoid port-clashes of
this sort when someone comes up with a new mackage or are services
clashing all the time?

If you want to offer a service to others, you do well to use the
standard or well known port where other expect to find that service.
If that service does not have a standard or well known port, the
application author should register the port/service with IANA _if_
that author expects others to find the port/service. You may notice
that this is an inter-operability concept. You don't have to follow
the rules if you don't want to - it's just that others may not know
the rules you _are_ following, and thus may not be able to connect to
that service. I'm sure "The Cult Of The Dead Cow" wasn't concerned
about this when they set the "Back Orfice" mal-ware to use port 31337.

Old guy

[Rahul]

Post by Moe Trin
As for a clash - are you running the (defunct) "Intel Remote Desktop
Management Interface"? If so, where did you get the application? Port

Nope. I am not. I have no clue why that entry is in my services file.
Probably a previous sys-admin.

[Peter B. Steiger]

Post by Rahul
Nope. I am not. I have no clue why that entry is in my services file.
Probably a previous sys-admin.

A lot of distros just throw in the kitchen sink on the theory that a few
thousand (or hundred thousand) bytes isn't enough to lose sleep over, and
it's better to have it and not need it, than to need it and not have it.
Mine (Arch Linux) doesn't have 8000, but it does have such essential
favorites as 104 (acr-nema, from dicom?), 610-612 (npmp / dqs313), and
the like.

[Moe Trin]

On Tue, 27 Jan 2009, in the Usenet newsgroup comp.os.linux.misc, in article

Post by Rahul

Post by Moe Trin
As for a clash - are you running the (defunct) "Intel Remote Desktop
Management Interface"? If so, where did you get the application?

Nope. I am not. I have no clue why that entry is in my services file.

Probably it's your un-named distribution trying to be helpful. As
mentioned by another, the /etc/services file is merely a name/number
cross-reference. It's drawn from the web page I referenced, and that
page has about 10600 ports (UDP and TCP) listed. Certainly doesn't
mean that all might be used for the well-known or registered service.
It lists 33434 only (both UDP and TCP) as 'traceroute use' when in fact
the classic LBL/VanJacobson traceroute defaults to 33434/udp for the
_destination_ of the first hop, and increments port number and TTL for
each hop.

The 'nmap' network scanner has a similar services file (though not as
large). It lists port 8000 as

http-alt 8000/tcp # A common alternative http port

which is functionally correct - rather than factual.

Post by Rahul
Probably a previous sys-admin.

If rpm based, try 'rpm -Vf /etc/services'. If Debian based, there
is a similar trick using 'debsums -c' command, but I'm not sure what
package /etc/services belongs to.

Old guy

[Eric Pozharski]

On 2009-01-28, Moe Trin <***@painkiller.example.tld> wrote:
*SKIP*

Post by Moe Trin
If rpm based, try 'rpm -Vf /etc/services'. If Debian based, there
is a similar trick using 'debsums -c' command, but I'm not sure what
package /etc/services belongs to.

dpkg -S /etc/services

B<debsums> is optional, so it can be uninstalled. And yet, on Debian
some files in F</etc/> belong to none package (generated or missed
I<--purge> while removing).

[Rahul]

Post by Moe Trin
If rpm based, try 'rpm -Vf /etc/services'. If Debian based, there
is a similar trick using 'debsums -c' command, but I'm not sure what
package /etc/services belongs to.

rpm -Vf /etc/services
S.5....T c /etc/printcap
S.5....T c /etc/profile

What is this cryptic reply! I am lost! What am I looking for here! Any
advice "old-guy" or others?

[Moe Trin]

On Thu, 29 Jan 2009, in the Usenet newsgroup comp.os.linux.misc, in article

Post by Moe Trin

Post by Moe Trin
If rpm based, try 'rpm -Vf /etc/services'. If Debian based,
there is a similar trick using 'debsums -c' command, but I'm not
sure what package /etc/services belongs to.

rpm -Vf /etc/services
S.5....T c /etc/printcap
S.5....T c /etc/profile

OK - rpm indicates EITHER it's not watching the contents of the file,
or it is unchanged from the 'installed' version. My own past
experience with rpm and /etc/services is that the file is checked, so
the likely explanation it /etc/services is unchanged from "stock".

Post by Moe Trin
What is this cryptic reply! I am lost!

#include <std.security.lecture.h>

When ANYONE posts a command, or set of commands to be run, it's HIGHLY
desirable to look at the man page to see what the command may do before
you run it.

[compton ~]$ whatis rpm
rpm (8) - Red Hat Package Manager
[compton ~]$

Post by Moe Trin
What am I looking for here

Under the 'QUERY OPTIONS' and 'VERIFY OPTIONS' options.

rpm name of the command
-V verify mode
f the package that contains the file
/etc/services

This is a combination of two commands - 'rpm -qf /etc/services' would
tell what package "owns" that file, and 'rpm -V package_name' would
run verification checks on all files "owned" by that package.

S.5....T c /etc/printcap
S.5....T c /etc/profile

The file[s] /etc/printcap and /etc/profile (which are part of the same
package that "owns" /etc/services) are different from expected.

S Size in bytes is changed
. the fileMode (permissions) are NOT changed
5 the md5sum is changed
. the Device numbers (major:minor) are not wrong/applicable
. the L (readlink(2) test) is not wrong/applicable
. the User (file owner) is correct
. the Group (group owner) is correct
T the Timestamp is changed
c this file is a Configuration file

These differences are expected if someone intentionally changed the
file. As these are configuration files, this is not unexpected.

NOTE 1: If the person running rpm -V does not have permission to
the directory or file, the appropriate output will be a question mark
indicating the status is unknown.

NOTE 2: If the file does not exist, the report will be "missing ".

NOTE 3: Certain files are part of a package, but the _contents_ will
not be tested. For example, /etc/group or /etc/passwd will only be
tested for presence, ownership, and permission. Given that those files
contain usernames unique to _your_ installation, you can hardly expect
anyone to know what you have in there.

NOTE 4: Package verification is NOT a substitute for a proper
Intrusion Detection Tool. If you want such a tool, look for things
like 'aide', 'integrit', 'OSSEC', 'samhain', or 'tripwire'.

Post by Moe Trin
Any advice "old-guy" or others?

RTFM !!! ;-)

Old guy

[Rahul]

Post by Moe Trin
RTFM !!! ;-)
Old guy

Ah! I made the cardinal error! Thanks "Old guy"; it is an afternoon back to
"man rpm" for me. My fault; I was lazy, sorry!

I did look up the options for rpm but my attention wandered before I got
to the description of those bit strings! I never realized rpm had an
evolved status language of its own! ....and to think I "knew" rpm!

[Moe Trin]

On Fri, 30 Jan 2009, in the Usenet newsgroup comp.os.linux.misc, in article

Post by Rahul
I did look up the options for rpm but my attention wandered before I
got to the description of those bit strings! I never realized rpm had
an evolved status language of its own! ....and to think I "knew" rpm!

Yeah, part of it is "playing" with the commands, because some of the
behavior isn't documented or isn't documented well. An interesting
exercise is comparing 'rpm --help' with the man page. It also has
a pair of "save your a$$" commands 'rpm --setperms' and '--setugids'
which both use the same options as 'rpm -q' and come in VERY handy
when you mis-use the chown or chmod commands with a -R option.

Old guy

[Rahul]

Post by Moe Trin
NOTE 4: Package verification is NOT a substitute for a proper
Intrusion Detection Tool. If you want such a tool, look for things
like 'aide', 'integrit', 'OSSEC', 'samhain', or 'tripwire'.

Oh! Thanks for these pointer too "old guy". I wasn't aware of any of these
Intrusion Detection tools (although I wasn't really looking at security
right now it is still nice to know they exist and what they do!) Currently
iptables /etc/services and /etc/hosts form the workhorse of my security.

[Moe Trin]

On Fri, 30 Jan 2009, in the Usenet newsgroup comp.os.linux.misc, in article

Post by Rahul

Post by Moe Trin
NOTE 4: Package verification is NOT a substitute for a proper
Intrusion Detection Tool. If you want such a tool, look for things
like 'aide', 'integrit', 'OSSEC', 'samhain', or 'tripwire'.

Oh! Thanks for these pointer too "old guy". I wasn't aware of any of
these Intrusion Detection tools (although I wasn't really looking at
security right now it is still nice to know they exist and what they
do!)

IDS tools really need to be run from their own bootable media (floppy,
CD, _removable_ drive, etc.) to be most effective. Basically, you take
a snapshot of what your system looks like ``now'' and later compare
what you find then with what it looked like now. Bootable/removable
because you want the tool to be uncompromisable. This means not using
the existing/running operating system, as that could be 0wn3d and doing
Jedi mind tricks to tell you "these aren't the exploits you are looking
for" and so on. Biggest problem (other than having to reboot to be
absolutely positive) is keeping the snapshot up-to-date. Is that
change you see due to an exploit, or did you update the system and
forget that this (example) replaced /boot/vmlinux* ? You've got to
have a "clean" starting point.

Post by Rahul
Currently iptables /etc/services and /etc/hosts form the workhorse of
my security

/etc/services has nothing to do with security - it's merely a name
to number translator. Don't forget that some binaries BUT NOT
ALL are compiled to use /etc/hosts.allow and /etc/hosts.deny. If you
do use those files, make sure all your stuff goes into /etc/hosts.allow
as the only thing that goes in /etc/hosts.deny is the words "ALL: ALL".
'libwrap' (or tcp_wrappers) allows stuff specified in /etc/hosts.allow
and exits. If not in /etc/hosts.allow, it looks in /etc/hosts.deny to
see if access is to be denied. IF NOT EXPLICITLY DENIED, it is allowed
(hence the ALL: ALL to cover the unexpected). But again, this ONLY
applies to stuff compiled to use libwrap.

Old guy

[Rahul]

Post by Moe Trin
/etc/services has nothing to do with security - it's merely a name
to number translator. Don't forget that some binaries BUT NOT
ALL are compiled to use /etc/hosts.allow and /etc/hosts.deny. If you
do use those files, make sure all your stuff goes into /etc/hosts.allow
as the only thing that goes in /etc/hosts.deny is the words "ALL: ALL".
'libwrap' (or tcp_wrappers) allows stuff specified in /etc/hosts.allow
and exits. If not in /etc/hosts.allow, it looks in /etc/hosts.deny to
see if access is to be denied. IF NOT EXPLICITLY DENIED, it is allowed
(hence the ALL: ALL to cover the unexpected).

Thanks "Old Guy". That helps a lot.

Post by Moe Trin
But again, this ONLY
applies to stuff compiled to use libwrap.

Oh! So, what is the best way of opening / blocking ports selectively?
iptables? Or are there other options?

[The Natural Philosopher]

Post by Rahul

Post by Moe Trin
/etc/services has nothing to do with security - it's merely a name
to number translator. Don't forget that some binaries BUT NOT
ALL are compiled to use /etc/hosts.allow and /etc/hosts.deny. If you
do use those files, make sure all your stuff goes into /etc/hosts.allow
as the only thing that goes in /etc/hosts.deny is the words "ALL: ALL".
'libwrap' (or tcp_wrappers) allows stuff specified in /etc/hosts.allow
and exits. If not in /etc/hosts.allow, it looks in /etc/hosts.deny to
see if access is to be denied. IF NOT EXPLICITLY DENIED, it is allowed
(hence the ALL: ALL to cover the unexpected).

Thanks "Old Guy". That helps a lot.

Post by Moe Trin
But again, this ONLY
applies to stuff compiled to use libwrap.

Oh! So, what is the best way of opening / blocking ports selectively?
iptables? Or are there other options?

Iptables is bloody good.

[Moe Trin]

On Tue, 3 Feb 2009, in the Usenet newsgroup comp.os.linux.misc, in article

Post by Rahul

But again, this ONLY applies to stuff compiled to use libwrap.

Oh! So, what is the best way of opening / blocking ports selectively?
iptables? Or are there other options?

Normally, I answer a "what is the best" question with "I like chocolate
ice-cream" (or similar). That's asking an opinion, and opinions are as
varied as the people involved.

"firewall" - whether iptables (which is actually the application that
interfaces with the built-in firewall code in the kernel), the older
IPCHAINS or ipfwadm (not applicable to 2.6 kernels), or an external
appliance of some kind. These have the finest / most versatile
control. You can specify source/destination ports, addresses, as well
as flags within the packet headers.

"tcp_wrappers" (and the associated libwrap) - a simpler mechanism where
you can specify remote address and local ports. It's essentially
unmaintained now - the last release was 7.6 in March 1997.

"routing" which covers a multitude of sins - such things as forwarding
(or _not_ forwarding) packets through a router/modem/what-ever. Another
technique is mucking with the routing tables using 'Reject' routes
(a technique that is NOT recommended, but is used by some protective
tools like BlockHosts or PortSentry) or routing via the loopback
interface (a common technique used by ad blockers, etc.).

Individual applications may also have their own access control rules.
An example would be Apache.

As to which one I'd recommend - strawberry is pretty good...

There is a web site http://www.netfilter.org/documentation/HOWTO/ (also
reachable via http://www.iptables.org/documentation/HOWTO/) that has
seven HOWTOs that are quite useful.

"tcp_wrappers" has some documentation, but some of the tools (such as
tcpdchk) don't work on "modern" installations (specifically, those
using 'xinetd' instead of the older 'inetd').

As for routing - mixed results. Done manually, such as forwarding or
not forwarding packets based on destination port numbers - is usually
a good technique. A packet not forwarded can't be used to exploit
something it can't reach. There are automatic tools, such as
BlockHosts (http://www.aczoom.com/cms/blockhosts), DenyHosts
(http://denyhosts.sourceforge.net), fail2ban (http://www.fail2ban.org)
or the ancient (unsupported) PortSentry that can alter routing in an
effort to block ``attacks'' (usually identified by log-reading). A
real problem with automatic tools is that they can easily be configured
to automatically shoot yourself in the wobbly bits. Some one can spoof
an attack from the IP of your name server - you automatically block
that IP address, and then wonder why new connections have stopped
working. While I include URLs here, I hesitate to recommend such
automatic tools because they are intolerant of configuration mistakes,
and may encourage a sloppy or unreliable setup.

On the OTHER hand, I do recommend you looking at where you expect or
desire connections from. For example, if you have no expectation of
anyone in 'Burkina Faso' (a country in Western Africa - 2W/12N) for
example, you could block the 8 IP ranges registered there. Two problems
with this concept is that IP addresses may be registered in one country
and used elsewhere, and IP address ranges are not conveniently arranged
for ease of use (those 8 ranges in Burkina Faso need 7 rules to
describe them - a /19, 3 /20s a /22, /23 and /24) and you can't depend
on a rDNS (lookup may fail, and .com is used in every country). A
somewhat simpler concept is to ALLOW connections from ranges you want,
and default block the rest. Where that gets hairy is that there are
over 93000 networks around the world.

Hope this gives you something to look at, and some things to think
about. ;-)

Old guy

[Andrew Halliwell]

Post by Rahul

Post by Moe Trin
As for a clash - are you running the (defunct) "Intel Remote Desktop
Management Interface"? If so, where did you get the application? Port

Nope. I am not. I have no clue why that entry is in my services file.
Probably a previous sys-admin.

It's prolly just how the file came with your distro. iRDMI isn't in ubuntu,
but I imagine ubuntu did some housekeeping on the file and removed defunct
services.

[Rahul]

Post by Moe Trin
If you want to offer a service to others, you do well to use the
standard or well known port where other expect to find that service.
If that service does not have a standard or well known port, the
application author should register the port/service with IANA _if_
that author expects others to find the port/service. You may notice
that this is an inter-operability concept. You don't have to follow
the rules if you don't want to - it's just that others may not know
the rules you _are_ following, and thus may not be able to connect to
that service. I'm sure "The Cult Of The Dead Cow" wasn't concerned
about this when they set the "Back Orfice" mal-ware to use port 31337.

Thanks Old-Guy! That pretty much explains it.