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"