2015年9月22日 星期二

Linux ---Named install centos 6

https://www.digitalocean.com/community/tutorials/how-to-install-the-bind-dns-server-on-centos-6

How To Install the BIND DNS Server on CentOS 6


Preamble

This article will show you how to setup and configure the BIND DNS Server. If you are looking for a guide on how to use DigitalOcean's integrated DNS service, you may want to review the "How to Set Up a Host Name with DigitalOcean" article instead.
Before we begin, it is recommended you have at least two cloud servers to run your nameservers. Two nameservers are suggested to assure your primary and secondary servers are redundant in case of failure. You may want to consider using two different POP's as well. For example, we've used San Francisco 1 and New York 1. For the purpose of this guide, it will be assumed you are configuring both a primary and secondary name server.
It is worth noting that if you are managing a large number of domains this may not be the most viable solution, as you will need to manually add domains on both the master and slave nameservers. With that said, running your own nameservers is a great way to have more direct control over your hosting infrastructure, and assert full control over your DNS records.
As with any new server, it's always important to ensure your system is up to date. You can verify this by checking for updates using yum as follows:
yum update -y
(Note: In DigitalOcean, we call our cloud servers as "droplets". We will use both terms throughout this tutorial)

Initial BIND Installation

To begin, we will need to install the BIND and BIND Utilities packages using yum.
yum install bind bind-utils -y
Next, we'll open the BIND (named) configuration file and make several modifications.
nano -w /etc/named.conf
Your "options" section should appear as follows, replacing 2.2.2.2 with the IP of your second droplet.
options {
     #listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        directory "/var/named";
        dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
  allow-query { any; };
        allow-transfer     { localhost; 2.2.2.2; };
        recursion no;

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
};
Above, listen-on must be commented to listen on all available interfaces. Recursion should be turned off to prevent your server from being abused in "reflection" DDoS attacks. The allow-transfer directive whitelists transfers to your secondary droplet's IP. Furthermore, we have changed the allow-query directive to "any" in order to allow users proper access to hosted zones.
Next, we'll want to add a new zone for our first domain, you should add the following to your named.conf below the existing zones.
        zone "mydomain.com" IN {
                type master;
                file "mydomain.com.zone";
                allow-update { none; };
        };
After saving named.conf with the changes above, we're ready to create our first zone file.

Configure BIND Zones

Firstly, we'll need to open the zone file, using the name you specified in the configuration above. (Ex: mydomain.com.zone)
nano -w /var/named/mydomain.com.zone
We'll add the following contents to our newly created file. You should replace the applicable information with your own, where 1.1.1.1 is the IP of your first droplet, 2.2.2.2 is the IP of your second droplet and 3.3.3.3 is the IP you wish to point the domain itself to, such as a droplet running a webserver. You are free to add additional entries in the same format.
$TTL 86400
@   IN  SOA     ns1.mydomain.com. root.mydomain.com. (
        2013042201  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
; Specify our two nameservers
  IN NS  ns1.mydomain.com.
  IN NS  ns2.mydomain.com.
; Resolve nameserver hostnames to IP, replace with your two droplet IP addresses.
ns1  IN A  1.1.1.1
ns2  IN A  2.2.2.2

; Define hostname -> IP pairs which you wish to resolve
@  IN A  3.3.3.3
www  IN A  3.3.3.3
We can now start named for the first time. This may take several minutes while named generates therndc.key file, which only occurs on first execution.
service named restart
Once named has started successfully, we'll want to ensure that it is enabled as a startup service, by running the following:
chkconfig named on
By now, we should have a fully operational primary nameserver. You can verify that BIND is working correctly by running the following command, replacing 1.1.1.1 with the IP of your first droplet.
dig @1.1.1.1 mydomain.com
If you recieve a response which includes an answer and authority section, your nameserver has been configured correctly.

Slave Nameserver Configuration

With our primary nameserver configured, we'll now setup a slave nameserver on our second cloud server.
As always, please assure your system is up to date by checking for updates with yum as follows:
yum update -y
We can start by installing BIND (and related utilities) on the second droplet, in the same manner as the first:
yum install bind bind-utils -y
We'll proceed by opening named.conf and making the same changes we made previously, ommitting the "allow transfer" line. This directive is unnecessary as we will only be transfering records from our primary name server.
nano -w /etc/named.conf
options {
  #listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        directory "/var/named";
        dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
  allow-query { any; };
        recursion no;

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
};
We will add the zone we configured on the first droplet, this time changing the "type" directive to slave, instead of master. You should replace "1.1.1.1" with your first droplet's IP address.
zone "mydomain.com" IN {
 type slave;
 masters { 1.1.1.1; };
 file "mydomain.com.zone";
};
After configuring our slave zone, we'll start named. Again this may take several minutes while our rndc.keyfile is initially generated.
service named start
As with the first cloud server, we want to assure named is set to run at startup with the following:
chkconfig named on
Your slave nameserver should now be up and running. You can verify that it is fully operational by usingdig again, replacing 2.2.2.2 with the IP of your second droplet.
dig @2.2.2.2 mydomain.com
After any changes you make to the master zone files, you will need to instruct BIND to reload. Remember, you must also increment the "serial" directive to ensure synchronicity between the master and slave.
To reload the zone files, we need to run the following command on the master nameserver, followed by the slave:
rndc reload

BIND in a chroot environment

It is generally advised to install the additional package "bind-chroot" which will drop the privileges of BIND into a chroot environment.
Luckily, the CentOS package makes this extremely simple. The only aspect worth noting is that active paths for BIND will change to their chrooted equivalents, for example /var/named becomes/var/named/chroot/var/named With CentOS 6, you will not need to move any files as the package automatically creates hard symlinks to the non-chrooted directories.
If you'd like to enable this feature for the added security which it provides, you can do the following:
yum install bind-chroot -y
service named restart

2015年9月21日 星期一

Linux how to install update SSH

http://www.tecmint.com/install-openssh-server-in-linux/

On RHEL/Centos/Fedora

Type the following yum command to install openssh client and server.
# yum -y install openssh-server openssh-clients

Configuration of OpenSSH

It’s time to configure our OpenSSH behaviour through the ssh config file, but before editing the/etc/ssh/sshd_config file we need to backup a copy of it, so in case we make any mistake we have the original copy.
Open a terminal and run the following command to make a copy of the original sshd configuration file.
$ sudo cp /etc/ssh/sshd_config  /etc/ssh/sshd_config.original_copy
As you can see from the command I typed, I added the original_copy suffix, so every time I see this file I know it is an original copy of the sshd config file.

 nc -v -z 127.0.0.1 22
Referring to the netcat results, the ssh service is running on port 22 on my machine. Very good! What if we want to use another port, instead of 22? We can do that by editing the sshd configuration file.
Set your OpenSSH to listen on TCP port 13 instead of the default TCP port 22. Open the sshd_config file with your favourite text editor and change the port directive to 13.
# What ports, IPs and protocols we listen for
Port 13
Restart OpenSSH server so the changes in config file can take place by typing the following command and runnetcat to verify if the port you set for listening is open or not.
$ sudo /etc/init.d/ssh restart
Should we verify is our openssh server is listening on port 13, or not?. This verification is necessary, so I am calling my lovely tool netcat to help me do the job.
# nc -v -z 127.0.0.1 13
Do you like to make your openssh server display a nice login banner? You can do it by modifying the content of/etc/issue.net file and adding the following line inside the sshd configuration file.
Banner /etc/issue.net

Linux copy folder command

http://www.cyberciti.biz/faq/copy-folder-linux-command-line/

Linux: HowTo Copy a Folder [ Command Line Option ]


I'm a new Linux user. How do I copy a directory or folder under Linux operating system using command line options and bash shell?

You can use various command to copy a folder under Linux operating systems.

cp Command

cp is a Linux command for copying files and directories. The syntax is as follows:
 
cp source destination
cp dir1 dir2
cp -option  source destination
cp -option1 -option2  source destination
 
In this example copy /home/vivek/letters folder and all its files to /usb/backup directory:
 
cp -avr /home/vivek/letters /usb/backup
 
Where,
  • -a : Preserve the specified attributes such as directory an file mode, ownership, timestamps, if possible additional attributes: context, links, xattr, all.
  • -v : Explain what is being done.
  • -r : Copy directories recursively.

Example

Copy a folder called /tmp/conf to /tmp/backup:
$ cp -avr /tmp/conf/ /tmp/backup
Sample outputs:
HowTO: Copy Folder Linux Terminal Command
Fig.01: cp command in action

rsync Command

You can also use rsync command which is a fast and extraordinarily versatile file copying tool. It can make copies across the network. The syntax is as follows:
 
rsync -av /path/to/source /path/to/destination
rsync -av /path/to/source/ /path/to/destination/source

2015年9月16日 星期三

CISCO NTP access group on the NTP client


NTP access group on the NTP client


we will use ntp access-group serve-only 15


  • Peer: Peer access-groups allow both request and control queries to be processed meaning the router will be allowed to update its time from the allowed peers.
  • Query-only: This only allows control queries to be accepted, control queries don’t actually the effect the date/time so I’m going to skip this one. See RFC 1305 for addition information about this.
  • Serve: Allows the router to reply to request as well as control queries.
  • Serve-only: Does not allow control queries and only replies to NTP requests.

access-list 15 remark NTP Peer Only ACL
access-list 15 permit host %{NTP_SERVER_PRIMARY}%
access-list 15 permit host %{NTP_SERVER_SECONDARY}%
access-list 15 deny any log
!
access-list 16 remark NTP Serve Only ACL
access-list 16 permit %{CLIENT_NETWORK}% %{CLIENT_WILDCARD}%
access-list 16 deny any log
!
ntp source %{NTP_SOURCE_INT}%
!
ntp authentication-key %{NTP_KEY_ID}% md5 %{NTP_KEY}%
ntp trusted-key %{NTP_KEY_ID}%
ntp authenticate
!
ntp access-group peer 15
ntp access-group serve-only 16
!
ntp server %{NTP_SERVER_PRIMARY}% key %{NTP_KEY_ID}% prefer
ntp server %{NTP_SERVER_SECONDARY}% key %{NTP_KEY_ID}%
!
ntp logging
ntp max-associations 4

CISCO Understanding the “NTP access-group” command in IOS

https://www.packet-forwarding.net/2013/06/02/understanding-the-ntp-access-group-command-in-ios/


NTP has always been one of those things I have found tricky to really lab up. Its fairly easy to setup, but verifying whether everything is working as you expect, can be hard because it takes a while to synchronize (and even unsynchronize).
In this post I will try and shed some light on the “ntp access-group” command set in Cisco IOS.
When you perform a “?” on the command set it looks like the following (on 12.2(33)SRD7):
1
2
3
4
5
R1(config)#ntp access-group ?
  peer        Provide full access
  query-only  Allow only control queries
  serve       Provide server and query access
  serve-only  Provide only server access
For each of the options you can specify an access-list:
1
2
3
R1(config)#ntp access-group peer ?
  <1-99>       Standard IP access list
  <1300-1999>  Standard IP access list (expanded range)
The trick to understanding how this lightweight security system works is to understand the following sentence in the documentation:
“If you specify any access groups, only the specified access is granted.”
Along with the ordered list of most open to least open:
1
2
3
4
peer
query-only
serve
serve-only
Lets illustrate this with an example. If you apply the following:
1
2
3
4
access-list 90 deny any
access-list 91 permit 10.1.2.10
ntp access-group peer 90
ntp access-group serve-only 91
What you are really doing is telling the router that it cant “peer” with anything (allow time requests and allow the system itself to synchronize). However processing of an incomming time request will go down the list and meet the “ntp access-group serve-only 91” command. This allows time requests from the hosts permitted in the access-list.
In our case host 10.1.2.10 can get its time from the local system.
The example above is for demonstration purposes since the “ntp access-group peer 90” is the same as not having specified the “ntp access-group peer” command in the first place.
So you see, an incomming request goes down the list of things “allowed” and if it finds itself allowed by anything, it succeeds. However if it reach the end of the list and nothing has permitted the request, it is discarded.
Caution
In my example, I have actually locked out any chance for the router itself to synchronize its time. This is due to the fact that since only peer and serve-only is allowed, and the only one of those two that will allow the router itself to synchronize is the peer option and this option denies everything.