Date: 02-12-23  Time: 12:18 PM

Author Topic: Restrict access to Server !  (Read 28478 times)

0 Members and 1 Guest are viewing this topic.

ballack67

  • Jr. Member
  • **
  • Posts: 6
  • Karma: +0/-0
Restrict access to Server !
« on: September 09, 2011, 09:01:05 AM »
I have a problem need help from you. I want to restrict access by IP Address from client to server through services ( ssh, telnet, ftp, rlogin...). Ex: I have 10 clients IP Address range from: 10.0.91.10 to 10.0.91.19, I don't want IP Address 10.0.91.11 access to server via ssh , telnet, ftp... but others may be and vice versa, how to resolve this problem?  ???

Michael

  • Administrator
  • Hero Member
  • *****
  • Posts: 1339
  • Karma: +0/-0
Re: Restrict access to Server !
« Reply #1 on: September 18, 2011, 01:49:00 PM »
There are two basic ways. One will always work - using bos.net.ipsec to write "firewall" access rules (can be used for all protocols and port combinations).

A simpler way for what you listed would be to use tcp_wrapper.

Where to get tcp_wrapper? I think it is part of the newer AIX distributions, however, it may be you need to go to AIX Toolbox. I use the bos.net.ipsec fileset these days.

ballack67

  • Jr. Member
  • **
  • Posts: 6
  • Karma: +0/-0
Re: Restrict access to Server !
« Reply #2 on: September 18, 2011, 02:13:47 PM »
Hi Michael!
First, thank you for your response my question.
I have been used tcpwrapper, but i see it's only best support for ftp and telnet services, with ssh service seem more complicated.
I have not used bos.net.ipsec to restrict access before, you can guide more deltails for me, can't you?
Thanks & Best regard!

Michael

  • Administrator
  • Hero Member
  • *****
  • Posts: 1339
  • Karma: +0/-0
Re: Restrict access to Server !
« Reply #3 on: September 18, 2011, 09:16:08 PM »
Yes, I'll make the time to do a short tutorial on using bos.net.ipsec - but note it is very similar to writing a firewall. The first choice is are you going to deny all, or permit all.

Firewall best practice is to deny all; however, there are situations where permit all is preferred. It depends on what you need to manage - permitting the few (deny all, write rules for the happy few), or denying a minority.

I do not understand why ssh should be more difficult than telnet or ftp. ssh is just port 22, and tcp_wrapper should recognize ssh or sshd as a program to monitor just as any other. Tell me a bit more, without giving any secrets away, about your specific problem so I can understand why ssh, in terms of tcpwrapper, is different than telnet.

Michael

ballack67

  • Jr. Member
  • **
  • Posts: 6
  • Karma: +0/-0
Re: Restrict access to Server !
« Reply #4 on: September 19, 2011, 04:22:04 AM »
Hi Michael!
Can you guide me how to install and configure the IPsec?
tcp_wrapper: I downloaded it from internet ( tcp_wrappers-7.6.1.0.exe), after that i installed it to AIX server, create 2 file /etc/hosts.allow and /etc/hosts.deny, modify inetd.conf :
 
ftp     stream  tcp6    nowait  root    /usr/local/bin/tcpd         ftpd
telnet  stream  tcp6    nowait  root    /usr/local/bin/tcpd      telnetd ?a
ssh     stream  tcp6    nowait  root    /usr/local/bin/tcpd       sshd

./usr/local/bin/tcpdchk -v
refresh -s inetd
As I know, hosts.allow file has higher priority than hosts.deny, but I see It don't follow such rules and doesn't work as expected  >:(. Example:
I have 2 servers, server1 ( 10.0.10.25), server2 ( 10.0.10.27), I want server1 connect to server2 through ftp and restrict access through telnet and ssh ....I modified 2 file hosts.allow & hosts.deny at server2 as follow:
hosts.allow:
ftpd:10.0.10.25
hosts.deny:
telnetd:10.0.10.25
sshd:10.0.10.25
After that refresh -s inetd, but I don't understand why It's still connect each other through telnetd, sshd...

Michael

  • Administrator
  • Hero Member
  • *****
  • Posts: 1339
  • Karma: +0/-0
Re: Restrict access to Server !
« Reply #5 on: September 19, 2011, 11:03:48 PM »
tcpd is not ipsec, however, this is how I have used it.

To begin with: /etc/hosts.deny
ALL: ALL

In other words, deny all protocols wrapped in /etc/inetd.conf unless an /etc/hosts.allow line permits it.

The alternative of ALL:ALL for allow, with specific deny rules, won't work - imho.


ballack67

  • Jr. Member
  • **
  • Posts: 6
  • Karma: +0/-0
Re: Restrict access to Server !
« Reply #6 on: September 20, 2011, 07:32:11 AM »
Hi Michael!
I understand different between tcpd and IPsec, simply I mean that is other questions.
I tried do with tcp_wrapper to restric access but It only affect to ftp and telnet, with ssh is not. I see tcpd not control ssh service, when I configure sshd:ipaddress at hosts.deny but It's still connect nomarlly.

Michael

  • Administrator
  • Hero Member
  • *****
  • Posts: 1339
  • Karma: +0/-0
Re: Restrict access to Server !
« Reply #7 on: September 27, 2011, 07:55:08 PM »
tcp_wrapper works by using /etc/inetd.conf to intercept incoming messages on certain ports. Older versions of sshd did that as well - more recent ones have the sshd running in the background.

What you will need to do is stop the SRC subsystem activation of sshd and enter a line in /etc/inetd.conf to tcp_wrap the sshd deamon.

I just checked my AIX 5.1 system and it has the startup of sshd via /etc/inittab - it starts the daemon directly.
On later systems sshd is being started via the rc.d directories (/etc/rc.d/rc2.d/Ssshd) - you will need to remove these files so they do not start.

Then in /etc/inetd.conf add:

ssh stream  tcp6    nowait  root    /usr/local/bin/tcpd /usr/sbin/sshd -i -D -4


Note from man page regarding starting from inetd:

  -i   Specifies that sshd is being run from inetd(8).  sshd
               is normally not run from inetd because it needs to
               generate the server key before it can respond to the
               client, and this may take tens of seconds.  Clients
               would have to wait too long if the key was regenerated
               every time.  However, with small key sizes (e.g., 512)
               using sshd from inetd may be feasible.


The -D and -4 arguments above are optional...
In your case the -D may be necessary, however, I do not know what effect that has on supporting multiple connections.

          -D   When this option is specified sshd will not detach and
               does not become a daemon.  This allows easy monitoring
               of sshd.

          -4   Forces sshd to use IPv4 addresses only.




Bottom line: the sshd process must be wrapped via the /etc/inetd.conf - and you will need some extra arguments to make sure all incoming connections are being handled by tcpd first.



juherrarte

  • Registered
  • *
  • Posts: 1
  • Karma: +0/-0
Re: Restrict access to Server !
« Reply #8 on: May 11, 2018, 04:50:38 PM »
this action was succecfully? either no?

couze i have the same problem.

Michael

  • Administrator
  • Hero Member
  • *****
  • Posts: 1339
  • Karma: +0/-0
Re: Restrict access to Server !
« Reply #9 on: May 13, 2018, 11:18:20 AM »
Since that post was written I have learned yet another option - using sshd_config.

You will need to look at the "Match" option - as it provides a way to use "Addresses" as a selection criteria.

Code: [Select]
          Match
               Introduces a conditional block.  If all of the criteria
               on the Match line are satisfied, the keywords on the
               following lines override those set in the global
               section of the config file, until either another Match
               line or the end of the file.  If a keyword appears in
               multiple Match blocks that are satisfied, only the
               first instance of the keyword is applied.

               The arguments to Match are one or more criteria-pattern

     Page 14                                         (printed 5/6/18)

     SSHD_CONFIG(5)         (September 27 2017 )        SSHD_CONFIG(5)

               pairs or the single token All which matches all
               criteria.  The available criteria are User, Group,
               Host, LocalAddress, LocalPort, and Address.  The match
               patterns may consist of single entries or comma-
               separated lists and may use the wildcard and negation
               operators described in the PATTERNS section of
               ssh_config(5).

               The patterns in an Address criteria may additionally
               contain addresses to match in CIDR address/masklen
               format, such as 192.0.2.0/24 or 2001:db8::/32.  Note
               that the mask length provided must be consistent with
               the address - it is an error to specify a mask length
               that is too long for the address or one with bits set
               in this host portion of the address.  For example,
               192.0.2.0/33 and 192.0.2.0/8, respectively.

If you need an example - just ask. (I do not have one right now, or I would have already added it).
« Last Edit: May 13, 2018, 12:33:10 PM by Michael »