haproxy/tests/test-inspect-smtp.cfg

45 lines
1.5 KiB
INI
Raw Normal View History

[MAJOR] implement tcp request content inspection Some people need to inspect contents of TCP requests before deciding to forward a connection or not. A future extension of this demand might consist in selecting a server farm depending on the protocol detected in the request. For this reason, a new state CL_STINSPECT has been added on the client side. It is immediately entered upon accept() if the statement "tcp-request inspect-delay <xxx>" is found in the frontend configuration. Haproxy will then wait up to this amount of time trying to find a matching ACL, and will either accept or reject the connection depending on the "tcp-request content <action> {if|unless}" rules, where <action> is either "accept" or "reject". Note that it only waits that long if no definitive verdict can be found earlier. That generally implies calling a fetch() function which does not have enough information to decode some contents, or a match() function which only finds the beginning of what it's looking for. It is only at the ACL level that partial data may be processed as such, because we need to distinguish between MISS and FAIL *before* applying the term negation. Thus it is enough to add "| ACL_PARTIAL" to the last argument when calling acl_exec_cond() to indicate that we expect ACL_PAT_MISS to be returned if some data is missing (for fetch() or match()). This is the only case we may return this value. For this reason, the ACL check in process_cli() has become a lot simpler. A new ACL "req_len" of type "int" has been added. Right now it is already possible to drop requests which talk too early (eg: for SMTP) or which don't talk at all (eg: HTTP/SSL). Also, the acl fetch() functions have been extended in order to permit reporting of missing data in case of fetch failure, using the ACL_TEST_F_MAY_CHANGE flag. The default behaviour is unchanged, and if no rule matches, the request is accepted. As a side effect, all layer 7 fetching functions have been cleaned up so that they now check for the validity of the layer 7 pointer before dereferencing it.
2008-07-14 21:54:42 +00:00
# This is a test configuration. It listens on port 8025, waits for an incoming
# connection, and applies the following rules :
# - if the address is in the white list, then accept it and forward the
# connection to the server (local port 25)
# - if the address is in the black list, then immediately drop it
# - otherwise, wait up to 35 seconds. If the client talks during this time,
[MAJOR] implement tcp request content inspection Some people need to inspect contents of TCP requests before deciding to forward a connection or not. A future extension of this demand might consist in selecting a server farm depending on the protocol detected in the request. For this reason, a new state CL_STINSPECT has been added on the client side. It is immediately entered upon accept() if the statement "tcp-request inspect-delay <xxx>" is found in the frontend configuration. Haproxy will then wait up to this amount of time trying to find a matching ACL, and will either accept or reject the connection depending on the "tcp-request content <action> {if|unless}" rules, where <action> is either "accept" or "reject". Note that it only waits that long if no definitive verdict can be found earlier. That generally implies calling a fetch() function which does not have enough information to decode some contents, or a match() function which only finds the beginning of what it's looking for. It is only at the ACL level that partial data may be processed as such, because we need to distinguish between MISS and FAIL *before* applying the term negation. Thus it is enough to add "| ACL_PARTIAL" to the last argument when calling acl_exec_cond() to indicate that we expect ACL_PAT_MISS to be returned if some data is missing (for fetch() or match()). This is the only case we may return this value. For this reason, the ACL check in process_cli() has become a lot simpler. A new ACL "req_len" of type "int" has been added. Right now it is already possible to drop requests which talk too early (eg: for SMTP) or which don't talk at all (eg: HTTP/SSL). Also, the acl fetch() functions have been extended in order to permit reporting of missing data in case of fetch failure, using the ACL_TEST_F_MAY_CHANGE flag. The default behaviour is unchanged, and if no rule matches, the request is accepted. As a side effect, all layer 7 fetching functions have been cleaned up so that they now check for the validity of the layer 7 pointer before dereferencing it.
2008-07-14 21:54:42 +00:00
# drop the connection.
# - then accept the connection if it passes all the tests.
#
# Note that the rules are evaluated at every new chunk of data read, and at
# delay expiration. Rules which apply to incomplete data don't match as long
# as the timer has not expired.
listen block-fake-mailers
log 127.0.0.1:514 local0
option tcplog
mode tcp
bind :8025
timeout client 60s
timeout server 60s
timeout queue 60s
timeout connect 5s
[MAJOR] implement tcp request content inspection Some people need to inspect contents of TCP requests before deciding to forward a connection or not. A future extension of this demand might consist in selecting a server farm depending on the protocol detected in the request. For this reason, a new state CL_STINSPECT has been added on the client side. It is immediately entered upon accept() if the statement "tcp-request inspect-delay <xxx>" is found in the frontend configuration. Haproxy will then wait up to this amount of time trying to find a matching ACL, and will either accept or reject the connection depending on the "tcp-request content <action> {if|unless}" rules, where <action> is either "accept" or "reject". Note that it only waits that long if no definitive verdict can be found earlier. That generally implies calling a fetch() function which does not have enough information to decode some contents, or a match() function which only finds the beginning of what it's looking for. It is only at the ACL level that partial data may be processed as such, because we need to distinguish between MISS and FAIL *before* applying the term negation. Thus it is enough to add "| ACL_PARTIAL" to the last argument when calling acl_exec_cond() to indicate that we expect ACL_PAT_MISS to be returned if some data is missing (for fetch() or match()). This is the only case we may return this value. For this reason, the ACL check in process_cli() has become a lot simpler. A new ACL "req_len" of type "int" has been added. Right now it is already possible to drop requests which talk too early (eg: for SMTP) or which don't talk at all (eg: HTTP/SSL). Also, the acl fetch() functions have been extended in order to permit reporting of missing data in case of fetch failure, using the ACL_TEST_F_MAY_CHANGE flag. The default behaviour is unchanged, and if no rule matches, the request is accepted. As a side effect, all layer 7 fetching functions have been cleaned up so that they now check for the validity of the layer 7 pointer before dereferencing it.
2008-07-14 21:54:42 +00:00
tcp-request inspect-delay 35s
[MAJOR] implement tcp request content inspection Some people need to inspect contents of TCP requests before deciding to forward a connection or not. A future extension of this demand might consist in selecting a server farm depending on the protocol detected in the request. For this reason, a new state CL_STINSPECT has been added on the client side. It is immediately entered upon accept() if the statement "tcp-request inspect-delay <xxx>" is found in the frontend configuration. Haproxy will then wait up to this amount of time trying to find a matching ACL, and will either accept or reject the connection depending on the "tcp-request content <action> {if|unless}" rules, where <action> is either "accept" or "reject". Note that it only waits that long if no definitive verdict can be found earlier. That generally implies calling a fetch() function which does not have enough information to decode some contents, or a match() function which only finds the beginning of what it's looking for. It is only at the ACL level that partial data may be processed as such, because we need to distinguish between MISS and FAIL *before* applying the term negation. Thus it is enough to add "| ACL_PARTIAL" to the last argument when calling acl_exec_cond() to indicate that we expect ACL_PAT_MISS to be returned if some data is missing (for fetch() or match()). This is the only case we may return this value. For this reason, the ACL check in process_cli() has become a lot simpler. A new ACL "req_len" of type "int" has been added. Right now it is already possible to drop requests which talk too early (eg: for SMTP) or which don't talk at all (eg: HTTP/SSL). Also, the acl fetch() functions have been extended in order to permit reporting of missing data in case of fetch failure, using the ACL_TEST_F_MAY_CHANGE flag. The default behaviour is unchanged, and if no rule matches, the request is accepted. As a side effect, all layer 7 fetching functions have been cleaned up so that they now check for the validity of the layer 7 pointer before dereferencing it.
2008-07-14 21:54:42 +00:00
acl white_list src 127.0.0.2
acl black_fast src 127.0.0.3 # those ones are immediately rejected
acl black_slow src 127.0.0.4 # those ones are rejected after a delay
[MAJOR] implement tcp request content inspection Some people need to inspect contents of TCP requests before deciding to forward a connection or not. A future extension of this demand might consist in selecting a server farm depending on the protocol detected in the request. For this reason, a new state CL_STINSPECT has been added on the client side. It is immediately entered upon accept() if the statement "tcp-request inspect-delay <xxx>" is found in the frontend configuration. Haproxy will then wait up to this amount of time trying to find a matching ACL, and will either accept or reject the connection depending on the "tcp-request content <action> {if|unless}" rules, where <action> is either "accept" or "reject". Note that it only waits that long if no definitive verdict can be found earlier. That generally implies calling a fetch() function which does not have enough information to decode some contents, or a match() function which only finds the beginning of what it's looking for. It is only at the ACL level that partial data may be processed as such, because we need to distinguish between MISS and FAIL *before* applying the term negation. Thus it is enough to add "| ACL_PARTIAL" to the last argument when calling acl_exec_cond() to indicate that we expect ACL_PAT_MISS to be returned if some data is missing (for fetch() or match()). This is the only case we may return this value. For this reason, the ACL check in process_cli() has become a lot simpler. A new ACL "req_len" of type "int" has been added. Right now it is already possible to drop requests which talk too early (eg: for SMTP) or which don't talk at all (eg: HTTP/SSL). Also, the acl fetch() functions have been extended in order to permit reporting of missing data in case of fetch failure, using the ACL_TEST_F_MAY_CHANGE flag. The default behaviour is unchanged, and if no rule matches, the request is accepted. As a side effect, all layer 7 fetching functions have been cleaned up so that they now check for the validity of the layer 7 pointer before dereferencing it.
2008-07-14 21:54:42 +00:00
tcp-request content accept if white_list
tcp-request content reject if black_fast
tcp-request content reject if black_slow WAIT_END
tcp-request content reject if REQ_CONTENT
# note that it is possible to wait for the end of the analysis period
# before rejecting undesired contents
# tcp-request content reject if REQ_CONTENT WAIT_END
# on Linux+transparent proxy patch, it's useful to reuse the client'IP
# source 0.0.0.0 usesrc clientip
[MAJOR] implement tcp request content inspection Some people need to inspect contents of TCP requests before deciding to forward a connection or not. A future extension of this demand might consist in selecting a server farm depending on the protocol detected in the request. For this reason, a new state CL_STINSPECT has been added on the client side. It is immediately entered upon accept() if the statement "tcp-request inspect-delay <xxx>" is found in the frontend configuration. Haproxy will then wait up to this amount of time trying to find a matching ACL, and will either accept or reject the connection depending on the "tcp-request content <action> {if|unless}" rules, where <action> is either "accept" or "reject". Note that it only waits that long if no definitive verdict can be found earlier. That generally implies calling a fetch() function which does not have enough information to decode some contents, or a match() function which only finds the beginning of what it's looking for. It is only at the ACL level that partial data may be processed as such, because we need to distinguish between MISS and FAIL *before* applying the term negation. Thus it is enough to add "| ACL_PARTIAL" to the last argument when calling acl_exec_cond() to indicate that we expect ACL_PAT_MISS to be returned if some data is missing (for fetch() or match()). This is the only case we may return this value. For this reason, the ACL check in process_cli() has become a lot simpler. A new ACL "req_len" of type "int" has been added. Right now it is already possible to drop requests which talk too early (eg: for SMTP) or which don't talk at all (eg: HTTP/SSL). Also, the acl fetch() functions have been extended in order to permit reporting of missing data in case of fetch failure, using the ACL_TEST_F_MAY_CHANGE flag. The default behaviour is unchanged, and if no rule matches, the request is accepted. As a side effect, all layer 7 fetching functions have been cleaned up so that they now check for the validity of the layer 7 pointer before dereferencing it.
2008-07-14 21:54:42 +00:00
balance roundrobin
server mail 127.0.0.1:25