Category Archives: Security

Protecting SAMBA PDC Share from viruses

Generally domain controller share is used by a user to store its documents, spread sheets, presentations etc… etc..

If a user is a programmer, then he has to save executable file (*.exe, *.com, *.dll). But we know that files with such extensions are having more chances to get infected by viruses.
For a normal user which is not a programmer there is no need of *.exe *.com *.dll etc.. file in his share, So we can prevent such users to have such file in his share.

This can reduce the risk of viruses at least in the user shares which do not require executable file.

If you wanted to disallow EXE files, COM files, or DLL files, you could have a veto files attribute that looked like this:

Veto files = /*.exe/*.com/*.dll/

This will prevent access to or storage of these types of files and effectively prevent a Samba PDC from spreading most types of Windows worms and viruses. You may want to veto other file types to effectively exclude all of the file extensions that are used by viruses to propagate.

Following is the example for User Share in which we have to disallow such kind of files:

[MIKE]
comment = Mike’s Share
path = /home/mike
public = yes
writable = yes
printable = no
valid users = mike @hr
browseable = yes
Veto files = /*.exe/*.com/*.dll/*.sh/*.py/

We see that valid users of the above share are mike & group members of hr group, the share is browse able, the users do not have access or storage permissions to the files with extensions .exe, .com, .dll, .sh, .py

 

TCP SYN DOS Attack

INTRODUCTION
This article discusses a form of Denial of Service Attack—-TCP SYN DOS Attack , a method to conduct denial-of-service attacks by creating TCP “half-open” connections.This method is actively used to attack sites connected to the Internet by leaving no resources for legitimate requests, the resources being the backlog queue(explained later) in this case. There is, as yet, no complete solution for this problem, but there are steps that can be taken to lessen its impact. Although discovering the origin of the attack is difficult, it is possible to do; we have received reports of attack origins being identified.
Any system connected to the Internet and providing TCP-based network services (such as a Web server, FTP server, or mail server) is potentially subject to this attack. Note that in addition to attacks launched at specific hosts, these attacks could also be launched against your routers or other network server systems if these hosts enable (or turn on) other TCP services (e.g., echo). The consequences of the attack may vary depending on the system; however, the attack itself is fundamental to the TCP protocol used by all systems.
This advisory provides a brief outline of the problem and a partial solution. We will update this advisory as we receive new information.
DESCRIPTION
When a system (called the client) attempts to establish a TCP connection to a system providing a service (the server), the client and server exchange a set sequence of messages. This connection technique applies to all TCP connections–telnet, Web,email, etc.
The client system begins by sending a SYN message to the server. The server then acknowledges the SYN message by sending SYN-ACK message to the client. The client then finishes establishing the connection by responding with an ACK message. The connection between the client and the server is then open, and the service-specific data can be exchanged between the client and the server. Here is a view of this message flow:
Client Server
—— ——
SYN——————–>

<—————SYN-ACK

ACK——————–>
Client and server can now send service-specific data.The potential for abuse arises at the point where the server system has sent an acknowledgment (SYN-ACK) back to client but
has not yet received the ACK message. This is what we mean by half-open connection. The server has built in its system memory a data structure describing all pending connections. This data structure is of finite size, and it can be made to overflow by intentionally creating too many partially-open connections.Creating half-open connections is easily accomplished with IP spoofing. The attacking system sends SYN messages to the victim server system; these appear to be legitimate but in fact reference a client system that is unable to respond to the SYN-ACK messages. This means that the final ACK message will never be sent to the victim server system.The half-open connections data structure on the victim server system will eventually fill; then the system will be unable to accept any new incoming connections until the table is emptied out. Normally there is a timeout associated with a pending connection, so the half-open connections will eventually expire and the victim server system will recover. However, the attacking system can simply continue sending IP-spoofed packets requesting new connections faster than the victim system can expire the pending connections.
In most cases, the victim of such an attack will have difficulty in accepting any new incoming network connection. In these cases, the attack does not affect existing incoming connections nor the ability to originate outgoing network connections.However, in some cases, the system may exhaust memory, crash, or be rendered otherwise inoperative.
The location of the attacking system is obscured because the source addresses in the SYN packets are often implausible. When the packet arrives at the victim server system, there is no way to determine its true source. Since the network forwards packets based on destination address, the only way to validate the source of a packet is to use input source filtering.
IMPACT
Systems providing TCP-based services to the Internet community may be unable to provide those services while under attack and for some time after the attack ceases. The service itself is not harmed by the attack; usually only the ability to provide the service is impaired. In some cases, the system may exhaust memory, crash, or be rendered otherwise inoperative.
How to detect a SYN attack
It is very simple to detect SYN attacks. The netstat command shows us how many connections are currently in the half-open state. The half-open state is described as SYN_RECEIVED in Windows and as SYN_RECV in Unix systems.
# netstat -n -p TCP
tcp 0 0 10.150.0.200:21 237.177.154.8:25882 SYN_RECV -
tcp 0 0 10.150.0.200:21 236.15.133.204:2577 SYN_RECV -
tcp 0 0 10.150.0.200:21 127.160.6.129:51748 SYN_RECV -
tcp 0 0 10.150.0.200:21 230.220.13.25:47393 SYN_RECV -
tcp 0 0 10.150.0.200:21 227.200.204.182:60427 SYN_RECV -
tcp 0 0 10.150.0.200:21 232.115.18.38:278 SYN_RECV -
tcp 0 0 10.150.0.200:21 229.116.95.96:5122 SYN_RECV -
tcp 0 0 10.150.0.200:21 236.219.139.207:49162 SYN_RECV -
tcp 0 0 10.150.0.200:21 238.100.72.228:37899 SYN_RECV -

We can also count how many half-open connections are in the backlog queue at the moment. In the example below, 769 connections (for TELNET) in the SYN RECEIVED state are kept in the backlog queue.
# netstat -n -p TCP | grep SYN_RECV | grep :23 | wc -l
769
The other method for detecting SYN attacks is to print TCP statistics and look at the TCP parameters which count dropped connection requests. While under attack, the values of these parameters grow rapidly.
In this example we watch the value of the TcpHalfOpenDrop parameter on a Sun Solaris machine.
# netstat -s -P tcp | grep tcpHalfOpenDrop
tcpHalfOpenDrop = 473
It is important to note that every TCP port has its own backlog queue, but only one variable of the TCP/IP stack controls the size of backlog queues for all ports.
The backlog queue
The backlog queue is a large memory structure used to handle incoming packets with the SYN flag set until the moment the three-way handshake process is completed. An operating system allocates part of the system memory for every incoming connection. We know that every TCP port can handle a defined number of incoming requests. The backlog queue controls how many half-open connections can be handled by the operating system at the same time. When a maximum number of incoming connections is reached, subsequent requests are silently dropped by the operating system.
As mentioned before, when we detect a lot of connections in the SYN RECEIVED state, host is probably under a SYN flooding attack. Moreover, the source IP addresses of these incoming packets can be spoofed. To limit the effects of SYN attacks we should enable some built-in protection mechanisms. Additionally, we can sometimes use techniques such as increasing the backlog queue size and minimizing the total time where a pending connection is kept in allocated memory (in the backlog queue).
Built-in protection mechanisms
Operating system: Windows 2000
The most important parameter in Windows 2000 and also in Windows Server 2003 is SynAttackProtect. Enabling this parameter allows the operating system to handle incoming connections more efficiently. The protection can be set by adding a SynAttackProtect DWORD value to the following registry key:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
In general, when a SYN attack is detected the SynAttackProtect parameter changes the behavior of the TCP/IP stack. This allows the operating system to handle more SYN requests. It works by disabling some socket options, adding additional delays to connection indications and changing the timeout for connection requests.
When the value of SynAttackProtect is set to 1, the number of retransmissions is reduced and according to the vendor, the creation of a route cache entry is delayed until a connection is made. The recommended value of SynAttackProtect is 2, which additionally delays the indication of a connection to the Windows Socket until the three-way handshake is completed. During an attack, better performance in handling connections is achieved by disabling the use of a few parameters (these parameters are usually used by the system during the process of creating new connections). The TCPInitialRTT parameter, which defines the time of the first retransmission, will no longer work. It’s impossible to negotiate the window size value. Also, the scalable windows option is disabled on any socket.
As we can see, by enabling the SynAttackProtect parameter we don’t change the TCP/IP stack behavior until under a SYN attack. But even then, when SynAttackProtect starts to operate, the operating system can handle legitimate incoming connections.
The operating system enables protection against SYN attacks automatically when it detects that values of the following three parameters are exceeded. These parameters are TcpMaxHalfOpen, TcpMaxHalfOpenRetried and TcpMaxPortsExhausted.To change the values of these parameters, first we have to add them to the same registry key as we made for SynAttackProtect.
The TcpMaxHalfOpen registry entry defines the maximum number of SYN RECEIVED states which can be handled concurrently before SYN protection starts working. The recommended value of this parameter is 100 for Windows 2000 Server and 500 for Windows 2000 Advanced Server.
TcpMaxHalfOpenRetried defines the maximum number of half-open connections, for which the operating system has performed at least one retransmission, before SYN protection begins to operate. The recommended value is 80 for Windows 2000 Server, and 400 for Advanced Server.
The TcpMaxPortsExhausted registry entry defines the number of dropped SYN requests, after which the protection against SYN attacks starts to operate. Recommended value is 5.
Operating system: Linux RedHat
RedHat, like other Linux operating systems, has implemented a SYN cookies mechanism which can be enabled in the following way:
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Note that to make this change permanent we need to create a startup file that sets this variable. We must do the same operation for other UNIX variables described in this paper because the values for these variables will return to default upon system reboot.Optionally the same can be enabled in the sysctl.conf file in /etc directory by specifying the following:
net.ipv4.tcp_syncookies = 1
What are SYN cookies?
SYN cookies are an implementation of TCP that can respond to the TCP SYN request with a cookie. Following the descriptions above, in normal TCP implementation, when the server received a SYN packet, it responds with a SYN-ACK to acknowledge, and enter the TCP_SYN_RECV state (half-open connection) to wait the last ACK. The server uses a data structure describing all pending connections, and the data structure is of finite size. Therefore, the attacker may fill up the structure.
In the SYN cookies implementation of TCP, when the server received a SYN packet, it responds a SYN-ACK packet with the ACK sequence number calculated from source address, source port, source sequence, destination address, destination port and a secret seed. Then the server releases state. If an ACK comes from the client, the server can recalculate it to determine if it is a response to the former SYN-ACK. If it is, the server can directly enter the TCP_ESTABLISHED state and open the connection. In this way, the server avoids to keep half-open connections.This is just the basic idea of SYN cookies. There are still many mechanics in the implementation.
SYN cookies protection is especially useful when the system is under a SYN flood attack and source IP addresses of SYN packets are also forged (a SYN spoofing attack). This mechanism allows construction of a packet with the SYN and ACK flags set and which has a specially crafted initial sequence number (ISN), called a cookie. The value of the cookie is not a pseudo-random number generated by the system but instead is the result of a hash function. This hash result is generated from information like: source IP, source port, destination IP, destination port plus some secret values. During a SYN attack , when the backlog queue is about to fill, the system generates a response by sending back a packet with a cookie, instead of making an entry of half open connection in the queue and does n’t reject the connection. When a server receives a packet with the ACK flag set (the last stage of the three-way handshake process) then it verifies the cookie. When its value is correct, it creates the connection, even though there is no corresponding entry in the SYN queue. Then we know that it is a legitimate connection and that the source IP address was not spoofed. It is important to note that the SYN cookie mechanism works by not using the backlog queue at all, so we don’t need to change the backlog queue size.
Also note that the SYN cookies mechanism works only when the CONFIG_SYNCOOKIES option is set during kernel compilation.The next section will describe other useful methods of protection against SYN attacks. I would like to emphasize that under heavy SYN attacks (like Distributed SYN flooding attack) these methods may help but still not solve the problem.
Increasing the backlog queue
Under a SYN attack, we can modify the backlog queue to support more connections in the half-open state without denying access to legitimate clients. In some operating systems, the value of the backlog queue is very low and vendors often recommend increasing the SYN queue when a system is under attack.Increasing the backlog queue size requires that a system reserve additional memory resources for incoming requests. If a system has not enough memory for this operation, it will have an impact on system performance. We should also make sure that network applications like Apache or IIS can accept more connections.
Operating system: Windows 2000
Aside from described above TcpMaxHalfOpen and TcpMaxHalfOpenRetried variables, in Windows 2000 the number of connections handled in the half-open state can be set through a dynamic backlog. Configuration of this dynamic backlog is accomplished via the AFD.SYS driver. This kernel-mode driver is used to support Windows Socket applications like FTP and Telnet. To increase the number of half-open connections, AFD.SYS provides four registry entries. All of these values, corresponding to AFD.SYS, are located under the following registry key:
HKLM\System\CurrentControlSet\Services\AFD\Parameters
The EnableDynamicBacklog registry value is a global switch to enable or disable a dynamic backlog. Setting it to 1 enables the dynamic backlog queue.
MinimumDynamicBacklog controls the minimum number of free connections allowed on a single TCP port. If the number of free connections drops below this value, then additional free connections are created automatically. Recommended value is 20.
The MaximumDynamicBacklog registry value defines the sum of active half-open connections and the maximum number of free connections. When this value is exceeded, no more free connections will be created by a system. Microsoft suggests that this value should not exceed 20000.
The last DynamicBacklogGrowthDelta parameter controls the number of free connections to be created when additional connections are necessary. Recommended value: 10.
Operating system: Linux
A tcp_max_syn_backlog variable defines how many half-open connections can be kept by the backlog queue. For instance 256 is a total number of half-open connections handled in memory by Linux RedHat 7.3. The TCP/IP stack variables can be configured by sysctl or standard Unix commands. The following example shows how to change the default size of the backlog queue by the sysctl command:
# sysctl -w net.ipv4.tcp_max_syn_backlog=”2048″
Operating system: Sun Solaris
In Sun Solaris there are two parameters which control the maximum number of connections. The first parameter controls the total number of full connections. The second tcp_conn_req_max_q0 parameter defines how many half-open connections are allowed without the dropping of incoming requests. In Sun Solaris 8, the default value is set to 1024. Using the ndd command we can modify this value.
# ndd -set /dev/tcp tcp_conn_req_max_q0 2048
Operating system: HP-UX
In HP-UX, a tcp_syn_rcvd_max TCP/IP stack variable is responsible for control of the maximum number of half-open connections in the SYN RECEIVE state. In HP-UX 11.00 this value is set to 500. We can change this value by using the ndd command, similar to the one used in a Sun Solaris system.
# ndd -set /dev/tcp tcp_syn_rcvd_max 2048
Decreasing total time of handling connection request
As we know, SYN flooding/spoofing attacks are simply a series of SYN packets, mostly from forged IP addresses. In the last section we tried to increase the backlog queue. Now that our systems can handle more SYN requests, we should decrease the total time we keep half-open connections in the backlog queue. When a server receives a request, it immediately sends a response with the SYN and ACK flags set, puts this half-open connection into the backlog queue, and then waits for a packet with the ACK flag set from the client. When no response is received from the client, the server retransmits a response packet (with the SYN and ACK flags set) several times (depending on default value in each operating system) by giving the client a chance to send the ACK packet again. It is clear that when the source IP address of client was spoofed, the ACK packet will never arrive. After a few minutes the server removes this half-open connection. We can speed up this time of removing connections in the SYN RECEIVED state from the backlog queue by changing time of first retransmission and by changing the total number of retransmissions.
Another technique of protection against SYN attacks is switching off some TCP parameters that are always negotiated during the three-way handshake process. Some of these parameters are automatically turned off by mechanisms described in the first section (SynAttackProtect and Syncookies).Now, I will describe TCP/IP stack variables which allow a decrease in the time half-open connections are kept in the backlog queue.
Operating system: Windows 2000
In Windows 2000, the default time for a first retransmission is set to 3 seconds (3000 milliseconds) and can be changed by modifying the value of the TcpInitialRtt registry entry (for every interface). For example, to decrease time of a first retransmission to 2 seconds we have to set this registry value to 2000 milliseconds in decimal format. The number of retransmissions (packets with the SYN and ACK flags set) is controlled by a TcpMaxConnectResponseRetransmissions registry parameter which has to be added to HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters registry key.
Operating system: Sun Solaris
In this operating system it is impossible to turn off retransmissions of packets directly using the ndd command. Moreover, in Sun Solaris there are parameters which are non-configurable by ndd and which control the number of retransmissions (at least 3) and total time of packet retransmissions (at least 3 minutes).
Operating system: HP-UX
For HP-UX, the time spent handling half-open connections in the backlog queue is controlled by the tcp_ip_abort_cinterval parameter. By using the ndd command we can define how long a HP-UX operating system will be waiting for the ACK packet. We can control how many retransmissions will be performed indirectly by changing this value. We can change the time of a first retransmission by modifying tcp_rexmit_interval_initial. Intervals of subsequent retransmissions are controlled by two parameters: tcp_rexmit_interval and tcp_rexmit_interval_min. These three variables are the same as in a Sun Solaris operating system.
Summary
The methods of hardening the TCP/IP stack that are presented in this article make servers more resistant to SYN flooding and SYN spoofing – Denial of Service attacks. A modification of your default TCP/IP stack settings is also recommended during the process of securing of the operating system.