enabling / disabling access to ports?

[George N]

Hello, I have a two node serviceguard cluster. I would like to have in our failover scripts, the ability to block and allow access to SMTP and IMAP (port 25 and 143). We have a custom application that uses these services in kind of an unconventional way. Without getting into all the details of it, we would like to accomplish the following:

- Deny requests to port 25 and 143 in the failover script.
- Turn access back on in the failback script.

Sure, I could write something that edits a line in inetd.conf and then runs inetd -c but that's a little clunky. Surely there is a better way? THANKS

[klb]

How about writing a wrapper for the exe called by the entries in inted.conf that checks some condition ( a file somewhere ) before actually firing off the service.

This is probably more clunky even that editing the inted.conf file and reloading it into inetd and it's probably not a very secure thing to do either, but it would work!

Suppose you could also write your own C code to open those ports and hold them open until the SG failover/failback scripts inform them otherwise.

Hth,

-klb

[Steven Schweda]

> [...] disabling access to ports?

I find that it's often more helpful to think
in terms of enabling or disabling the program
which is listening on a particular port than
it is to think about controlling access to
that port. (Controlling access to a port can
be done by a firewall, internal or external,
too. You can guard the approach to a bridge,
or you can demolish the bridge.)

> [...] edits a line in inetd.conf [...]

Rather than have a script edit the thing, I'd
create two editions of the thing, say,
"inetd.conf_norm" and "inetd.conf_alt", and
have "inetd.conf be a symbolic link to one of
them. Then let the script toggle the symlink
(and dope-slap inetd) to effect the change.

That's if the service in question is managed
by inetd. If it's started independently, by
one of the usual start-up scripts, then
editing inetd won't buy you much, but that
might make it easier to disable/enable the
service. Assuming that kind of arrangement,
...

Does this configuration change need to
survive a reboot? If not, then why not use
a "stop" command with the appropriate
start-up script for the service in question?
(And then "start" with the same script(s) to
revert.)

If you choose to kill the listeners, then you
need to determine who's listening on those
ports, and who runs whom. If inetd runs
anyone, then you need to deal with inetd (or
else forget inetd, and use a firewall).

[Bob_Vance]

Assuming that everything of interest is controlled by inetd, another approach would be to restrict inetd via

/var/adm/inetd.sec
.

Changes in inetd.sec are immediate.
I.e., it is read by inetd on each connection.
So, no inetd -c is needed.

Furthermore, you can deny service completely, or by ip or network address, or allow only specific.


## man 4 inetd.sec


I like Steven's idea of two master files + symlink,
one "enabled"
other "disabled"
.

It is clean and simpler than "runtime", dynamic editing of the files.

I use both techniques.
For very static files, I prefer symlink.

The advantage of dynamic editing, is that you don't have to worry about you or a software install making a change to the file (and merging the changes into another file).



((((((((((((((((
Here's a possible "runtime" editing of the files

*** disable
## (F=/var/adm/inetd.sec; T= /tmp/inetd.sec
SERVICE=smtp
sed < $F > $T \
-e "s/^${SERVICE}[ TAB]*/#SGtemp#${SERVICE} /"
cp $T $F
)
((where ^[ TAB]* matches whitespace
and TAB is actual tab key
))

*** enable
## (F=/var/adm/inetd.sec; T= /tmp/inetd.sec
SERVICE=smtp
sed < $F > $T \
-e "s/^#SGtemp#${SERVICE}[ TAB]*/${SERVICE} /"
cp $T $F
)

))))))))))))))))


bv

[George N]

Thanks all for the great ideas, I've decided to go with two master inetd.sec files, one with allow entries and one with deny entries. My scripts simply cp -f the desired file into place. Thanks again

[George N]

solved

[Steven Schweda]

> The advantage of dynamic editing, is that
> you don't have to worry about you or a
> software install making a change to the
> file (and merging the changes into another
> file).

> [...] simply cp -f the desired file into
> place.

While the symlink scheme is efficient,
copying a template file into the active
position has an advantage in not exposing a
template file to the hazards of replacement
by a careless upgrade procedure. You may
still need to deal with changes from updates,
but you shouldn't lose any valuable data.

The switch-over procedure could include a
safety check, to ensure that the file being
overwritten matches one of the template
files, and call for help if it looks
unfamiliar.

Everything's complicated, as usual.