• Aucun résultat trouvé

Fingerprint Scrambling

Dans le document A valuable extension to the (Page 131-134)

The best way to defend against fingerprinting attempts is to modify the defining characteristics of network listening hosts and services to further masquerade the identity of the system. Change configurable values of services to emulate those of different but similar services on a completely separate architecture.

The more ways you can mask the identity of the operating system and services, the less likely their true identity will be easily discovered. When making these modifications, however, stay with a single theme so inconsistencies are minimized. To make a Linux server appear to be a Microsoft Windows Server, for example, change as many items as possible to make it appear as a Windows server, keeping in mind the type and versions of applications that correspond with the system to be emulated.

In the case of a web server, the next items you’ll want to modify are the error pages.

Change all error pages so the web server emulates a desired environment, or make them purposely ambiguous in the event any kind of error occurs (client navigation errors, script crashes, and so on). You can do this in the httpd.conf file. Here is an example of how to configure custom error pages from apache.org:

ErrorDocument 500 /cgi-bin/crash-recover

ErrorDocument 500 "Sorry, our script crashed. Oh dear"

ErrorDocument 500 http://xxx/

ErrorDocument 404 /Lame_excuses/not_found.html

ErrorDocument 401 /Subscription/how_to_subscribe.html

The next step would be to copy error pages from a Windows IIS Server or other service and platform combination to the Linux Apache Server and configure the above

Chapter 5: Data Networks Security

97

icmp_echo_ignore_all ipfrag_low_thresh tcp_max_tw_buckets icmp_echo_ignore_

broadcasts

ipfrag_max_dist tcp_mem icmp_ignore_bogus_

error_responses

ipfrag_secret_interval tcp_orphan_retries icmp_ratelimit ipfrag_time tcp_reordering

icmp_ratemask neigh tcp_retrans_collapse

igmp_max_memberships netfilter tcp_retries1

igmp_max_msf route tcp_retries2

inet_peer_gc_maxtime tcp_abort_on_overflow tcp_rfc1337 inet_peer_gc_mintime tcp_adv_win_scale tcp_rmem inet_peer_maxttl tcp_app_win tcp_sack

inet_peer_minttl tcp_dsack tcp_stdurg

inet_peer_threshold tcp_ecn tcp_syn_retries

ip_autoconfig tcp_fack tcp_synack_retries

ip_conntrack_max tcp_fin_timeout tcp_syncookies

ip_default_ttl tcp_frto tcp_timestamps

ip_dynaddr tcp_keepalive_intvl tcp_tw_recycle ip_forward tcp_keepalive_probes tcp_tw_reuse ip_local_port_range tcp_keepalive_time tcp_westwood ip_no_pmtu_disc tcp_low_latency tcp_window_scaling ip_nonlocal_bind tcp_max_orphans tcp_wmem

ipfrag_high_thresh tcp_max_syn_backlog

Table 5-1 IPv4 Confi gurable Parameters

mappings to point to the new obfuscated files. On a Windows 2003 IIS 6.0 server, the default error pages can be found in C:\Windows\Help\iisHelp\common\.

Modifying the error pages, however, is just the beginning. You can also modify IPv4 network protocol parameters to change the way systems communicate on the network. They can be configured to behave in a manner similar to a different operating system or be modified to provide maximum protection against external attacks. In either case, the end result is to obfuscate the identity of the operating system, but the latter suggestion provides more inherent value. Table 5-1 lists the options that can be configured for IPv4 in Linux.

The next example shows a brief illustration of some parameters you can modify to prevent a SYN flood attack, as well as ways to change the TCP fingerprint of the respective system.

tcp_max_syn_backlog This parameter defines how many half-open connections can be retained by the backlog queue. Half-open connections are those for which a SYN packet has been received, a SYN/ACK packet has been sent, and an ACK packet has not yet been received. You can easily create a denial of service situation if the tcp_max_syn_

backlog setting is low and the timeout value is high. Once the backlog value has been reached, the system cannot receive any more connections until the existing ones are either established or timed out. The tcp_max_syn_backlog should be set to 2048. This setting can be configured with the following command line, depending on the Linux distribution:

# sysctl -w net.ipv4.tcp_max_syn_backlog="2048"

tcp_synack_retries This parameter controls the number of SYN/ACK retransmissions.

By default, this value is set to 5 in most Linux distributions (which causes half-open connections to be removed after 3 minutes if no valid ACK packet is received). However, you can be reduce this value to allow shorter timeouts. The following values apply:

value = 5 (3 minutes), value = 3 (45 seconds), value = 2 (21 seconds), value = 1 (9 seconds).

Take care not to set the values too low, as low values will create a denial of service by design if legitimate network traffic from remote destinations takes longer to traverse the Internet than the configured retransmission value. This setting can be configured with the following command line, depending on the Linux distribution:

# sysctl -w net.ipv4.tcp_ synack_retries ="3"

tcp_syncookies This parameter is very useful in thwarting SYN Flood attacks, especially when source addresses are spoofed. Changing this setting to 1 bypasses the backlog queue by creating a cookie based on the connection socket. More specifically, when a SYN packet is received, a SYN/ACK packet is constructed having a specially crafted initial sequence number (ISN), also called a cookie. Unlike the default configuration, the ISN is not a pseudo-random number but is generated by hashing the connection socket (source address, source port, destination address, and destination port) with some secret values. The system will not actually open a connection until it receives an ACK packet having the respective cookie. Therefore, spoofed SYN packets cannot monopolize

Chapter 5: Data Networks Security

99

connections on the server. This setting can be configured with the following command line, depending on the Linux distribution:

# sysctl -w net.ipv4.tcp_ syncookies="1"

If the configuration setting is of no interest or not feasible, several firewalls are on the market that have an innate ability to scramble the fingerprints of the hosts they protect, as well as defend against attacks like SYN Floods. Checkpoint Smart Defense module has this built-in ability, and enabling it is as simple as clicking a button and applying the policy.

IPTables, which is actually a configuration and maintenance tool for the NetFilter framework and is already included in nearly all default Linux distributions, can also be modified to scramble fingerprints. The website http://en.hakin9.org has a lengthy but great whitepaper on fingerprint scrambling. Written by Jaros Sajko and published on August 1, 2006, it provides detailed instructions on how to create custom IPTables extensions to perform fingerprint scrambling.

Dans le document A valuable extension to the (Page 131-134)