In order to block the Skype by using Squid 3.0, here is guide from squid web site.
# Skype
acl numeric_IPs dstdom_regex ^(([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)|(\[([0-9af]+)?:([0-9af:]+)?:([0-9af]+)?\])):443
acl Skype_UA browser ^skype^
http_access deny numeric_IPS
http_access deny Skype_UA
• Recent releases of Skype have been evading the above restriction by not sending their User-Agent headers and using domain names. The following can be used to catch those installs, but be aware it will likely also catch other agents.
acl validUserAgent browser \S+
http_access deny !validUserAgent
Tuesday, January 25, 2011
Saturday, January 15, 2011
Hardening Sendmail
Connection Controlling
FEATURE(`access_db')dnl
FEATURE(`delay_checks', `friend')dnl
FEATURE(`ratecontrol', `nodelay',`terminate')dnl
FEATURE(`conncontrol', `nodelay',`terminate')dnl
After the already existing line "FEATURE(`access_db')dnl" I added the lines to enable rate and connection-controlling.
The option "nodelay" is important, because I am using the delay-checks-feature, and these checks are not to be delayed.
The "terminate"-option tells sendmail to kill all connections exceeding the later defined limits with a temporary error-message. The properly configured and standard-compliant smtp-client will try again later, spammers usually don't.
The rate-control feature enables control over how often a single host is allowed to connect per a defined window. It was introduce by sendmail version 8.13.0, and uses the access.db for defining the limits for single hosts, groups of hosts or all hosts.
The window-size is defined using the this option:
define(`confCONNECTION_RATE_WINDOW_SIZE',`window')dnl
with a default-value for window of "60s" (60 seconds).
My access.db-entries for the rate-control-feature look like this:
ClientRate:localhost 0
ClientRate:localhost.localdomain 0
ClientRate:127.0.0.1 0
ClientRate: 5
The first three lines tell sendmail to ingore rate-limits for the localhost, and the last line imposes a limit of 5 connections per window for all hosts.
In cases of a DDoS, it might not be sufficient to limit the connections of a single host per minute, because a DDoS comes from multiple hosts at the same time. This is why Sendmail come with another option:
define(`confCONNECTION_RATE_THROTTLE', `5')dnl
This defines the overall number of concurrent connection the server accepts per second, before queuing incoming connection-request regardless of the host. The connections will not be rejected but stalled until the next second. This means that for the above example that when 20 connection-requests arrive, the first five (1-5) are processed in second one, the second five (6-10) in second two, the third five (11-15) in second three, and the final five (16-20) in second four.
The conn-control feature enables control over the number of concurrent connections a single host is allowed to run simultaneously. Like rate-control, this feature was introduced with Sendmail 8.13, and the access.db is used to define settings for single-hosts, host-ranges and "all hosts", too.
My access.db-entries for the conn-control-feature look like this:
ClientConn:localhost 0
ClientConn:localhost.localdomain 0
ClientConn:127.0.0.1 0
ClientConn: 3
The entries are read similar to rate-control. The last line defines a default of 3 concurrent connections, the first three disable the feature for localhost.
Greeting Pause
A common technique of spammers, trojans and viruses is the so-called slamming. The SMTP-Standard requires the client to wait with the HELO/EHLO-Command until the server has sent its greeting line. Slamming is to ignore this, and to start sending immediately.
FEATURE(`greet_pause', `2000')dnl
With the above feature, Sendmail can be configured to delay the sending of this greeting. The value is in milliseconds, so in the example above, the greeting-pause would be two seconds. A client issuing the HELO/EHLO during this pause will cause Sendmail to answer with
554 smtp.nifelhei.info not accepting messages
and the greeting will not be send. Sendmail will log such attempts with a message like
rejecting messages from due to pre-greeting traffic.
and terminate the connection.
You can use the access.db again to define host-specific greeting-pause times, or to exclude certain hosts from the pause. The following example would exclude localhost from the delay. You can use this to whitelist smtp-servers who do slamming but are otherwise "friendly".
GreetPause:localhost 0
GreetPause:localhost.localdomain 0
GreetPause:127.0.0.1 0
Please note:
RFC 2821 specifies 5 minutes as the maximum timeout for the initial connection greeting. Therefore, if you specify a time longer than 300000 milliseconds (i.e. 5 minutes), sendmail will not wait longer than 5 minutes, to maintain RFC compliance.
Recipient-Controlling
After setting up the controlling mechanisms for incoming connections, there is a another level of control that can be applied. Many spammers try to send a single mail with hundreds of recipients. This is also known as "recipient flooding". Sendmail can be configured to limit the number of recipients a message may have, as well throttling down all those clients who try to add more recipient than a certain threshold by pausing a hardcoded full second between each accepted recipient. The options are as follows:
define(`confBAD_RCPT_THROTTLE', `2')dnl
define(`confMAX_RCPTS_PER_MESSAGE', `25')dnl
BAD_RCPT_THROTTLE sets the threshold which invokes the one-second-delay. For the example above this means that with the third RCPT TO: sendmail will pause one full second, before sending the response.
MAX_RCPTS_PER_MESSAGE limits the absolute maximum number of recipients for each message to the value given (25 for the above example). Every RCPT TO: exceeding this number will be rejected with an appropriate message. The standard-compliant server will collect the rejected RCPT TOs and requeue the message for all yet outstanding recipients. (Yes, spammers won't.)
Timeouts
Sendmail, in order to get as many as possible mails through, has very generous timeout-defaults. These values are often measured in days, where today seconds or minutes would suffice. Long timeouts mean long bound resources for probably unsolicited connections. I have defined much shorter values for several timeouts:
define(`confTO_INITIAL', `30s')dnl
define(`confTO_CONNECT', `30s')dnl
define(`confTO_ACONNECT', `1m')dnl
define(`confTO_ICONNECT', `30s')dnl
define(`confTO_HELO', `30s')dnl
define(`confTO_MAIL', `30s')dnl
define(`confTO_RCPT', `30s')dnl
define(`confTO_DATAINIT', `1m')dnl
define(`confTO_DATABLOCK', `1m')dnl
define(`confTO_DATAFINAL', `1m')dnl
define(`confTO_RSET', `30s')dnl
define(`confTO_QUIT', `30s')dnl
define(`confTO_MISC', `30s')dnl
define(`confTO_COMMAND', `30s')dnl
define(`confTO_CONTROL', `30s')dnl
define(`confTO_LHLO', `30s')dnl
define(`confTO_AUTH', `30s')dnl
define(`confTO_STARTTLS', `30s')dnl
M4 approach
/etc/mail/sendmail.mc
MaxDaemonChildren
define(`confMAX_DAEMON_CHILDREN‘,’30‘)dnl
MaxMessageSize
define(`confMAX_MESSAGE_SIZE‘,’10000000‘)dnl
ConnectionRateThrottle
define(`confCONNECTION_RATE_THROTTLE‘,’10‘)dnl
MaxRecipientsPerMessage
define(`confMAX_RCPTS_PER_MESSAGE‘,’1000‘)dnl
FEATURE(`access_db')dnl
FEATURE(`delay_checks', `friend')dnl
FEATURE(`ratecontrol', `nodelay',`terminate')dnl
FEATURE(`conncontrol', `nodelay',`terminate')dnl
After the already existing line "FEATURE(`access_db')dnl" I added the lines to enable rate and connection-controlling.
The option "nodelay" is important, because I am using the delay-checks-feature, and these checks are not to be delayed.
The "terminate"-option tells sendmail to kill all connections exceeding the later defined limits with a temporary error-message. The properly configured and standard-compliant smtp-client will try again later, spammers usually don't.
The rate-control feature enables control over how often a single host is allowed to connect per a defined window. It was introduce by sendmail version 8.13.0, and uses the access.db for defining the limits for single hosts, groups of hosts or all hosts.
The window-size is defined using the this option:
define(`confCONNECTION_RATE_WINDOW_SIZE',`window')dnl
with a default-value for window of "60s" (60 seconds).
My access.db-entries for the rate-control-feature look like this:
ClientRate:localhost 0
ClientRate:localhost.localdomain 0
ClientRate:127.0.0.1 0
ClientRate: 5
The first three lines tell sendmail to ingore rate-limits for the localhost, and the last line imposes a limit of 5 connections per window for all hosts.
In cases of a DDoS, it might not be sufficient to limit the connections of a single host per minute, because a DDoS comes from multiple hosts at the same time. This is why Sendmail come with another option:
define(`confCONNECTION_RATE_THROTTLE', `5')dnl
This defines the overall number of concurrent connection the server accepts per second, before queuing incoming connection-request regardless of the host. The connections will not be rejected but stalled until the next second. This means that for the above example that when 20 connection-requests arrive, the first five (1-5) are processed in second one, the second five (6-10) in second two, the third five (11-15) in second three, and the final five (16-20) in second four.
The conn-control feature enables control over the number of concurrent connections a single host is allowed to run simultaneously. Like rate-control, this feature was introduced with Sendmail 8.13, and the access.db is used to define settings for single-hosts, host-ranges and "all hosts", too.
My access.db-entries for the conn-control-feature look like this:
ClientConn:localhost 0
ClientConn:localhost.localdomain 0
ClientConn:127.0.0.1 0
ClientConn: 3
The entries are read similar to rate-control. The last line defines a default of 3 concurrent connections, the first three disable the feature for localhost.
Greeting Pause
A common technique of spammers, trojans and viruses is the so-called slamming. The SMTP-Standard requires the client to wait with the HELO/EHLO-Command until the server has sent its greeting line. Slamming is to ignore this, and to start sending immediately.
FEATURE(`greet_pause', `2000')dnl
With the above feature, Sendmail can be configured to delay the sending of this greeting. The value is in milliseconds, so in the example above, the greeting-pause would be two seconds. A client issuing the HELO/EHLO during this pause will cause Sendmail to answer with
554 smtp.nifelhei.info not accepting messages
and the greeting will not be send. Sendmail will log such attempts with a message like
rejecting messages from
and terminate the connection.
You can use the access.db again to define host-specific greeting-pause times, or to exclude certain hosts from the pause. The following example would exclude localhost from the delay. You can use this to whitelist smtp-servers who do slamming but are otherwise "friendly".
GreetPause:localhost 0
GreetPause:localhost.localdomain 0
GreetPause:127.0.0.1 0
Please note:
RFC 2821 specifies 5 minutes as the maximum timeout for the initial connection greeting. Therefore, if you specify a time longer than 300000 milliseconds (i.e. 5 minutes), sendmail will not wait longer than 5 minutes, to maintain RFC compliance.
Recipient-Controlling
After setting up the controlling mechanisms for incoming connections, there is a another level of control that can be applied. Many spammers try to send a single mail with hundreds of recipients. This is also known as "recipient flooding". Sendmail can be configured to limit the number of recipients a message may have, as well throttling down all those clients who try to add more recipient than a certain threshold by pausing a hardcoded full second between each accepted recipient. The options are as follows:
define(`confBAD_RCPT_THROTTLE', `2')dnl
define(`confMAX_RCPTS_PER_MESSAGE', `25')dnl
BAD_RCPT_THROTTLE sets the threshold which invokes the one-second-delay. For the example above this means that with the third RCPT TO: sendmail will pause one full second, before sending the response.
MAX_RCPTS_PER_MESSAGE limits the absolute maximum number of recipients for each message to the value given (25 for the above example). Every RCPT TO: exceeding this number will be rejected with an appropriate message. The standard-compliant server will collect the rejected RCPT TOs and requeue the message for all yet outstanding recipients. (Yes, spammers won't.)
Timeouts
Sendmail, in order to get as many as possible mails through, has very generous timeout-defaults. These values are often measured in days, where today seconds or minutes would suffice. Long timeouts mean long bound resources for probably unsolicited connections. I have defined much shorter values for several timeouts:
define(`confTO_INITIAL', `30s')dnl
define(`confTO_CONNECT', `30s')dnl
define(`confTO_ACONNECT', `1m')dnl
define(`confTO_ICONNECT', `30s')dnl
define(`confTO_HELO', `30s')dnl
define(`confTO_MAIL', `30s')dnl
define(`confTO_RCPT', `30s')dnl
define(`confTO_DATAINIT', `1m')dnl
define(`confTO_DATABLOCK', `1m')dnl
define(`confTO_DATAFINAL', `1m')dnl
define(`confTO_RSET', `30s')dnl
define(`confTO_QUIT', `30s')dnl
define(`confTO_MISC', `30s')dnl
define(`confTO_COMMAND', `30s')dnl
define(`confTO_CONTROL', `30s')dnl
define(`confTO_LHLO', `30s')dnl
define(`confTO_AUTH', `30s')dnl
define(`confTO_STARTTLS', `30s')dnl
M4 approach
/etc/mail/sendmail.mc
MaxDaemonChildren
define(`confMAX_DAEMON_CHILDREN‘,’30‘)dnl
MaxMessageSize
define(`confMAX_MESSAGE_SIZE‘,’10000000‘)dnl
ConnectionRateThrottle
define(`confCONNECTION_RATE_THROTTLE‘,’10‘)dnl
MaxRecipientsPerMessage
define(`confMAX_RCPTS_PER_MESSAGE‘,’1000‘)dnl
Monday, January 3, 2011
TOP TEN TIPS FOR SMALL AND MEDIUM-SIZED BUSINESSES
The following constitute the essentials of defence for your IT security:
- carrying out basic screening checks on all your employees and contractors
- having short, clearly documented security policies and procedures
- carrying out basic security awareness training with your employees
- implementing patches for software vulnerabilities as soon as possible
- knowing who is accessing your systems, and why
- using strong passwords and changing them regularly
- making sure your anti-virus system is updated every few days
- using a content-filtering system to guard against spam and phishing
- using a firewall, especially if you have broadband Internet access
- using an ‘all-in-one’ network defence system with a small network
- carrying out basic screening checks on all your employees and contractors
- having short, clearly documented security policies and procedures
- carrying out basic security awareness training with your employees
- implementing patches for software vulnerabilities as soon as possible
- knowing who is accessing your systems, and why
- using strong passwords and changing them regularly
- making sure your anti-virus system is updated every few days
- using a content-filtering system to guard against spam and phishing
- using a firewall, especially if you have broadband Internet access
- using an ‘all-in-one’ network defence system with a small network
Subscribe to:
Posts (Atom)