Fast and Slow ACLs

Some ACL types require information which may not be already available to Squid. Checking them requires suspending work on the current request, querying some external source, and resuming work when the needed information becomes available. This is for example the case for DNS, authenticators or external authorization scripts. ACLs can thus be divided in FAST ACLs, which do not require going to external sources to be fulfilled, and SLOW ACLs, which do.

Fast ACLs include (as of squid 3.1.0.7):

• all (built-in)
• src
• dstdomain
• dstdom_regex
• myip
• arp
• src_as
• peername
• time
• url_regex
• urlpath_regex
• port
• myport
• myportname
• proto
• method
• http_status {R}
• browser
• referer_regex
• snmp_community
• maxconn
• max_user_ip
• req_mime_type
• req_header
• rep_mime_type {R}
• user_cert
• ca_cert

Slow ACLs include:

• dst
• dst_as
• srcdomain
• srcdom_regex
• ident
• ident_regex
• proxy_auth
• proxy_auth_regex
• external
• ext_user
• ext_user_regex

This list may be incomplete or out-of-date. See your squid.conf.documented file for details. ACL types marked with {R} are reply ACLs, see the dedicated FAQ chapter.

Squid caches the results of ACL lookups whenever possible, thus slow ACLs will not always need to go to the external data-source.

Knowing the behaviour of an ACL type is relevant because not all ACL matching directives support all kinds of ACLs. Some check-points will not suspend the request: they allow (or deny) immediately. If a SLOW acl has to be checked, and the results of the check are not cached, the corresponding ACL result will be as if it didn't match. In other words, such ACL types are in general not reliable in all access check clauses.

The following are SLOW access clauses:

• http_access
• adapted_http_access (2.x call this http_access2)
• http_reply_access
• url_rewrite_access
• storeurl_access
• location_rewrite_access
• always_direct
• never_direct
• cache

These are instead FAST access clauses:

• icp_access
• htcp_access
• htcp_clr_access
• miss_access
• ident_lookup_access
• reply_body_max_size {R}
• authenticate_ip_shortcircuit_access
• log_access
• header_access
• delay_access
• snmp_access
• cache_peer_access
• ssl_bump
• sslproxy_cert_error
• follow_x_forwarded_for

Thus the safest course of action is to only use fast ACLs in fast access clauses, and any kind of ACL in slow access clauses.

Удалить много conntrack соединений оптом

First, use conntrack to correctly identify your entries:

    conntrack -L -s 172.16.1.45 -d 123.123.123.123

This should display any connections that came from the internal IP of 172.16.1.45 destined to 123.123.123.123

Once you have confirmed the connections shown are the ones you with to delete/reset, paste the following after the command from above:

    conntrack -L -s 172.16.1.45 -d 123.123.123.123 | sed 's/=/ /g' | awk '{print("conntrack -D -s "$6" -d "$8" -p "$1" --sport="$10" --dport="$12)}'

This will print a list of the commands that would run to delete the connections. Replace "print" with "system" to execute the deletions:

    conntrack -L -s 172.16.1.45 -d 123.123.123.123 | sed 's/=/ /g' | awk '{system("conntrack -D -s "$6" -d "$8" -p "$1" --sport="$10" --dport="$12)}'

Finally, re-run the list command to see that all the entries have been removed:

    conntrack -L -s 172.16.1.45 -d 123.123.123.123

And you're done!

http://www.muchtall.com/2008/11/12/5/

Rsyslog

Rate-limit

Feb 13 10:32:17 gw207 rsyslogd-2177: imuxsock begins to drop messages from pid 2178 due to rate-limiting
Feb 13 10:32:19 gw207 rsyslogd-2177: imuxsock lost 108 messages from pid 2178 due to rate-limiting
Feb 13 10:32:43 gw207 rsyslogd-2177: imuxsock begins to drop messages from pid 2178 due to rate-limiting
Feb 13 10:32:47 gw207 rsyslogd-2177: imuxsock lost 24 messages from pid 2178 due to rate-limiting

$SystemLogRateLimitInterval [number] default 5
$SystemLogRateLimitBurst [number] default 200

This means in plain words, that rate limiting will take effect if more than 200 messages occur in 5 seconds.

http://www.rsyslog.com/tag/rate-limiting/

Centralizing the audit log

active = yes

 direction = out
 path = builtin_syslog
 type = builtin 
 args = LOG_INFO
 format = string

and on the receiving rsyslog server, I configure the following to collect all audit events into one file per day:

 # Log linux audit log on original format:
 $template HostAudit, "/var/log/audit/%$YEAR%/%$MONTH%/%$DAY%/audit.log"
 $template auditFormat, "%msg%\n"
 :programname,   isequal,        "audispd"       -?HostAudit;auditFormat
 :programname,   isequal,        "audispd"       ~

http://wiki.rsyslog.com/index.php/Centralizing_the_audit_log

IPSEC Mikrotik(server) + WinXP(client)

Mikrotik  v 6.21 (server)

/ip ipsec proposal
set [ find default=yes ] enc-algorithms=3des auth-algorithms=sha1

/ip pool
add name=vpn_pool ranges=192.168.4.200-192.168.4.254

/interface l2tp-server server

set default-profile=profile_l2tp enabled=yes ipsec-secret=243211 use-ipsec=yes

(ipser peer  создается автоматический)

/ip address

add address=10.10.10.1/30 interface=ether4 network=10.10.10.0

/ip firewall filter

add chain=input dst-address=10.10.10.1 dst-port=500,1701 in-interface=ether4 \

    protocol=udp src-address=10.10.10.2

add chain=input dst-address=10.10.10.1 in-interface=ether4 protocol=ipsec-esp \

    src-address=10.10.10.2

WinXP(client)

https://kb.iweb.com/entries/22387228-Configuring-new-VPN-L2TP-IPSec-connections-on-Windows-XP

Ссылки

http://wiki.mikrotik.com/wiki/L2TP_%2B_IPSEC_between_Mikrotik_router_and_a_PC

http://wiki.mikrotik.com/wiki/MikroTik_RouterOS_and_Windows_XP_IPSec/L2TP

http://nixman.info/?p=2308

Что показывает AT+CREG?

AT+CREG?
+CREG: 0,3

<stat>: network registration state
For <stat> = 1 or 5 (i.e the Wireless CPU® is registered on a
network) the next parameter couple is returned if <mode> = 2
For <stat> = 3 (i.e. the network registration is denied) and if the
customer application has enabled, the denied network
registration cause with the +WBHV command, only the
<rejectCause> parameter is returned with the meaning as
explained in <rejectCause> mode
0 not registered, ME is not currently searching for a new
operator
1 registered, home network
2 not registered, ME currently searching for a new operator
3 registration denied
4 unknown
5 registered, roaming

Фазы (этапы) IPSec

1. Определение трафика подлежащего шифрованию.
Чаще всего используеются так называемые crypto acl.

2. Первая фаза IKE. 
2.1. Аутентификация обоих концов туннеля.
2.2. Создается IKE SA которая используется для защиты процесса IKE.
2.3. Выполняется алгоритм Диффи-Хелмана, который гарантирует, что на каждом конце туннеля будет использоватся одинаковый shared secret, без пересылания этого shared secret.
2.4. Создается туннель для работы второй фазы IKE.


Первая фаза IKE может проходить в двух режимах:
- Main mode
проходит в три этапа:
- согласование используемых алгоритмов
- обе стороны используеют алгоритм Диффи-Хелмана для определения ключей
- используя ключи стороны аутентифицируют друг-друга.
- Aggressive mode
Все что посылается в Main mode в три этапа, посылается в одном пакете. Основная проблема, что стороны обмениваются информацией до того как безопасное соединение будет установлено.

3. Вторая фаза IKE.
Основаня задача этого этапа подготовить IPSec SA которые будут использоватся непосредственно для шифрования трафика. Сюда входит согласование параметров и собственно установка.
IPSec может переходить из фазы 4 к фазе 4 и назад в нескольких случаях:

- каждая SA имеет определенное время жизни (например 1 час в Checkpoint), соостветственно по истечении этого часа необходимо пересоздать SA. 
При этом для создания новой SA используется тот же shared secret, что и раньше.
- использование perfect forward secrecy (PFS). Алгоритм PFS гарантирует, что при создании новой SA предыдущий shared secret использоватся не будет, более того не будет никакой корреляции между старым и новым shared secret. Для реализации PFS используется алгоритм Диффи-Хелмана в quick mode.

Quick mode: для ренерации новой SA используется текущая SA (нет отброса на первую фазу IKE).


4. Нормальная работа.
На этой фазе туннель работает в нормальном режиме шифруя и расшифровывая трафик.

5. Закрытие туннеля.
Может быть принудительным (clear SA) либо по истечении тайм-аута.

http://techoover.blogspot.ru/2007/09/ipsec.html

Keyboard Shortcuts for Bash

 Command Shell for Ubuntu, Debian, Suse, Redhat, Linux, etc

Ctrl + A	Go to the beginning of the line you are currently typing on
Ctrl + E	Go to the end of the line you are currently typing on
Ctrl + L	Clears the Screen, similar to the clear command
Ctrl + U	Clears the line before the cursor position. If you are at the end of the line, clears the entire line.
Ctrl + H	Same as backspace
Ctrl + R	Let’s you search through previously used commands
Ctrl + C	Kill whatever you are running
Ctrl + F	Move cursor one character to the right
Ctrl + B	Move cursor one character to the left
Ctrl + W	Delete the word before the cursor
Ctrl + K	Clear the line after the cursor
Ctrl + T	Swap the last two characters before the cursor
Esc + T	Swap the last two words before the cursor
Alt + F	Move cursor forward one word on the current line
Alt + B	Move cursor backward one word on the current line
Tab	Auto-complete files and folder names