Wednesday, October 7, 2009

Linux Securirty Notes 8: SSH & MD5Sum

Notes on SSH Security.
    It is hard to trace or decrypt the data by sniffing a ssh session. Hardly we get the information about the data by sniffing the packet streams in a ssh session
Eg:-
Try with  #tcpdump -w ssh_sniff.log -i eth0 dst port 22 and analyze the data using ethereal.
The out put encrypted and send across the wire.
    So here using the secure id authentication instead of the password login will be more secure so that the username and password will not be exposed.

    SSH is based on PKI, There is a public key and a Private Key. In  "known_host" file in users ~/.ssh directory resides the public key of the remote server. When SSH clients make the connection it encrypt the data to server using the server's public key. The Public has to be shared with the client and one and only server which created or has the private key can be decrypted.

Creating the Keybased authentication in SSH:

User based keypair:
$ssh-keygen -t rsa
    This will start creating the private as well public key by asking the path of the file that to be stored.
Then ends up with the key finger print. This key finger print will be unique for each and every keys.
So end result will be creating two keys
  1. id_rsa     the Private key
  2. id_rsa.pub The Public key
Know have to copy the public key to the remote host
#scp id_rsa.pub user@remotehost:

Then in remote system
#cat id_rsa.pub > ~/.ssh/authorized_keys
#chmod 600 ~/.ssh/authorized_keys

Now try connecting to the server
If any errors occured will be logged to /var/log/secure

Note:-
    Always check the authorized_keys files for tampering, since it provides the password less login, it is an attack vector. So always ensure that the file is not tampered. Any usual entries in this file should be taken care with high precaution
      
Port Forwarding Using SSH:
    This will create a Psuedo VPNs. Using this tunnel we can encrypt the data and secure the communication.
Eg:- the telnet/vftp can be secured using the ssh tunnel by making the communication through SSH Tunnel.

For Eg:- Securing the Telnet access.

change the binding address parameter in xinetd for telnetd
#vim /etc/xinetd.d/telnet
---------
bind = 127.0.0.1
---------
 restart the xinetd then the service will be available only to the loopback adaptor.
Now use tunneling to forward the port.
Local (127.0.0.1:2323) -> using SSH Tunnel -> RemoteHost (127.0.0.1:23)

# ssh -L 2323:127.0.0.1:23 192.168.1.100
     This will bind the Remote host's(192.168.1.100) loopback (127.0.0.1) adaptor port 23 to the localhost's loopback adaptor (127.0.0.1) port of 2323.
# Now telnet to the 127.0.0.1 locally. The connection will be establised over the SSH tunnel.   

MD5Sum
    This utility is available under almost all the linux disros. IT generates a bit matching unique string for a given file. This used to check the integrity of the binary file normally used to download.

Testing MD5Sum:
Create a test.txt file and check the md5sum.
#seq 10000 > test.txt
#md5sum test.txt

    This will show a unique key for the file test.txt file. Now make a note of this value. And try moving the test.txt file accross the wire and test.
#md5sum test.txt
    Both strings will be the same.

     Testing the same by modyfying the file will change the md5sum string. So this can be used to confirm the same package has been downloaded without the corruption over the wire. IF the content has been changed and made to remain unchanged then the md5sum will be the same as original. This means that the md5sum is depend upon the content of the file. i.e, Renaming the the binaries will not change the md5sum. This is usefull to find out any impact of Man in Middle attack for the downloaded binaries or to check the integrity of the open source packages that downloaded.

Linux Securirty Notes 7: CHATTR & TCPDUMP

Increase security with extended file attributes - CHATTR
    The chattr command allows to set the files to unchangeable (immutable). This can be used to secure the key configuration files.

#/usr/bin/chattr is the path of the binary. To change the attributes, in case of normal users the user should need to have the owner ship.
#/usr/bin/lsattr is used to reveal the extended attributes on files.

Setting up the attributes:
#lsattr /etc/ssh/sshd_config
    This will show the attributes list for the file
Now set the bit
#chattr +i sshd_config
    Now check the file with lsattr can see that the "i" has been set to file.Thus this file became immutable(even as a root we will be unable to modify the file).
#chattr -i sshd_config to remove the attribute.
   
    There are some programs that will update some configuration files once if a new package installation happens. So this feature can be exploited by the cracker. In such a case this feature is useful. One more example is, if any malicious programs has been installed and changes the resolv.conf then they can redirect all the requests to any phishing websites. So using this feature make very much sense.


SNIFFING the clear text based communication using TCPDUMP.

    The data passes through the wire can be sniffed and can reveal almost all the information. Here will show the sniffing of data send through  TELNET the same method can be follow to sniff the communication between FTP.

Scenario:
Sniffing Telnet session between 2 machines

Now pretend to be a Man in Middle and start sniffing data. (Ethereal is another tool to sniff the network)

# /usr/sbin/tcpdump -i eth0 -w tcpdump.log dst port 23
    This will start capture all packets in eth0 coming having the destination port of 23 in promiscuos mode and will log to file tcpdump.log

Now start analysing the data that has been sniffed.
# tcpdump -r tcpdump.log
    Use switch -A for more details. We can use the ethreal tool to analys the same file captured by tcpdump.

# ethereal -gnome (Open the same file captured by tcpdump)
Using Ethreal we can "follow the TCP Stream" by right click of any Telnet stream to find out all the communication including the credentials and the commands exicuted.
But for SSH we can see everything has been encrypted.
    So have to insist on the encryption based communication. And user password less authentication, which is more secure than password based authentication. Because the credentials are not passed through the wire in this case.

Tuesday, October 6, 2009

Linux Securirty Notes 6: Xinetd & TCPWrappers

Securing the Xinted services

Securing the Xinetd example with Telnet:

Checking the disabled services inside the xinted
#cd /etc/xinetd.d/
# grep disable *

    This shows all the disabled services inside the xinetd.d directory.

Enabling the Telnet in Xientd (Telnet has been outdated and fully replaced with ssh. But this will give more idea about securing the Xinetd services).
    Change the "disable" directive to "no" or comment it out to enable the service on boot.
The key directive that applies to all deamons defined in xinetd is configured in /etc/xinetd.conf, which is called the global configuration.
Eg:- Maximum instalnce (instance = 50), log_type = SYSLOG authpriv (check the syslog configuration to find the facility authpriv where that logs to), The maximum number of connections to the service (cps = 25 30). This can be overwritten by the indivigual configuration of the xinetd directives.

Securing the Telnet (can use the same procedure to secure other Xinetd services):

Step 1:
    Telnet uses /etc/issue.net file as "banner" while users trying to connect. So make a banner with security warning and remove the superfluos information about the version of the OS / Patch etc.
Step 2:
    Use /etc/securetty file to edit the available terminals
Step 3:
    Include the follwing directive to telnet deamon configuration file.
# vim /etc/xinetd.d/telnet
------
only_from = 192.168.10.1
# or if need more hosts to allow
only_from = 192.168.10.1 192.168.10.2 host2 10.0.0.1

------
    So this makes telnet service can be only access from 192.168.10.1. Even the access to the localhost will be only provided when the IP (127.0.0.1) has been listed to the derivative, else xinetd will deny the request from localhost.
Step 4:
    Allow the service access at given time only
-----
# access_times   = hour:min-hour:min
 access_times  = 20:00-20:20

-----
    This makes the service available only between 20:00 to 20:20, and any request coming beyond the time will be rejected
-------
   no_access = 10:30-16:30 #makes the service "to not listen" for the time period of 10:30AM to 4:30PM
-------
Note:-
    Xinetd logs with the facility "authpriv" (log_type derivative in xinted)and according the syslog the authpriv will be logged to /var/log/secure.

Step 5:
    Change the standard port to non standard port
------
port = 23354
------
    This makes the service to new port. And it makes the hackers a bit harder to findout the new running port (Always keep in mind security should be implemented in layers).

TCPWrappers: (Other layer of security)

Security Layers that will be implemented for a xinetd service.

TCPWrappers(source address) -> XINETD(based on timing/connection address) -> TELNET(credentials) (/usr/sbin/in.telnetd)
Or
XINETD(based on timing/connection address) -> TCPWrappers(source address) -> TELNET(credentials) (/usr/sbin/in.telnetd)

    Here is the 3 layers of security and one more layer can be added with IPTables as 4th layer of security.

TCPWrappers relies ipon 2 files
/etc/hosts.allow
/etc/hosts.deny

    TCPWrappers first reads the file /etc/hosts.allow and process i. If no match is found it will read the file /etc/hosts.deny and will process. If there isn't any match in both the file then it permits the access to deamon.
Note:-
    Usuallly rules are defined in hosts.allow and a catchall rule is defined in hosts.deny. As soon a change is made to each file the TCPWrappers takes effect immediately.

Editing /etc/hosts.allow
---------
#syntax
#service: client_list : programs to spawn
in.telnetd :    192.168.1.10

---------
    This permits the access from the host 192.168.1.10 to telnet.
Editing /etc/hosts.deny
-----
#service: client_list
in.telnetd :    ALL

-----
    This will make the service to deny all.
"Now in the above scenario when a new connection makes to the telnet service the TCPWrappers will check the hosts.allow file first. Now the rule for IP 192.168.1.10 is set to allow the connection. So TCPWrapper allows the request from this source. But if other request is coming from any other source address the TCPWrappers will deny the request, bcoz the hosts.deny file has been defined as a catchall rule for in.telnetd.
Overall only the IP 192.168.1.10 will be allowed. TCPWrapper first process the hosts.allow file then the hosts.deny"

Linux Securirty Notes 5: Security With Respect To Syslog

    syslog recieves msgs in unix domain sockets and writes it to the respective files or systems.
/etc/syslog.conf is the file is the configurtation file of syslog utilities.The below given entry is responsible for logging the authentication details to file /var/log/secure.
-----
authpriv.*        /var/log/security
-----
Note:-
The file /var/log/security will contain the logs for user login details, failed login attempts, user creation, system poweroff, restart of authentication services etc.
    So incase of any suspect to the compromise of Linux system, check any change for the definition of logging procedure like misspelling of derivatives or redirection of the logs to any null files etc. So the logs may routed correctly in to the destination.

     When considering the logs and correlate the activities the system time should be accurate. This will help to trace out the time that when the compromise happened hackers. So time sync should happen from stratum 1 server and time should be up2date. NTP should be implemented with the restrict option with the sync servers.

Implementing The Syslog server
     Syslog should be configured to replicate logs to a centralised server. This will increase the integrity of the log from being compromised. Crakers/hackers can manupulate the log files to wash out the evidence once they have hacked in to the system.
To avoid this have to log the logs remotely (Making one more copy) .

Creating a syslog repository.

Note:-
The default syslog port is 514.

Step 1:(In Server)
In Remote system which will act as a syslog repository which accepts the logs:

# vi /etc/sysconf/syslog
-----
#change from
SYSLOGD_OPTIONS="-m 0"
#to
SYSLOGD_OPTIONS="-r"
-----
    This will change the way that the syslog will start and make to listen to the UDP port 514.
Now restart the syslog
# service syslogd restart
   
Note:-
    The iptables should be running to secure the syslog server.

# netstat |grep 514
    Now the syslog server is ready to accept the logs

Step2: (In client)
    Open the syslog configuration file on client to make changes to export the logs to the syslogd server.

# vi /etc/syslog.conf
----------
mail.*    @192.168.1.100
*.*        @syslogserver.domain

---------
    all severity of logs for the facitlity mail will be also logged to server 192.168.1.100 and all the logs will be replicated to the syslog server syslogserver.domain.

Now restart the syslog service in client
#service syslog reload

Now the logs will be generated on both systems. So if a cracker changes the logs in any client it wont get effected in the log server. The daily log check is unavoidable to maintain the integrity of the system.

Comparison of Buffers and Cache

Buffers are allocated by various processes to use as input queues, etc. Most of the time, buffers are some processes' output, and they are file buffers. A simplistic explanation of buffers is that they allow processes to temporarily store input in memory until the process can deal with it.

Cache is typically frequently requested disk I/O. If multiple processes are accessing the same files, much of those files will be cached to improve performance (RAM being much faster than hard drives).

Creating RPM packages from the source code Hello World

      This document explains how to create an RPM package from a source code (test.c) which prints “Hello World” in RED HAT.
The test.c file that is used to create the RPM package is given below. It should be located in the /usr/src/redhat/SOURCES/ directory and /root/ceylonlinux/testing directory.
[root@three testing]# vim test.c
------------------

#include
int main(){
printf("Hello world");
return 0;
}

------------------

A spec file have to be written in order to create either a binary RPM package or a source RPM package. It simply gives information about where the files are stored and where should the files be stored. The spec file which is used for this example is given below.
[root@three testing]# vim test.spec
------------------

Summary: This prints hello world
Name: test
Version:1
Release:1
Copyright: GPL
Group: Applications/System
Source:test.c
BuildRoot:/root/ceylonlinux/testing
%description: This package prints hello world when executed
%prep
%build
gcc -o /root/ceylonlinux/testing/test /root/ceylonlinux/testing/test.c
%install
./test

------------------
The option summary is used to give a general description of whet the RPM package does. This description should be of one line.
  • “Name” is the name of the RPM package.
  • “Version” and “Release” are used to keep track of the modifications done.
  • “Copyright” option is used to mention the license information.
  • “Group” option is used to inform the high level installer programs such has Red hat’s glt to which group this program belongs.
  • “Source” is the source file that is being added to the rpm package. This should appear in the /usr/src/redhat/SOURCES directory.
  • “Build root” is the directory which will be used as the root directory when building the rpm package.
  • “Description” gives information about the rpm package. This can be expanded up to multiple lines.
  • %prep This section is used to set up the environment for building the rpm package. Things like expansion of source tar balls are done in this section. Since in this example there are no tar balls this section is kept blank
  • %build This section is used to compile and to build the source codes. In this example compilation of the source code is done in this section.
  • %install This is used to install the programs and in this example the executable file is run
Note that only the test.c file should be there in the /root/ceylonlinux/testing directory. After creating the spec file execute the following command to create the source rpm package.
# rpmbuild –bs test.spec
It will create a test-1-1.src.rpm package inside the /usr/src/redhat/SRPMS/ directory.
To build an rpm package use the following command.
# rpmbuild –ba test.spec
It will create a test-1-1.src.rpm package in the /usr/src/redhat/SRPMS/ directory and a test-1-1. i386.rpm binary package inside the /usr/src/redhat/RPMS/i386/ directory.