- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: enabling / disabling access to ports?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-12-2011 02:28 PM
тАО05-12-2011 02:28 PM
enabling / disabling access to ports?
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-12-2011 03:05 PM
тАО05-12-2011 03:05 PM
Re: enabling / disabling access to ports?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-12-2011 08:27 PM
тАО05-12-2011 08:27 PM
Re: enabling / 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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-13-2011 03:41 AM
тАО05-13-2011 03:41 AM
Re: enabling / disabling access to ports?
/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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-13-2011 12:58 PM
тАО05-13-2011 12:58 PM
Re: enabling / disabling access to ports?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-13-2011 12:58 PM
тАО05-13-2011 12:58 PM
Re: enabling / disabling access to ports?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-13-2011 05:25 PM
тАО05-13-2011 05:25 PM
Re: enabling / disabling access to ports?
> 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.