Secure 1st, network security and cyber forensic specialists, announce the release of Secure Hash V1.0. This new Windows application is designed to generate, store, and analyze digital signatures. These digital signatures can then be used during a cyber forensic investigation to ensure the integrity of the investigation.
Secure Hash scans the hard disk (or any storage media) on a Windows PC and calculates the MD5 and SHA1 hashes of the files and builds a list with other vital information such as file size, location, date of creation, and date of modification. The resulting list can be used during a cyber forensic investigation. For example, the investigator may use Secure Hash to save the names, locations, and hashes of all the files on a PC during the first stage of the investigation, after the PC has been removed from the crime scene. Later, the investigator could use this information in a court of law or in a lab to generate a report and file list to ensure the integrity of the investigation.
Secure Hash also allows for analysis and comparison of the digital signatures. A previously generated list of hashes can be loaded and various filters applied to compare the previous list with the current file states. With filtering, it is easy to discover if any files have been modified, created, or deleted as well as finding duplicate files.
Secure Hash is 100% compatible with all versions of Microsoft Windows from Windows 95 to Windows 7 including the 64 bit variants.
Secure 1st is an information security company which specializes in Computer Forensic Solutions, Computer Forensic Training Services, and Computer Forensic Consultancy Services. Secure 1st helps its clients to develop and maintain an integrated security infrastructure that can prevent and minimize the effect of possible security lapses.Pls do not try secure hash , if you are a starter , its risky for you to identify the rootkit thread.
For more information, visit http://www.secure1st.com/.
Sincerely
gurbinder sharma
I am frm Punjab.I am a Microsoft Certified IT Professional. MY Skills:IT Security,Client/Domain,Cloud,VPN,AD,DNS,DHCP,Relay Agent,Access Point And Networking(LAN/WAN/WLAN/WWAN/Wi-MAX)TCP/IP,Virtualization Computing and diskless networking.
Subscribe To http://gurbindersh.blogspot.com
Posts
All Comments
SHAREPOINT
Spotlight on share server 2010
Saturday, November 6, 2010
RAM DUMP ANALYSIS IN CYBER CRIMES
The RAM analysis is a crucial point in a forensic analysis as it allows to retrieve all information normally lost in case the ‘compromised’ computer is turned off. Thanks to the ever increasing number of programs and the constant increase of the space dedicated to RAM the importance of this phase was reconsidered. Inside the RAM it is possible to print list of open files for each process, print list of open connections, scan for modules, print list of open sockets and so on. This information allows a complete analysis in order to identify possible malware traces.
It’s standard procedure to use obfuscation methods in order to hide, among the system/user processes, the process associated with the malware. Common RAM analyses split in two ways of searching processes in the image memory:
The most common procedure is the use of the DKOM (Direct Kernel Object Model) technique presented also at the Black Hat.
Information present in the memory can be generally split in two categories: data and codes. Data refers to bytes that are not executed. For example, it could be data structures directly linked to the kernel functioning of the system or data of an open file. Data is usually stored in parts called heap, stack and pool. Codes refer to executable ‘commands’ necessary in order for the processor to end its task. Current rootkits can be ‘invisible’ and alter the content of the memory in order to change the behaviour of the operating system or the ways in which data is presented to the user. The operation which controls the content of the memory is called “memory patching”.
The term ‘ring’ is used to refer to the privilege level when an application is run. The term “ring 0” identifies running processes in kernel mode and “ring 3” refers to application in “user mode” such as browser, memo pad, etc . With “ring 0” the processor gets access to all registers and the entire system memory; with “ring 3” access is allowed solely to those memory parts used in “user mode”. Obviously the interest area for the rootkit is “ring 0”. Here is a practical example: In case you wish to obtain the list of processes running on one's Windows system. The first step is to open the Task Manager. This system application however, operates in user mode although running the code 'kernel' mode and retrieving the list of running processes. For this type of activity, the Windows Task Manager invokes a feature called NTQuerySystemInformationpresent in the NTDLL.DLL. A routine that operates in kernel mode receives the request and draws on an appropriate kernel structure called System Service Descriptor Table (SSDT). Every time the system interfaces with the kernel in order to run operations requested by applications or through the use of the shell, we could have to deal with a possible point of attack that a rootkit can use in order to alter the normal information flow and thus undermine the correct functioning of Windows. Before invoking a feature able to interface with the kernel of the operating system, the feature has to be imported by the application about to use it. This means that the library(file DLL) with the feature has to be uploaded in the memory space used by the application and added to a special table called Import Address Table. This method adds a new point of failure that the rootkit can take advantage of. Another method widely used by rootkit developers in order to alter the running procedure of the code in user mode is often called inline (function) patching or inserting a trampoline. In this case, the rootkit modifies the first bytes that characterize the feature; it is thus able to filter recovered data, going out of the feature. The possibilities are infinite: the rootkit could for example remove the file from a list of files into a data folder. It is thus possible to hide from the operating system and the installed applications files created ad-hoc linked to the rootkit functioning and other malware. The API NtQueryDirectoryFile is often criticised precisely for this peculiarity of rendering the list of files and folders stored in any directory on the disk.
The DKOM (Direct Kernel Object Manipulation)opened the way to the development of new rootkits that use this technique in order to hide operating processes in user mode altering the objects in kernel. One can take advantage of the kernel to hide not only processes but also peripheral drivers and network ports and run processes with higher user privileges.
In order to understand DKOM it is necessary to describe a Windows feature. The 'user mode' processes are governed by objects that operate in kernel mode known as “executive process blocks” (”EPROCESS blocks“). A EPROCESS block is a structure, stored in memory, that contains information on a specific process in 'user mode'. EPROCESS structures are organized in lists connected twice: every EPROCESS structure points to another process that contains reference (pointers) both to the following and the previous EPROCESS structure. Once the rootkit is able to identify pointers, it is easy to include them in a continuous cycle (loop) until a EPROCESS structure referring to the process you wish to hide or modify is identified. At this point, the rootkit will rearrange the distribution of pointers towards previous and following EPROCESS structures in order to 'disconnect' the hiding process from the respective EPROCESS block.
Although this technique allows to hide processes it is obvious how a low level scanning of the RAM memory searching for the EPROCESS structure could easily show hidden structures also. That's because the entire search highlights the presence of a ‘magic’ value that identifies the presence of the EPROCESS structure. The value looked for is \x03\x00\x1b\x00. This method is used in the Volatility tool through the psscan2 option. The tool makes a bruteforce on the memory under analysis searching for the pattern described. Jesse Kornblum and others have raised various questions about the need not to alter the header of the structure and on the possibility that such a modification may compromise the execution of the process. The answer was negative. The technique that reminds the “Better Magic throught fuzzing” was introduced in order to improve the detection technique of hidden. Although it may not appear appropriate the method consists of the arbitrary modification of the EPROCESS structure and the monitoring of the behaviour the system has. Fuzzing may be summed up as follows:
Once tests were over, it was possible to identify a series of patterns that have to be complete for the correct execution of the process. This approach presents various disadvantages that have to do with the operating system on which it is applied. These tests are actually repeated for the various operating systems supported by the analysis tool; especially for the 64bit systems. The above described complications have redirected investigators towards analyzing the different components involved during the execution of the process with particular attention to the connection between them. Particular interest is shown to the following:
A process is made up of different components such as: threads, handles, DLLs and other structures. As anticipated, interest is focused on threads. Every thread element is associated with a stack, operates inside that part of memory associated with the process and can interact with other threads. All threads are managed by Windows Sheduler which keeps a list of double pointers of the threads present, for each priority level. Going backwards, we note that there is inside the Windows Scheduler a list of running threads, each thread referring to the the ETHREAD structure and each ETHREAD structure refers to the EPROCESS structure. A similar analysis can be carried out for the management of the handles files; the kernel maintains a list of open files and each handle file keeps a reference to a EPROCESS file. Besides these elements (thread and file handles) there are similar analyses with open connections for example; it is thus difficult for an attacker to disguise all reference to the EPROCESS structure.
No tools combine the use of the two techniques shown: “magic” value and kernel object; however with the introduction of an add-on inside the Volatility framework it is possible to enact the first process discovery method.
Therefore, there are 51 fields inside the structure of a process that can be arbitrarily modified included those currently in use in order to find hidden processes. There are however data parts that can not be modified without causing a system crash and the end of the active process. From this analysis a new add-on called “psscan3” was created for the Volatily framework. The script considers solely the fields considered robust for the discovery phase of hidden processes.
One of the most valued features is the object of several famous publications “SIFT Workstation 2.0: SANS Investigative Forensic Toolkit" written by Russ McRee, (GCIH, GCFA, GPEN, CISSP, team leader and senior security analyst for Microsoft's Online Services Security Incident Management team) is the Windows Memory Analysis.Thanks to this new add-on. Thanks to the new “psscan3” script it is possible to see the setbacks of the previous “psscan2” and the process analysis based on new robust fields is introduced.
Here below is the output of the tests run in laboratory with an image example supplied by http://amnesia.gtisc.gatech.edu/~moyix/ds_fuzz_hidden_proc.img.bz2 where it is possible to see how the analysis of active processes with the psscan script and psscan does not detect the “network_listene process.
Very Very Thanks to Mr. Russ McRee. Senior Security analyst for the Microsoft's online security Team.
Regards
gurbinder sharma
It’s standard procedure to use obfuscation methods in order to hide, among the system/user processes, the process associated with the malware. Common RAM analyses split in two ways of searching processes in the image memory:
- List-walking: which traverses the kernel's linked list of process data structures;
- Scanning: which does a sweep over memory, looking for byte patterns that match the data found in a process data structure.
The most common procedure is the use of the DKOM (Direct Kernel Object Model) technique presented also at the Black Hat.
Information present in the memory can be generally split in two categories: data and codes. Data refers to bytes that are not executed. For example, it could be data structures directly linked to the kernel functioning of the system or data of an open file. Data is usually stored in parts called heap, stack and pool. Codes refer to executable ‘commands’ necessary in order for the processor to end its task. Current rootkits can be ‘invisible’ and alter the content of the memory in order to change the behaviour of the operating system or the ways in which data is presented to the user. The operation which controls the content of the memory is called “memory patching”.
The term ‘ring’ is used to refer to the privilege level when an application is run. The term “ring 0” identifies running processes in kernel mode and “ring 3” refers to application in “user mode” such as browser, memo pad, etc . With “ring 0” the processor gets access to all registers and the entire system memory; with “ring 3” access is allowed solely to those memory parts used in “user mode”. Obviously the interest area for the rootkit is “ring 0”. Here is a practical example: In case you wish to obtain the list of processes running on one's Windows system. The first step is to open the Task Manager. This system application however, operates in user mode although running the code 'kernel' mode and retrieving the list of running processes. For this type of activity, the Windows Task Manager invokes a feature called NTQuerySystemInformationpresent in the NTDLL.DLL. A routine that operates in kernel mode receives the request and draws on an appropriate kernel structure called System Service Descriptor Table (SSDT). Every time the system interfaces with the kernel in order to run operations requested by applications or through the use of the shell, we could have to deal with a possible point of attack that a rootkit can use in order to alter the normal information flow and thus undermine the correct functioning of Windows. Before invoking a feature able to interface with the kernel of the operating system, the feature has to be imported by the application about to use it. This means that the library(file DLL) with the feature has to be uploaded in the memory space used by the application and added to a special table called Import Address Table. This method adds a new point of failure that the rootkit can take advantage of. Another method widely used by rootkit developers in order to alter the running procedure of the code in user mode is often called inline (function) patching or inserting a trampoline. In this case, the rootkit modifies the first bytes that characterize the feature; it is thus able to filter recovered data, going out of the feature. The possibilities are infinite: the rootkit could for example remove the file from a list of files into a data folder. It is thus possible to hide from the operating system and the installed applications files created ad-hoc linked to the rootkit functioning and other malware. The API NtQueryDirectoryFile is often criticised precisely for this peculiarity of rendering the list of files and folders stored in any directory on the disk.
The DKOM (Direct Kernel Object Manipulation)opened the way to the development of new rootkits that use this technique in order to hide operating processes in user mode altering the objects in kernel. One can take advantage of the kernel to hide not only processes but also peripheral drivers and network ports and run processes with higher user privileges.
In order to understand DKOM it is necessary to describe a Windows feature. The 'user mode' processes are governed by objects that operate in kernel mode known as “executive process blocks” (”EPROCESS blocks“). A EPROCESS block is a structure, stored in memory, that contains information on a specific process in 'user mode'. EPROCESS structures are organized in lists connected twice: every EPROCESS structure points to another process that contains reference (pointers) both to the following and the previous EPROCESS structure. Once the rootkit is able to identify pointers, it is easy to include them in a continuous cycle (loop) until a EPROCESS structure referring to the process you wish to hide or modify is identified. At this point, the rootkit will rearrange the distribution of pointers towards previous and following EPROCESS structures in order to 'disconnect' the hiding process from the respective EPROCESS block.
Although this technique allows to hide processes it is obvious how a low level scanning of the RAM memory searching for the EPROCESS structure could easily show hidden structures also. That's because the entire search highlights the presence of a ‘magic’ value that identifies the presence of the EPROCESS structure. The value looked for is \x03\x00\x1b\x00. This method is used in the Volatility tool through the psscan2 option. The tool makes a bruteforce on the memory under analysis searching for the pattern described. Jesse Kornblum and others have raised various questions about the need not to alter the header of the structure and on the possibility that such a modification may compromise the execution of the process. The answer was negative. The technique that reminds the “Better Magic throught fuzzing” was introduced in order to improve the detection technique of hidden. Although it may not appear appropriate the method consists of the arbitrary modification of the EPROCESS structure and the monitoring of the behaviour the system has. Fuzzing may be summed up as follows:
Once tests were over, it was possible to identify a series of patterns that have to be complete for the correct execution of the process. This approach presents various disadvantages that have to do with the operating system on which it is applied. These tests are actually repeated for the various operating systems supported by the analysis tool; especially for the 64bit systems. The above described complications have redirected investigators towards analyzing the different components involved during the execution of the process with particular attention to the connection between them. Particular interest is shown to the following:
- Thread;
- File handles.
A process is made up of different components such as: threads, handles, DLLs and other structures. As anticipated, interest is focused on threads. Every thread element is associated with a stack, operates inside that part of memory associated with the process and can interact with other threads. All threads are managed by Windows Sheduler which keeps a list of double pointers of the threads present, for each priority level. Going backwards, we note that there is inside the Windows Scheduler a list of running threads, each thread referring to the the ETHREAD structure and each ETHREAD structure refers to the EPROCESS structure. A similar analysis can be carried out for the management of the handles files; the kernel maintains a list of open files and each handle file keeps a reference to a EPROCESS file. Besides these elements (thread and file handles) there are similar analyses with open connections for example; it is thus difficult for an attacker to disguise all reference to the EPROCESS structure.
No tools combine the use of the two techniques shown: “magic” value and kernel object; however with the introduction of an add-on inside the Volatility framework it is possible to enact the first process discovery method.
Therefore, there are 51 fields inside the structure of a process that can be arbitrarily modified included those currently in use in order to find hidden processes. There are however data parts that can not be modified without causing a system crash and the end of the active process. From this analysis a new add-on called “psscan3” was created for the Volatily framework. The script considers solely the fields considered robust for the discovery phase of hidden processes.
One of the most valued features is the object of several famous publications “SIFT Workstation 2.0: SANS Investigative Forensic Toolkit" written by Russ McRee, (GCIH, GCFA, GPEN, CISSP, team leader and senior security analyst for Microsoft's Online Services Security Incident Management team) is the Windows Memory Analysis.Thanks to this new add-on. Thanks to the new “psscan3” script it is possible to see the setbacks of the previous “psscan2” and the process analysis based on new robust fields is introduced.
Here below is the output of the tests run in laboratory with an image example supplied by http://amnesia.gtisc.gatech.edu/~moyix/ds_fuzz_hidden_proc.img.bz2 where it is possible to see how the analysis of active processes with the psscan script and psscan does not detect the “network_listene process.
Very Very Thanks to Mr. Russ McRee. Senior Security analyst for the Microsoft's online security Team.
Regards
gurbinder sharma
Friday, November 5, 2010
How to set up an Open VPN server
Having a virtual private network affords a lot of convenience, particularly for those who want or need to access a remote network from a different location, such as connecting to a work network from home, or vice versa. With the availability of 3G on the road, or wireless hotspots everywhere, being able to connect, securely, to a remote private network from anywhere is ideal.
OpenVPN is one of the most reliable VPN setups around. It’s fully open source, it’s supported on Linux, Windows, and OS X, it’s robust, and it’s secure. Unfortunately, configuration can be a bit of a pain, so in a series of upcoming tips, I aim to get you up and running quickly.
To begin, you will need to have OpenVPN installed on the server or system you wish to use as a VPN end-point. Most distributions include OpenVPN; for the server setup, I am using OpenVPN 2.0.9 as provided by the RPMForge repository for CentOS 5.
The first part of this series concentrates on the server, while the second and third parts will concentrate on the configuration of Linux and OS X clients, respectively. So without further ado, let’s get our hands dirty.
To begin with, you need to copy some files from the OpenVPN docs directory (typically provided in /usr/share/doc/openvpn-[version]) to create certificates:
# cd /usr/share/doc/openvpn-2.0.9
# cp -av easy-rsa /etc/openvpn/
# cd /etc/openvpn/easy-rsa/
# vim vars
In the vars file, edit the KEY_* entries at the bottom of the file, such as KEY_COUNTRY, KEY_ORG, KEY_EMAIL, etc. These will be used to build the OpenSSL certificates. Next, it’s time to initialize the PKI:
# . ./vars
# sh clean-all
# sh build-ca
# sh build-key-server server
For the above, and the below client certificates, you can enter pretty much anything for the “Common Name” field, however there is a certain logic to use: “OpenVPN-CA” when generating the Certificate Authority, “server” when generating the server certificate, and “client” or the name of the specific client system for the client certificates. Those certificates are generated with:
# sh build-key client1
# sh build-key client2
The next step is to generate the Diffie Hellman parameters for the server:
# sh build-dh
When this is done, you will have a number of files in the keys/ subdirectory. At this point, for the clients, you want to copy the appropriate files to them securely (i.e., via SSH or on a USB stick); the files the clients need are ca.crt, client1.crt, and client1.key (or whatever you named the files when you generated them with the build-key script).
Next, create the OpenVPN server configuration file. To get up and running quickly, copy one of the example config files:
# cd /etc/openvpn/
# cp /usr/share/doc/openvpn-2.0.9/sample-config-files/server.conf .
# vim server.conf
The aim here is to get this going right away, so we won’t examine each of the options in detail. The primary things you want to do are to uncomment the “user” and “group” directives, to make the openvpn process run as the unprivileged “nobody” user. You may also want to change the “local” directive to make it listen to one specific IP address. This would be the IP to which your firewall is forwarding UDP port 1194. As well, you will want to set the “client-to-client” directive to enable it, and also set the “push” directives for route and DNS options. What follows is a comment-stripped server.conf, as an example:
local 192.168.10.11
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.10.0 255.255.254.0"
push "dhcp-option DNS 192.168.10.12"
push "dhcp-option DOMAIN domain.com"
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
Finally, copy the required keys and certificates that you previously generated:
# cd /etc/openvpn/
# cp easy-rsa/keys/ca.crt .
# cp easy-rsa/keys/server.{key,crt} .
# cp easy-rsa/keys/dh1024.pem .
And, finally, start the OpenVPN server:
# /etc/init.d/openvpn start
To get routing set up properly on the server so that remote clients, when they connect, can reach more than just the server itself, you will need to enable IP forwarding. This can be done by the following:
# echo 1 > /proc/sys/net/ipv4/ip_forward
You can also do it by editing /etc/sysctl.conf and adding the following (this is a good thing to do as it will ensure that packet-forwarding persists across reboots):
net.ipv4.ip_forward = 1
You also want to ensure that packets going back to the client system are routed properly. This can be done by changing the route on the gateway of the server’s network to route packets to the client network (10.8.0.1/32) through the OpenVPN server (if the server happens to be the gateway as well, you don’t have to do anything additional to accomplish this). How this is done largely depends on the operating system of the gateway.
Once this is done, you should be able to ping any machine on the server’s LAN from the client, and be able to ping the client from any machine on the server’s LAN. For instance, from a machine on the server LAN (not the server):
% traceroute 10.8.0.6
traceroute to 10.8.0.6 (10.8.0.6), 64 hops max, 52 byte packets
1 fw (192.168.10.1) 0.848 ms 0.342 ms 0.249 ms
2 server (192.168.10.11) 0.214 ms 0.231 ms 0.243 ms
3 server (192.168.10.11) 0.199 ms !Z 0.443 ms !Z 0.396 ms !Z
% ping 10.8.0.6
PING 10.8.0.6 (10.8.0.6): 56 data bytes
64 bytes from 10.8.0.6: icmp_seq=0 ttl=63 time=17.540 ms
And from the client:
# traceroute 192.168.10.65
traceroute to 192.168.10.65 (192.168.10.65), 30 hops max, 40 byte packets
1 10.8.0.1 (10.8.0.1) 22.963 ms 27.311 ms 27.317 ms
2 10.8.0.1 (10.8.0.1) 27.297 ms !X 27.294 ms !X 27.269 ms !X
# ping 192.168.10.65
PING 192.168.10.65 (192.168.10.65) 56(84) bytes of data.
64 bytes from 192.168.10.65: icmp_seq=1 ttl=62 time=515 ms
Sincerely
Gurbinder Sharma
OpenVPN is one of the most reliable VPN setups around. It’s fully open source, it’s supported on Linux, Windows, and OS X, it’s robust, and it’s secure. Unfortunately, configuration can be a bit of a pain, so in a series of upcoming tips, I aim to get you up and running quickly.
To begin, you will need to have OpenVPN installed on the server or system you wish to use as a VPN end-point. Most distributions include OpenVPN; for the server setup, I am using OpenVPN 2.0.9 as provided by the RPMForge repository for CentOS 5.
The first part of this series concentrates on the server, while the second and third parts will concentrate on the configuration of Linux and OS X clients, respectively. So without further ado, let’s get our hands dirty.
To begin with, you need to copy some files from the OpenVPN docs directory (typically provided in /usr/share/doc/openvpn-[version]) to create certificates:
# cd /usr/share/doc/openvpn-2.0.9
# cp -av easy-rsa /etc/openvpn/
# cd /etc/openvpn/easy-rsa/
# vim vars
In the vars file, edit the KEY_* entries at the bottom of the file, such as KEY_COUNTRY, KEY_ORG, KEY_EMAIL, etc. These will be used to build the OpenSSL certificates. Next, it’s time to initialize the PKI:
# . ./vars
# sh clean-all
# sh build-ca
# sh build-key-server server
For the above, and the below client certificates, you can enter pretty much anything for the “Common Name” field, however there is a certain logic to use: “OpenVPN-CA” when generating the Certificate Authority, “server” when generating the server certificate, and “client” or the name of the specific client system for the client certificates. Those certificates are generated with:
# sh build-key client1
# sh build-key client2
The next step is to generate the Diffie Hellman parameters for the server:
# sh build-dh
When this is done, you will have a number of files in the keys/ subdirectory. At this point, for the clients, you want to copy the appropriate files to them securely (i.e., via SSH or on a USB stick); the files the clients need are ca.crt, client1.crt, and client1.key (or whatever you named the files when you generated them with the build-key script).
Next, create the OpenVPN server configuration file. To get up and running quickly, copy one of the example config files:
# cd /etc/openvpn/
# cp /usr/share/doc/openvpn-2.0.9/sample-config-files/server.conf .
# vim server.conf
The aim here is to get this going right away, so we won’t examine each of the options in detail. The primary things you want to do are to uncomment the “user” and “group” directives, to make the openvpn process run as the unprivileged “nobody” user. You may also want to change the “local” directive to make it listen to one specific IP address. This would be the IP to which your firewall is forwarding UDP port 1194. As well, you will want to set the “client-to-client” directive to enable it, and also set the “push” directives for route and DNS options. What follows is a comment-stripped server.conf, as an example:
local 192.168.10.11
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.10.0 255.255.254.0"
push "dhcp-option DNS 192.168.10.12"
push "dhcp-option DOMAIN domain.com"
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
Finally, copy the required keys and certificates that you previously generated:
# cd /etc/openvpn/
# cp easy-rsa/keys/ca.crt .
# cp easy-rsa/keys/server.{key,crt} .
# cp easy-rsa/keys/dh1024.pem .
And, finally, start the OpenVPN server:
# /etc/init.d/openvpn start
To get routing set up properly on the server so that remote clients, when they connect, can reach more than just the server itself, you will need to enable IP forwarding. This can be done by the following:
# echo 1 > /proc/sys/net/ipv4/ip_forward
You can also do it by editing /etc/sysctl.conf and adding the following (this is a good thing to do as it will ensure that packet-forwarding persists across reboots):
net.ipv4.ip_forward = 1
You also want to ensure that packets going back to the client system are routed properly. This can be done by changing the route on the gateway of the server’s network to route packets to the client network (10.8.0.1/32) through the OpenVPN server (if the server happens to be the gateway as well, you don’t have to do anything additional to accomplish this). How this is done largely depends on the operating system of the gateway.
Once this is done, you should be able to ping any machine on the server’s LAN from the client, and be able to ping the client from any machine on the server’s LAN. For instance, from a machine on the server LAN (not the server):
% traceroute 10.8.0.6
traceroute to 10.8.0.6 (10.8.0.6), 64 hops max, 52 byte packets
1 fw (192.168.10.1) 0.848 ms 0.342 ms 0.249 ms
2 server (192.168.10.11) 0.214 ms 0.231 ms 0.243 ms
3 server (192.168.10.11) 0.199 ms !Z 0.443 ms !Z 0.396 ms !Z
% ping 10.8.0.6
PING 10.8.0.6 (10.8.0.6): 56 data bytes
64 bytes from 10.8.0.6: icmp_seq=0 ttl=63 time=17.540 ms
And from the client:
# traceroute 192.168.10.65
traceroute to 192.168.10.65 (192.168.10.65), 30 hops max, 40 byte packets
1 10.8.0.1 (10.8.0.1) 22.963 ms 27.311 ms 27.317 ms
2 10.8.0.1 (10.8.0.1) 27.297 ms !X 27.294 ms !X 27.269 ms !X
# ping 192.168.10.65
PING 192.168.10.65 (192.168.10.65) 56(84) bytes of data.
64 bytes from 192.168.10.65: icmp_seq=1 ttl=62 time=515 ms
Sincerely
Gurbinder Sharma
Wednesday, November 3, 2010
DISORDER OF SEX DEVOLPMENT: A CASE OF MISSED OPPORTUNITY
A 14 year boy born of nonconsanguineous parents presented to the panel of ekta institute of child health.
with frequent vomitiing his illness dated back to the neonatal period when he started having frequent episodes of non-bilious vomitting. managment by local practioner brought tempraory relief . At 4 months of age the parents noticed empty sacroyotal sacs and the medical advice sought suggessted to " wait till 4 yrs of age" Abdominal sonography was done at that age showed intra abdominal gonads, child was subjected to surgery and the gonads were removed histology confirmed the gonads as overies the symptoms continued unabted .
At 12 year of age when the problem increased in severity , an abdominal sonography was done showed " rudimentary fallopian tubes and uterus and a cervix ending blindly".An abdominal laproscopy was done and these structures were removed .even the second surgery was failed to relieve his symptoms .
EKTA :
The growth parameters were below third percintile stretched phallic lenghth was 5.2 cm both sacrotal sacs were empty and confirmed " Adernal hyperplasia" (CAH).A proper reconstrution surgery and replacement therapy would have allowed the child to be reared up as a normal female.Paradoxical signs are commonly seen during treatment of TB steroids have found to be useful in their treatment. They Stated that adverse drug reactions was only possibly related to Isoniazid.
Gurbinder Sharma
with frequent vomitiing his illness dated back to the neonatal period when he started having frequent episodes of non-bilious vomitting. managment by local practioner brought tempraory relief . At 4 months of age the parents noticed empty sacroyotal sacs and the medical advice sought suggessted to " wait till 4 yrs of age" Abdominal sonography was done at that age showed intra abdominal gonads, child was subjected to surgery and the gonads were removed histology confirmed the gonads as overies the symptoms continued unabted .
At 12 year of age when the problem increased in severity , an abdominal sonography was done showed " rudimentary fallopian tubes and uterus and a cervix ending blindly".An abdominal laproscopy was done and these structures were removed .even the second surgery was failed to relieve his symptoms .
EKTA :
The growth parameters were below third percintile stretched phallic lenghth was 5.2 cm both sacrotal sacs were empty and confirmed " Adernal hyperplasia" (CAH).A proper reconstrution surgery and replacement therapy would have allowed the child to be reared up as a normal female.Paradoxical signs are commonly seen during treatment of TB steroids have found to be useful in their treatment. They Stated that adverse drug reactions was only possibly related to Isoniazid.
Gurbinder Sharma
Subscribe to:
Comments (Atom)