Это не повышает безопасность. См. https://security.stackexchange.com/questions/89533/would-requiring-multiple-passwords-enhance-security и Увеличит ли двойное шифрование безопасность шифра против брутфорса?. В двух словах, увеличение количества одних и тех же действий не может повысить безопасность: либо то, что вы делали раньше, было хорошо, и дополнительные действия излишни, либо то, что вы делали раньше, было не очень хорошо, и повторение не спасет вас. Кроме того, сложность всегда является врагом безопасности, поскольку она увеличивает риск ошибок в реализации и снижает вероятность того, что пользователи будут вести себя так, как вы ожидаете, поэтому если что-то не улучшает безопасность, то затраты на это вредят безопасности.
Запрос двух паролей - это то же самое, что и запрос одного пароля, но сначала вводится первая половина, а затем вторая. Разделив пароль, вы облегчили его взлом, поскольку две половины могут быть взломаны независимо друг от друга. Таким образом, вы снизили уровень безопасности.
Учитывая это, то, о чем вы просите, можно сделать. Повторяю, это плохая идея, но если вы хотите выстрелить себе в ногу, вот как это сделать. Только имейте в виду, что это не заставит вас работать быстрее.
В большинстве версий Unix аутентификация настраивается через PAM. Модуль PAM, который обрабатывает аутентификацию пароля, - pam_unix
. Вы можете добавить один или несколько вызовов других модулей проверки паролей, таких как pam_pwdfile
, которые обращаются к другой базе данных паролей (см. Можно ли изменить файл базы данных паролей(/etc/passwd) в linux?).
Но, повторюсь, не делайте этого. Если вы не понимаете в безопасности, используйте настройки системы по умолчанию, а не извращайте их в нечто худшее.
Вероятно, вы обнаружили ошибку в ядре. Возможно, мне не следует называть это ошибкой, поскольку могло быть просто то, что поддержка конкретного идентификатора карты никогда не была добавлена в код ядра.
Код ettercap, имеющий дело с физическим уровнем, выглядит следующим образом:
switch (ifr.ifr_hwaddr.sa_family)
{
case ARPHRD_ETHER:
case ARPHRD_METRICOM:
#ifdef ARPHRD_LOOPBACK
case ARPHRD_LOOPBACK:
#endif
l->link_type = DLT_EN10MB;
l->link_offset = 0xe;
break;
case ARPHRD_SLIP:
case ARPHRD_CSLIP:
case ARPHRD_SLIP6:
case ARPHRD_CSLIP6:
case ARPHRD_PPP:
l->link_type = DLT_RAW;
break;
case ARPHRD_FDDI:
l->link_type = DLT_FDDI;
l->link_offset = 0x15;
break;
/* Token Ring */
case ARPHRD_IEEE802:
case ARPHRD_IEEE802_TR:
case ARPHRD_PRONET:
l->link_type = DLT_PRONET;
l->link_offset = 0x16;
break;
default:
snprintf(l->err_buf, LIBNET_ERRBUF_SIZE,
"unknown physical layer type 0x%x",
ifr.ifr_hwaddr.sa_family);
goto bad;
}
И вы можете проверить значения всех этих определений внутри /usr/include/net/if_arp.h
. И да, 0x323 оказывается не одним из них. Более того, 0x323 не является каким-либо известным устройством для net / if_arp.h
Вот тестовая программа для заполнения ifr.ifr_hwaddr.sa_family
и его печати:
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <arpa/inet.h>
#include <sys/ioctl.h>
#include <stropts.h>
#include <net/if.h>
#include <netinet/if_ether.h>
#include <net/if_arp.h>
int
main(int argc, char** argv)
{
struct ifreq ifr;
int fd = -1;
char *iface = argv[1];
fd = socket(PF_INET, SOCK_PACKET, htons(ETH_P_ALL));
if (fd == -1)
{
if (errno == EPERM) {
printf("UID/EUID 0 or capability CAP_NET_RAW required\n");
} else {
printf("socket: %s\n", strerror(errno));
}
return 1;
}
memset(&ifr, 0, sizeof (ifr));
strncpy(ifr.ifr_name, iface, sizeof (ifr.ifr_name) -1);
ifr.ifr_name[strlen(iface)] = '\0';
if (ioctl(fd, SIOCGIFHWADDR, &ifr) < 0 )
{
printf("SIOCGIFHWADDR: %s\n", strerror(errno));
return 1;
}
printf( "IFR: [%08x] sa_family [%02x]\n"
, ifr.ifr_hwaddr, ifr.ifr_hwaddr.sa_family);
return 0;
}
Половина его просто скопирована из кода ettercap. В любом случае компиляция должна быть тривиальной gcc -o prog prog.c
(при условии, что источник имеет имя prog.c
), и вы должны запустить ее с именем интерфейса в качестве первого аргумента. например
[root@haps ~]# /home/grochmal/tmp/libnet/test enp3s0
IFR: [24240001] sa_family [00]
[root@haps ~]# /home/grochmal/tmp/libnet/test wlp2s0
IFR: [22000001] sa_family [00]
(это на моей машине)
Мы видим, что sa_family
заполняется:
ioctl(fd, SIOCGIFHWADDR, &ifr)
Что запускает это:
struct net_device *dev = dev_get_by_name_rcu(net, ifr->ifr_name);
...
case SIOCGIFHWADDR:
if (!dev->addr_len)
memset(ifr->ifr_hwaddr.sa_data, 0,
sizeof(ifr->ifr_hwaddr.sa_data));
else
memcpy(ifr->ifr_hwaddr.sa_data, dev->dev_addr,
min(sizeof(ifr->ifr_hwaddr.sa_data),
(size_t)dev->addr_len));
ifr->ifr_hwaddr.sa_family = dev->type;
return 0;
Где dev_get_by_name_rcu
- это макрос ядра который заполняет структуру struct net_device
. И поскольку у нас есть ifr-> ifr_hwaddr.sa_family = dev-> type,
также заполняет sa_family
.
Я нашел отчет об ошибке на странице Kali Linux об этом sa_family
, но kali не использует самое последнее ядро.
Поэтому я бы запустил приведенную выше тестовую программу, чтобы убедиться, что она печатает:
IFR: [********] sa_family [323]
Тестовую программу нужно запускать от имени пользователя root, поскольку она использует необработанный сокет.
А затем я бы попробовал более новую версию ядра, чтобы проверить, исправлена ли ошибка в ветви ядра 4.x (например, gentoo или arch). Например, запуск live CD с gcc
. У тестовой программы нет требований к библиотеке, поэтому ее легко скомпилировать на live CD.
Это настолько глубоко, насколько я могу вникнуть в код ядра. Каким образом определяется sa_family
из хэша устройства , мне непонятно.