/usr/share/doc/denyhosts/FAQ.html is in denyhosts 2.10-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<link rel="stylesheet" type="text/css" href="denyhosts.css">
<link rel="icon" href="/favicon.ico" type="image/x-icon">
<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon">
<title>
DenyHosts Frequently Asked Questions
</title>
</head>
<body bgcolor=white>
<center>
<img src=/images/denyhosts.png alt="DenyHosts">
</center>
<table width=100% border=0>
<tr>
<td width="15%" valign=top>
<P>
<script src="xaramenu.js"></script>
<script menumaker src="images/denyhosts.js"></script>
<p>
<fieldset>
<font size=-3>
<a href="index.html">Home</a> |
<a href="faq.html">FAQ</a> |
<a href="http://stats.denyhosts.net/stats.html">Statistics</a> |
<a href="links.html">Links</a> |
<a href="features.html">Features</a> |
<a href="http://sourceforge.net/project/showfiles.php?group_id=131204">Download</a> |
<a href="http://sourceforge.net/projects/denyhosts/">SourceForge</a>
</font>
</fieldset>
<p>
</td>
<td width="85%">
<!-- This page was generated automatically with FAQtor.py -->
<a name="#top"></a>
<center><h1>DenyHosts - Frequently Asked Questions</h1></center><table border=0><tr><td>
<table border="0">
<tr><th colspan="2" align="left"> <br>General</th></tr>
<tr><td>Q. 1.0 </td><td valign="top"><a href="#1_0">What is DenyHosts?</a></td></tr>
<tr><td>Q. 1.1 </td><td valign="top"><a href="#1_1">Who should use DenyHosts?</a></td></tr>
<tr><td>Q. 1.2 </td><td valign="top"><a href="#1_2">Who wrote DenyHosts?</a></td></tr>
<tr><td>Q. 1.3 </td><td valign="top"><a href="#1_3">What steps can I take to make sshd more secure?</a></td></tr>
<tr><td>Q. 1.4 </td><td valign="top"><a href="#1_4">What was the motivation behind DenyHosts?</a></td></tr>
<tr><td>Q. 1.5 </td><td valign="top"><a href="#1_5">How does DenyHosts work?</a></td></tr>
<tr><td>Q. 1.6 </td><td valign="top"><a href="#1_6">What else does DenyHosts do?</a></td></tr>
<tr><td>Q. 1.7 </td><td valign="top"><a href="#1_7">What are the requirements for running DenyHosts?</a></td></tr>
<tr><td>Q. 1.8 </td><td valign="top"><a href="#1_8">I just installed DenyHosts and receive a SyntaxError: invalid syntax. What happened?</a></td></tr>
<tr><td>Q. 1.9 </td><td valign="top"><a href="#1_9">My server has an earlier version of Python installed, can I still run DenyHosts?</a></td></tr>
<tr><td>Q. 1.10 </td><td valign="top"><a href="#1_10">Will DenyHosts work with my sshd configuration?</a></td></tr>
<tr><td>Q. 1.11 </td><td valign="top"><a href="#1_11">This FAQ is cool... I want one! How did you create it?</a></td></tr>
<tr><td>Q. 1.12 </td><td valign="top"><a href="#1_12">The DenyHosts logo is cool, who designed it?</a></td></tr>
<tr><td>Q. 1.13 </td><td valign="top"><a href="#1_13">Where can I download DenyHosts from?</a></td></tr>
<tr><td>Q. 1.14 </td><td valign="top"><a href="#1_14">Is DenyHosts available as a Redhat or Fedora Core package?</a></td></tr>
<tr><td>Q. 1.15 </td><td valign="top"><a href="#1_15">Is DenyHosts available as a Debian package?</a></td></tr>
<tr><td>Q. 1.16 </td><td valign="top"><a href="#1_16">Is DenyHosts available for Mac OS/X?</a></td></tr>
<tr><td>Q. 1.17 </td><td valign="top"><a href="#1_17">Is DenyHosts available for Gentoo?</a></td></tr>
<tr><td>Q. 1.18 </td><td valign="top"><a href="#1_18">DenyHosts is cool, can I make a generous donation?</a></td></tr>
<tr><td>Q. 1.19 </td><td valign="top"><a href="#1_19">Are there other tools similar to DenyHosts?</a></td></tr>
<tr><th colspan="2" align="left"> <br>Configuring DenyHosts</th></tr>
<tr><td>Q. 2.0 </td><td valign="top"><a href="#2_0">How do I configure DenyHosts?</a></td></tr>
<tr><td>Q. 2.1 </td><td valign="top"><a href="#2_1">How do I configure cron for DenyHosts use?</a></td></tr>
<tr><td>Q. 2.2 </td><td valign="top"><a href="#2_2">How can I disable hostname lookups?</a></td></tr>
<tr><td>Q. 2.3 </td><td valign="top"><a href="#2_3">Will DenyHosts work with metalog?</a></td></tr>
<tr><td>Q. 2.4 </td><td valign="top"><a href="#2_4">Will DenyHosts work with FreeBSD?</a></td></tr>
<tr><td>Q. 2.5 </td><td valign="top"><a href="#2_5">Will DenyHosts works with Solaris?</a></td></tr>
<tr><td>Q. 2.6 </td><td valign="top"><a href="#2_6">Can I use a non-standard hosts.deny file?</a></td></tr>
<tr><td>Q. 2.7 </td><td valign="top"><a href="#2_7">Can I use DenyHosts on FreeBSD using a non-standard hosts.deny file?</a></td></tr>
<tr><td>Q. 2.8 </td><td valign="top"><a href="#2_8">Can DenyHosts purge old entries added to the HOSTS_DENY file?</a></td></tr>
<tr><td>Q. 2.9 </td><td valign="top"><a href="#2_9">What time values are appropriate for PURGE_DENY, DAEMON_SLEEP, DAEMON_PURGE?</a></td></tr>
<tr><td>Q. 2.10 </td><td valign="top"><a href="#2_10">I just upgraded to 1.0.0, what do I need to do?</a></td></tr>
<tr><td>Q. 2.11 </td><td valign="top"><a href="#2_11">I just upgraded to 0.9.9 (or later) what do I need to do?</a></td></tr>
<tr><td>Q. 2.12 </td><td valign="top"><a href="#2_12">DenyHosts is unable to parse my syslog (or other) log file</a></td></tr>
<tr><td>Q. 2.13 </td><td valign="top"><a href="#2_13">Can I supply additional regular expressions to DenyHosts?</a></td></tr>
<tr><td>Q. 2.14 </td><td valign="top"><a href="#2_14">What is the difference between <i>FAILED_ENTRY_REGEX</i> and
<i>USERDEF_FAILED_ENTRY_REGEX</i>?
</a></td></tr>
<tr><td>Q. 2.15 </td><td valign="top"><a href="#2_15">Can I use DenyHosts with djb multilog?</a></td></tr>
<tr><td>Q. 2.16 </td><td valign="top"><a href="#2_16">Why isn't DenyHosts recognizing successful ssh logins?</a></td></tr>
<tr><td>Q. 2.17 </td><td valign="top"><a href="#2_17">What is the difference between DENY_THRESHOLD_INVALID, DENY_THRESHOLD_ROOT
and DENY_THRESHOLD_VALID and DENY_THRESHOLD_RESTRICTED?</a></td></tr>
<tr><td>Q. 2.18 </td><td valign="top"><a href="#2_18">Can I specify a set of users that should never be able to login?</a></td></tr>
<tr><td>Q. 2.19 </td><td valign="top"><a href="#2_19">Can I specify an alternate timestamp format for the DAEMON_LOG file?</a></td></tr>
<tr><td>Q. 2.20 </td><td valign="top"><a href="#2_20">Can failed login attempts be reset over a period of time?</a></td></tr>
<tr><td>Q. 2.21 </td><td valign="top"><a href="#2_21">Can failed login attempts be reset automatically?</a></td></tr>
<tr><td>Q. 2.22 </td><td valign="top"><a href="#2_22">Does DenyHosts support plugins?</a></td></tr>
<tr><td>Q. 2.23 </td><td valign="top"><a href="#2_23">Can TCPWRAPPERS automatically invoke DenyHosts per login attempt?</a></td></tr>
<tr><td>Q. 2.24 </td><td valign="top"><a href="#2_24">Can I dynamically specify configuration values?</a></td></tr>
<tr><th colspan="2" align="left"> <br>Using DenyHosts</th></tr>
<tr><td>Q. 3.0 </td><td valign="top"><a href="#3_0">I've configured DenyHosts, now what?</a></td></tr>
<tr><td>Q. 3.1 </td><td valign="top"><a href="#3_1">Do I need to run DenyHosts as root?</a></td></tr>
<tr><td>Q. 3.2 </td><td valign="top"><a href="#3_2">How should DenyHosts be run?</a></td></tr>
<tr><td>Q. 3.3 </td><td valign="top"><a href="#3_3">When my logs are rotated will DenyHosts work properly?</a></td></tr>
<tr><td>Q. 3.4 </td><td valign="top"><a href="#3_4">I want to process the entire log file regardless of the last offset, how can I do this?</a></td></tr>
<tr><td>Q. 3.5 </td><td valign="top"><a href="#3_5">DenyHosts exits without producing any output, what happened?</a></td></tr>
<tr><td>Q. 3.6 </td><td valign="top"><a href="#3_6">I don't want to receive an email report of hosts added to /etc/hosts.deny.</a></td></tr>
<tr><td>Q. 3.7 </td><td valign="top"><a href="#3_7">How can I prevent a legitimate IP address from being blocked by DenyHosts?</a></td></tr>
<tr><td>Q. 3.8 </td><td valign="top"><a href="#3_8">What if SSH sometimes logs hostnames rather than IP addresses<br>
How can I prevent these from being blocked?</a></td></tr>
<tr><td>Q. 3.9 </td><td valign="top"><a href="#3_9">DenyHosts reports suspicious login activity for allowed hosts, how can I stop this?
</a></td></tr>
<tr><td>Q. 3.10 </td><td valign="top"><a href="#3_10">Can DenyHosts process gzipped logfiles</a></td></tr>
<tr><td>Q. 3.11 </td><td valign="top"><a href="#3_11">Can DenyHosts process bzipped (bz2) logfiles</a></td></tr>
<tr><td>Q. 3.12 </td><td valign="top"><a href="#3_12">I've just upgraded to 0.8.0 (or greater) and want to update
my <i>HOSTS_DENY</i> for use with <i>PURGE_DENY</i>
</a></td></tr>
<tr><td>Q. 3.13 </td><td valign="top"><a href="#3_13">How can I prevent more than one instance of DenyHosts from running?</a></td></tr>
<tr><td>Q. 3.14 </td><td valign="top"><a href="#3_14">Why does DenyHosts report "Error sending email"?</a></td></tr>
<tr><td>Q. 3.15 </td><td valign="top"><a href="#3_15">Can DenyHosts email reports to SMTP servers that require
authentication?</a></td></tr>
<tr><td>Q. 3.16 </td><td valign="top"><a href="#3_16">Can DenyHosts be run as a daemon (background) process?</a></td></tr>
<tr><td>Q. 3.17 </td><td valign="top"><a href="#3_17">I have additional questions, where can I get help?</a></td></tr>
<tr><td>Q. 3.18 </td><td valign="top"><a href="#3_18">I've found a bug, will you fix it?</a></td></tr>
<tr><td>Q. 3.19 </td><td valign="top"><a href="#3_19">What are all of the files in my DenyHosts WORK_DIR?</a></td></tr>
<tr><th colspan="2" align="left"> <br>DenyHosts Synchronization Mode</th></tr>
<tr><td>Q. 4.0 </td><td valign="top"><a href="#4_0">What is synchronization mode?</a></td></tr>
<tr><td>Q. 4.1 </td><td valign="top"><a href="#4_1">What is denyhosts.net?</a></td></tr>
<tr><td>Q. 4.2 </td><td valign="top"><a href="#4_2">How does synchronization mode work?</a></td></tr>
<tr><td>Q. 4.3 </td><td valign="top"><a href="#4_3">What are the requirements for synchronization mode?</a></td></tr>
<tr><td>Q. 4.4 </td><td valign="top"><a href="#4_4">Is synchronization mode enabled by default?</a></td></tr>
<tr><td>Q. 4.5 </td><td valign="top"><a href="#4_5">How do I enable synchronization mode?</a></td></tr>
<tr><td>Q. 4.6 </td><td valign="top"><a href="#4_6">How do I configure synchronization mode?</a></td></tr>
<tr><td>Q. 4.7 </td><td valign="top"><a href="#4_7">Can I just send denied data?</a></td></tr>
<tr><td>Q. 4.8 </td><td valign="top"><a href="#4_8">Can I just receive data?</a></td></tr>
<tr><td>Q. 4.9 </td><td valign="top"><a href="#4_9">When receiving denied data will I get all denied hosts?</a></td></tr>
<tr><td>Q. 4.10 </td><td valign="top"><a href="#4_10">How do I know that DenyHosts synchronization mode is working?</a></td></tr>
<tr><td>Q. 4.11 </td><td valign="top"><a href="#4_11">I decided that I don't want to use synchronization mode, how do I disable it?</a></td></tr>
<tr><td>Q. 4.12 </td><td valign="top"><a href="#4_12">How long will retrieved ip addresses remain in my HOSTS_DENY file?</a></td></tr>
<tr><td>Q. 4.13 </td><td valign="top"><a href="#4_13">What is the cost of the synchronization service?</a></td></tr>
<tr><td>Q. 4.14 </td><td valign="top"><a href="#4_14">What information is collected from me?</a></td></tr>
<tr><td>Q. 4.15 </td><td valign="top"><a href="#4_15">How will information collected from me be used?</a></td></tr>
<tr><td>Q. 4.16 </td><td valign="top"><a href="#4_16">What is the acceptable use policy of the data that denyhosts.net provides?</a></td></tr>
<tr><td>Q. 4.17 </td><td valign="top"><a href="#4_17">I administer many commercial servers, can I run my own denyhosts.net server?</a></td></tr>
</table>
<hr>
<h1>General</h1>
<a name="1_0"></a>
<p align="right">A. 1.0</p><h2>What is DenyHosts?</h2><br>DenyHosts is a Python script that analyzes the sshd server log messages to determine what hosts
are attempting to hack into your system. It also determines what user accounts are being targeted.
It keeps track of the frequency of attempts from each host. <p>
Additionally, upon discovering a repeated attack host, the /etc/hosts.deny file is updated
to prevent future break-in attempts from that host.
<p>
An email report can be sent to a system admin.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="1_1"></a>
<p align="right">A. 1.1</p><h2>Who should use DenyHosts?</h2><br>Although DenyHosts is designed for the use by Linux system administrators, the script can be
useful to anybody running an sshd server.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="1_2"></a>
<p align="right">A. 1.2</p><h2>Who wrote DenyHosts?</h2><br>Phil Schwartz. You can see some of the other cool projects that I have written on the
<a href="links.html">links page</a>.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="security"></a>
<a name="1_3"></a>
<p align="right">A. 1.3</p><h2>What steps can I take to make sshd more secure?</h2><br>OpenSSH has many settings that can be adjusted in order to increase security. You may wish to refer to
OpenSSH security websites or to the many books on the subject. However, here are some things that you may
wish to consider based on my experience:<p>
<ol>
<li>Disable logins to <i>root</i>. This can be accomplished by setting the <i>PermitRootLogin</i> setting
in the sshd_config file (typically, /etc/ssh/sshd_config).<br>
<i>PermitRootLogin no</i>
<p>
<li>Disable password logins entirely by editing the <i>PasswordAuthentication</i> setting. By doing so,
each user with access to the server will need to create ssh keys (which is beyond the scope of this
document).<br>
<i>PasswordAuthentication no</i>
<p>
<li>Run sshd on a different port. By default, sshd runs on port 22. Most sshd hackers will only attack
port 22 so if you run sshd on a different port, the chances of being compromised are reduced dramatically.
However, by running sshd on an alternate port requires each user to be aware of this (so if your server is
accessed by many user accounts then this solution might not be feasible). To run sshd on an alternate port
simply edit the sshd_config and set the <i>Port</i> setting appropriately:<br>
<i>Port 9922</i><p>
To access <i>yourserver</i> running on port 9922 you would connect using the <i>-p</i> command line
option:<br>
$ <i>ssh -p 9922 yourserver</i>
<p>
Alternatively, you can edit your <i>$HOME/.ssh/config</i> file <i>or</i> your site-wide
<i>/etc/ssh/ssh_config</i> file and add an entry similar to:<p>
<table border="0">
<tr>
<td>Host yourserver</td>
</tr>
<tr>
<td align="right">Port 9922</td>
</tr>
</table>
<p>
<li>Install DenyHosts!
</ol>
<b>Note:</b> After saving changes to the sshd_config file you will need to restart
the sshd server for these settings to take effect
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="1_4"></a>
<p align="right">A. 1.4</p><h2>What was the motivation behind DenyHosts?</h2><br>I run a number of Linux servers and I noticed that one of them was <a href="hack_tale.html">hacked
into</a>. Upon browsing my sshd log I noticed that the system was targeted for some time and
eventually, somebody hacked out a password. Had I been using DenyHosts, that never would've happened
(if only I had the foresight to write this script <i>before</i> my system was compromised!). I then
looked at the logs of my other servers, and noticed hundreds of break-in attempts. I wanted to
thwart these hosts <i>and</i> future attackers from attempting to hack into my system.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="1_5"></a>
<p align="right">A. 1.5</p><h2>How does DenyHosts work?</h2><br>When run for the first time, DenyHosts will create a work directory. The work directory will ultimately
store the data collected and the files are in a human readable format, for each editing, if necessary.
<p>
DenyHosts then processes the sshd server log (typically, this is /var/log/secure, /var/log/auth.log, etc)
and determines which hosts have unsuccessfully attempted to gain access to the ssh server. Additionally,
it notes the user and whether or not that user is <i>root</i>, otherwise <i>valid</i> (eg. has a system
account) or <i>invalid</i> (eg. does not have a system account). <p>
When DenyHosts determines that a given host has attempted to login using a non-existent user account a
configurable number of attempts (this is known as the <i>DENY_THRESHOLD_INVALID</i>), DenyHosts will add that host
to the /etc/hosts.deny file. This will prevent that host from contacting your sshd server again. <p>
The <i>DENY_THRESHOLD_ROOT</i> configuration value specifies the maximum acceptable times that the
<i>root</i> user account can fail to login before being blocked. Typically this value is set lower than
<i>DENY_THRESHOLD_INVALID</i> such that root level attackers are blocked earlier than other accounts. It is also a
good practice to <a href="#security">disable root logins</a> within the sshd.conf file in conjunction with
this setting. By doing so, no user can login to root@your-server and their host will be blocked from attacking other user accounts
when the <i>DENY_THRESHOLD_ROOT</i> is reached.
<p>
The <i>DENY_THRESHOLD_VALID</i> configuration value specifies the maximum acceptable times a valid user
(ie. a user that exists in /etc/passwd) can fail to login before being blocked. This parameter
can be helpful for those with "fat fingers". Typically this value is set higher than
<i>DENY_THRESHOLD_INVALID</i>.<p>
Also, DenyHosts will note any successful logins that occurred by a host that has exceeded the <i>deny_threshold</i>.
These are known as <i>suspicious logins</i> and should be investigated further by the system admin.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="1_6"></a>
<p align="right">A. 1.6</p><h2>What else does DenyHosts do?</h2><br>Please see the <a href="features.html">features page</a> for more information.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="1_7"></a>
<p align="right">A. 1.7</p><h2>What are the requirements for running DenyHosts?</h2><br>Please see the <a href="requirements.html">requirements page</a>.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="invalid_syntax"></a>
<a name="1_8"></a>
<p align="right">A. 1.8</p><h2>I just installed DenyHosts and receive a SyntaxError: invalid syntax. What happened?</h2><br>If you see an error similar to this:<p>
<pre>
File "/etc/init.d/denyhosts", line 72
if args: cmd+= ' '.join(args)
^
SyntaxError: invalid syntax
</pre>
<p>
Then you are using an <a href=#python_version>earlier version of Python</a>.
DenyHosts requires Python v2.3 or later.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="python_version"></a>
<a name="1_9"></a>
<p align="right">A. 1.9</p><h2>My server has an earlier version of Python installed, can I still run DenyHosts?</h2><br>DenyHosts requires Python v2.3 or later. If you are using an earlier version of Python then you should
install a newer version of Python on your system. Multiple versions of Python can safely co-exist on your server
so you do not need to worry about breaking any dependencies. You should
<a href="http://www.python.org" target="x">obtain the latest version of Python</a> and install it on your system.
Depending on the method of download, your latest Python executable is typically installed in
/usr/local/bin or /usr/bin. <p>
If you downloaded version Python v2.3, then the executable is python2.3. If you downloaded
Python v2.4 then the executable is python2.4.
<p>
If you will be using DenyHosts in daemon mode, then you will need to edit the
<a href="daemon-control-dist">daemon-control-dist</a> script. You will want to copy this file to "daemon-control"
such that future DenyHosts upgrades will preserve your edits.<p>
<i>$ cp daemon-control-dist daemon-control</i>
<p>
Assuming you installed Python v2.4 and the
executable is in /usr/bin then you will need to make the following changes to your daemon-control script:<p>
<table border="0">
<tr>
<td width="15%"><b>Line #</b></td>
<td width="50%"><b>From</b></td>
<td width="35%"><b>To</b></td>
</tr>
<tr>
<td>1</td>
<td>#!/usr/bin/env python</td>
<td>#!/usr/bin/python2.4</td>
</tr>
<tr>
<td>18</td>
<td>PYTHON_BIN = "/usr/bin/env python"</td>
<td>PYTHON_BIN = "/usr/bin/python2.4"</td>
</tr>
</table>
<p>
You may need to modify the above paths to reflect the actual installation location and version of Python that
you installed.
<p>
If you are not using DenyHosts in daemon mode then to execute DenyHosts you would do the following:
<p>
<i>$ python2.4 denyhosts ... args...</i>
<p>-or-</p>
<i>$ python2.3 denyhosts ... args...</i>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="1_10"></a>
<p align="right">A. 1.10</p><h2>Will DenyHosts work with my sshd configuration?</h2><br>Most likely it will work with your configuration.
However, please see the <a href="ssh_config.html">ssh
configuration page</a> for more details.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="1_11"></a>
<p align="right">A. 1.11</p><h2>This FAQ is cool... I want one! How did you create it?</h2><br>Funny you should ask. I have also written
<a href="http://faqtor.sourceforge.net" target="x">FAQtor</a>, which
is a <b>FAQ</b> genera<b>TOR</b>.
You can see my other projects on the <a href="links.html">links page</a>.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="logo"></a>
<a name="1_12"></a>
<p align="right">A. 1.12</p><h2>The DenyHosts logo is cool, who designed it?</h2><br>The DenyHosts logo was designed by <a href="http://curtistee.homelinux.org/" target="x">Curtis
Taylor</a>. Many thanks to Curtis for the logo. Incidentally, Curtis also designed the
<a href="http://releaseforge.sourceforge.net" target="x">ReleaseForge</a> logo.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="1_13"></a>
<p align="right">A. 1.13</p><h2>Where can I download DenyHosts from?</h2><br>DenyHosts is available for
<a href="http://sourceforge.net/project/showfiles.php?group_id=131204">download from
SourceForge</a>. <p>
DenyHosts is currently released in several formats by the author:
<ul>
<li>Source tar.gz
<li>An RPM for Python 2.3
<li>An RPM for Python 2.4
<li>Source RPM
</ul>
<p>
Additionally, DenyHosts has been re-packaged and/or is available for the following distributions:
<p>
<ul>
<li><a href="#fedora">Fedora Core</a>
<li><a href="#fedora">Redhat</a>
<li><a href="#debian">Debian</a>
<li><a href="#gentoo">Gentoo</a>
<li><a href="#solaris">Solaris</a>
<li><a href="#freebsd">FreeBSD</a>
<li><a href="#macos">Mac OS/X</a>
</ul>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="fedora"></a>
<a name="1_14"></a>
<p align="right">A. 1.14</p><h2>Is DenyHosts available as a Redhat or Fedora Core package?</h2><br>Various RPM packages of DenyHosts are available from
<a href="http://dag.wieers.com/packages/denyhosts/">DAG Wieers repository</a>
<p>
Additionally, DenyHosts is included in the Fedora Extras repository
repository and should be accessible via yum and/or up2date. You can view the
appropriate repository: <p>
<a href="http://download.fedora.redhat.com/pub/fedora/linux/extras/4/i386/">Fedora Core 4</a>
<br>
<a href="http://download.fedora.redhat.com/pub/fedora/linux/extras/3/i386/">Fedora Core 3</a>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="debian"></a>
<a name="1_15"></a>
<p align="right">A. 1.15</p><h2>Is DenyHosts available as a Debian package?</h2><br>Thanks to Marco Bertorello, DenyHosts is now available as a
<a href="http://bertorello.ns0.it/debian/binary/denyhosts">Debian package</a>.
<p>
Falko Timme has written a "How To" document on
<a href="http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts">How to
setup DenyHosts on Debian</a>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="macos"></a>
<a name="1_16"></a>
<p align="right">A. 1.16</p><h2>Is DenyHosts available for Mac OS/X?</h2><br>DenyHosts should work under Mac OS/X. You will have to edit your denyhosts configuration file
(typically denyhosts.cfg) according to the Mac OS X version that you are running:<p>
If you are using <a target="x" href="mac_os_10_4.txt">Mac OS v10.4 or greater</a>
<p>
If you are using <a target="x" href="mac_os_10_3.txt">Mac OS v10.3 or earlier</a>
<p>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="gentoo"></a>
<a name="1_17"></a>
<p align="right">A. 1.17</p><h2>Is DenyHosts available for Gentoo?</h2><br>I'm not a Gentoo user so I can't provide a package for Gentoo. However,
Mike Kelly has released a
<a href="http://bugs.gentoo.org/show_bug.cgi?id=100043" target="x">Gentoo package</a>
for DenyHosts.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="donate"></a>
<a name="1_18"></a>
<p align="right">A. 1.18</p><h2>DenyHosts is cool, can I make a generous donation?</h2><br>Unfortunately, your
<a href="http://sourceforge.net/donate/index.php?group_id=131204">donation</a>
can not exceed $250 US, but I'll accept it anyway :) <p>
Portions of your donation help support SourceForge and the Python Software Foundation
(and PayPal takes a piece too). Whatever money remains will no doubt be spent on
delicious beer and other less important necessities of life.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="other"></a>
<a name="1_19"></a>
<p align="right">A. 1.19</p><h2>Are there other tools similar to DenyHosts?</h2><br>Yes. There are plenty of other tools that have the same goal as DenyHosts but have different
implementations. Here is a short list of those that I am aware of:
<ul>
<li><a href="http://fail2ban.sourceforge.net" target="x">Fail2Ban</a>
<li><a href="http://www.aczoom.com/cms/blockhosts/" target="x">BlockHosts</a>
<li><a href="http://blinkeye.ch/mediawiki/index.php/SSH_Blocking" target="x">Blacklist</a>
</ul>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<h1>Configuring DenyHosts</h1>
<a name="2_0"></a>
<p align="right">A. 2.0</p><h2>How do I configure DenyHosts?</h2><br>DenyHosts uses a simple configuration file. An example, <i>denyhosts.cfg-dist</i> is
supplied in the distribution. This file should be copied to <i>denyhosts.cfg</i> and edited
to match your system configuration.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="cron"></a>
<a name="2_1"></a>
<p align="right">A. 2.1</p><h2>How do I configure cron for DenyHosts use?</h2><br>Presumably, you will need to run DenyHosts as root (in order for DenyHosts to update /etc/hosts.deny and read
entries from /var/log), so you first must become root. Once you have either logged in as root (or
used <i>su - root</i>, for instance) you can then run the following command:<p>
# <i>crontab -e</i>
<p>
The above command will launch the crontab editor. To launch DenyHosts every 20 minutes you would then add the
following line to the crontab:<p>
<i>0,20,40 * * * * python <b>PATH_TO_DENYHOSTS/</b>denyhosts.py -c
<b>PATH_TO_DENYHOSTS_CONFIG/</b>denyhosts.cfg</i><p>
You will need to substitute your site-specific paths above. As an example, if you installed DenyHosts in
/usr/local/etc and maintain your configuration file there as well, then the following crontab entry would be
appropriate:
<p>
<i>0,20,40 * * * * python /usr/local/etc/denyhosts/denyhosts.py -c /usr/local/etc/denyhosts/denyhosts.cfg</i>
<p>
Once you have edited the crontab you should then save it. Assuming you didn't make any errors,
the crontab will automatically install itself.
<p>
For more information regarding the crontab format please see the crontab man page (<i>man 5 crontab</i>).
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="2_2"></a>
<p align="right">A. 2.2</p><h2>How can I disable hostname lookups?</h2><br>Denyhosts v0.6.0 added a feature to lookup corresponding hostnames for ip addresses that it
reports. The default enables these lookups. If you wish to disable this behavior you can
edit your DenyHosts configuration file and set the <i>HOSTNAME_LOOKUP</i> parameter to
<i>NO</i>. The default is <i>YES</i>.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="metalog"></a>
<a name="2_3"></a>
<p align="right">A. 2.3</p><h2>Will DenyHosts work with metalog?</h2><br>Yes. Metalog is an alternative to syslog and is the standard logging agent on (some) Gentoo
systems. <p>
Based on a patch contributed by Mike Kelly, DenyHosts 0.7 and greater will successfully parse
syslog and metalog log formats. This feature is implemented in a seemless manner so there is
no further configuration necessary in order to use DenyHosts with metalog.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="freebsd"></a>
<a name="2_4"></a>
<p align="right">A. 2.4</p><h2>Will DenyHosts work with FreeBSD?</h2><br>Yes. According to Frencesca Smith, DenyHosts 0.7 and greater will work under FreeBSD.
DenyHosts automatically detects if you are running it under FreeBSD and if so, will append
your deny entries with "<i> : deny</i>". You should also update your HOSTS_DENY
configuration value to "<i>/etc/hosts.allow</i>" since FreeBSD does not recognize the default
"<i>/etc/hosts.deny</i>" file that many other vendors use.<p>
You may also wish to view these items:
<ul>
<li>
<a href="#freebsdaux">this FAQ answer</a>
<li>
<a href="http://linuxgal.com/phpmyfaq/index.php?action=artikel&cat=1&id=1&artlang=en" target="x">article</a>
written by Francesa Smith that provides more information.
</ul>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="solaris"></a>
<a name="2_5"></a>
<p align="right">A. 2.5</p><h2>Will DenyHosts works with Solaris?</h2><br>Yes. DenyHosts has been reported to work with Solaris. However, since Solaris uses a
pam_afs format for logging messages, you will need to <a href="solaris.txt">add this line</a> to
your configuration file (typically, <i>denyhosts.cfg </i>).
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="aux"></a>
<a name="2_6"></a>
<p align="right">A. 2.6</p><h2>Can I use a non-standard hosts.deny file?</h2><br>Yes. To do so follow this procedure:<p>
<ol>
<li>edit your <i>HOSTS_DENY</i> configuration value to point it to another file
such as "/etc/hosts.evil".
<li>edit your <i>BLOCK_SERVICE</i> configuration value and leave it blank
<li>edit your <i>/etc/hosts.allow</i> file and add:<p>
<i>sshd: ALL EXCEPT /etc/hosts.evil</i>
<li>issue the following command:<br>
<i>touch /etc/hosts.evil</i>
</ol>
This will result in tcp_wrappers allowing all hosts to login <b>except</b> for those hosts
explicitly listed in
<i>/etc/hosts.evil</i>. <p>
This procedure will only work on DenyHosts 0.7 and greater and was implemented based on a
patch contributed by John Meinel Jr.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="freebsdaux"></a>
<a name="2_7"></a>
<p align="right">A. 2.7</p><h2>Can I use DenyHosts on FreeBSD using a non-standard hosts.deny file?</h2><br>Yes. Beginning with DenyHosts version 0.7.2 this can be accomplished by following these
steps:
<ol>
<li>edit your <i>HOSTS_DENY</i> configuration value to point it to another file
such as "/etc/hosts.evil".
<li>edit your <i>BLOCK_SERVICE</i> configuration value and leave it blank
<li>edit your <i>/etc/hosts.allow</i> file and add:<p>
<i>sshd : /etc/hosts.evil : deny<br>
sshd : ALL : allow</i>
<li>issue the following command:<br>
<i>touch /etc/hosts.evil</i>
</ol>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="purge"></a>
<a name="2_8"></a>
<p align="right">A. 2.8</p><h2>Can DenyHosts purge old entries added to the HOSTS_DENY file?</h2><br>DenyHosts v0.8.0 (and greater) offers the ability to remove old entries from the <i>HOSTS_DENY</i>
file (eg. <i>/etc/hosts.deny</i>). You must set the <i>PURGE_DENY</i> parameter in your
configuration file and invoke DenyHosts with the <i>--purge</i> command line flag:<p>
$ <i>denyhosts.py --purge</i><p>
When DenyHosts is run with the <i>--purge</i> flag it locates entries in the <i>HOSTS_DENY</i> file
that have been previously timestamped by DenyHosts that have exceeed the <i>PURGE_DENY</i> value
using the following algorithm:
<ol>
<li><i>HOSTS_DENY</i> is backed up to a file named <i>HOSTS_DENY.purge.bak</i>
<li>a temp file is created, <i>HOSTS_DENY.purge.tmp</i>
<li>the <i>HOSTS_DENY</i> is parsed and each non-expired entry and each non-timestamped entry
will be written to <i>HOSTS_DENY.purge.tmp</i>
<li>each <i>HOSTS_DENY</i> that has expired (based on <i>PURGE_DENY</i>) will <i>not</i> be written to
<i>HOSTS_DENY.purge.tmp</i>
<li> after all lines are parsed, if atleast one entry was not written to
<i>HOSTS_DENY.purge.tmp</i> (that is, no entries were expired) then
<i>HOSTS_DENY.purge.tmp</i> will be deleted and no further processing will be performed.
<li>otherwise, <i>HOSTS_DENY.purge.tmp</i> is moved to <i>HOSTS_DENY</i> (atomically-- such that
even in the case of failure, the <i>HOSTS_DENY</i> should always be present). In the event of a
catastrophic emergency you can manually move the <i>HOSTS_DENY.purge.bak</i> back to
<i>HOSTS_DENY</i>.
</ol>
<p>
The <i>PURGE_DENY</i> value is given as a <a href="#timespec">time specification</a>.
<ul>
<li>PURGE_DENY = # an empty value disables the purge facility
<li>PURGE_DENY = 1h # purge entries older than one hour
<li>PURGE_DENY = 20m # purge entries older than twenty minutes
<li>PURGE_DENY = 31d # purge entries older than 31 days
<li>PURGE_DENY = 2w # purge entries older than two weeks
<li>PURGE_DENY = 1y # purge entries older than one year
</ul>
<p>
Entries in <i>HOSTS_DENY</i> that were added before the <i>PURGE_DENY</i> value was defined
(for example, if you upgraded from a previous version of DenyHosts or you have just decided
to enable the purge functionality) will not be impacted by the <i>--purge</i> flag.
However, if you wish for these "legacy" <i>HOSTS_DENY</i> entries to be subject to expiration
then you will need to <a href="#migrate">migrate your <i>HOSTS_DENY</i> data</a>.<p>
Once <i>PURGE_DENY</i> has been configured to a non-empty value, DenyHosts will automatically
timestamp each record that is added to <i>HOSTS_DENY</i>. If <i>PURGE_DENY</i> is empty then
DenyHosts will <i>not</i> timestamp the records added to <i>HOSTS_DENY</i>.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="timespec"></a>
<a name="2_9"></a>
<p align="right">A. 2.9</p><h2>What time values are appropriate for PURGE_DENY, DAEMON_SLEEP, DAEMON_PURGE?</h2><br>Denyhosts configuration parameters that expect a unit of time as a value are specified as such:<p>
<i>number[period]</i>
Where number is any integer greater than zero and period can contain one of the values in:
<i>s, m, h, d, w, y</i>. Where:
<ul>
<li>s: seconds
<li>m: minutes
<li>h: hours
<li>d: days
<li>w: weeks
<li>y: years
</ul>
<p>
If the period is blank, then seconds is assumed.<p>
Examples:
<ul>
<li>1d is one day
<li>10 is 10 seconds
<li>10s is 10 seconds
<li>3w is 3 weeks
<li>30m is 30 minutes
<li>120d is 120 days
</ul>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="upgrade100"></a>
<a name="2_10"></a>
<p align="right">A. 2.10</p><h2>I just upgraded to 1.0.0, what do I need to do?</h2><br>Users upgrading from versions prior to 0.9.9 should also see <a href="#upgrade099">this FAQ answer</a>.
<p>
DenyHosts 1.0.0 adds two additional required configuration parameters that must be defined. You can
refer to the <i>denyhosts.cfg-dist</i> file for sample usage of the new <i>DENY_THRESHOLD_ROOT</i> and
<I>DENY_THRESHOLD_VALID</i> parameters. These parameters are also <a href="#threshold">documented</a>.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="upgrade099"></a>
<a name="2_11"></a>
<p align="right">A. 2.11</p><h2>I just upgraded to 0.9.9 (or later) what do I need to do?</h2><br>If you are upgrading to v0.9.9 (or later) from DenyHosts 0.8.0 through 0.9.8 <i>and</i> you have
previously set <i>PURGE_DENY</i> in your configuration file then you <b>must</b> do the
following:<p>
To upgrade your <i>HOSTS_DENY</i> file to the new timestamped format you must first invoke
denyhosts with the <i>--upgrade099</i> flag.<p>
$ <i>denyhosts.py --upgrade099</i><p>
Versions between 0.8.0 and 0.9.8 added a comment-timestamp (when <i>PURGE_DENY</i> was set) that
caused tcp_wrappers to report an error. DenyHosts 0.9.9 fixes this problem by upgrading the
entries of <i>HOSTS_DENY</i> to an alternative format which should prevent errors from being
reported. <p>
If you are upgrading from a version prior to 0.8.0 <i>or</i> have not yet set <i>PURGE_DENY</i>
then there is no need to upgrade. If you wish to now set <i>PURGE_DENY</i> for the first time then
you should run DenyHosts with the <a href="#migrate">--migrate</a> flag rather than the
--upgrade099 flag.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="custom_regex"></a>
<a name="2_12"></a>
<p align="right">A. 2.12</p><h2>DenyHosts is unable to parse my syslog (or other) log file</h2><br>New to version 0.9.9 (and greater), DenyHosts allows the end user to supply custom regular
expressions that may be necessary to parse unusual <i>SECURE_LOG</i> files. This feature
requires regular expression knowledge. If you are unsure how to parse your particular log
file please feel free to <a href="http://sourceforge.net/users/phil_schwartz/">email me
directly</a> for regex support.<p>
The following regex entries can be overridden in your denyhosts.cfg file:<p>
<ul>
<li>SSHD_FORMAT_REGEX
<li>FAILED_ENTRY_REGEX
<li>FAILED_ENTRY_REGEX2
<li>FAILED_ENTRY_REGEX3
<li>FAILED_ENTRY_REGEX4
<li>FAILED_ENTRY_REGEX5
<li>FAILED_ENTRY_REGEX6
<li>SUCCESSFUL_ENTRY_REGEX
</ul>
<p>Note that each of these configuration parameters are completely optional.
If a value is not configured within this file then the default value will be used.
The defaults can be seen by viewing the DenyHosts/regex.py file within the
source distribution.<p>
When providing a custom regular expression make sure that you only include the
portions between the opening and closing triple-quotes (ie. '''<b>this value</b>''').
That is, if you are modifying the SSHD_FORMAT_REGEX which appears in DenyHosts/regex.py as:<p>
<i>SSHD_FORMAT_REGEX = re.compile(r""".* (sshd.*:|\[sshd\]) (?P<<i>message></i>.*)""")</i><p>
You would enter the following in your denyhosts.cfg file:<p>
<i>SSHD_FORMAT_REGEX = .* (sshd.*:|\[sshd\]) (?P<<i>message></i>.*)</i><p>
You could then customize the above regex as you see fit based on your log file's particular
format. You can use a tool such as <a href="http://kodos.sourceforge.net">Kodos</a> (also
developed by <a href="http://www.phil-schwartz.com">Phil Schwartz</a>) to test your custom
regex patterns against your log contents.<p>
If I do provide you with a custom regex that helps DenyHosts perform for your particular
configuration, please consider making a
<a href="http://sourceforge.net/donate/index.php?group_id=131204">donation</a>.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="userdef_regex"></a>
<a name="2_13"></a>
<p align="right">A. 2.13</p><h2>Can I supply additional regular expressions to DenyHosts?</h2><br>Yes. New in v1.1.5, DenyHosts adds the ability for the user to specify additional
regular expressions that can be used to locate possible break-in attempts. The
<i>USERDEF_FAILED_ENTRY_REGEX</i> can be specified repeatedly. Each value must
contain a single regular expression that includes a <i>host</i> regular expression group and
optionally a <i>user</i> group. It is assumed that the end user is familiar with regular
expressions in order to take advantage of this feature. <p>
Examples:<p>
<i>USERDEF_FAILED_ENTRY_REGEX=break in attempt for (?P<user>.*) from (?P<host>.*)</i><br>
<i>USERDEF_FAILED_ENTRY_REGEX=break in attempt from (?P<host>.*)</i><p>
If multiple <i>USERDEF_FAILED_ENTRY_REGEX</i> are supplied they are evaluated in the order
that they appear in the configuration file. Additionally, this parameter is evaluated
<i>after</i> the built-in regular expressions (ie. FAILED_ENTRY_REGEX, FAILED_ENTRY_REGEX2, ...).
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="2_14"></a>
<p align="right">A. 2.14</p><h2>What is the difference between <i>FAILED_ENTRY_REGEX</i> and
<i>USERDEF_FAILED_ENTRY_REGEX</i>?
</h2><br><i>FAILED_ENTRY_REGEX, FAILED_ENTRY_REGEX2, FAILED_ENTRY_REGEX3 ...</i> refer to the
regular expressions that DenyHosts uses in order to recognize hackers. Under most
circumstances these are adequate. However, if DenyHosts is unable to parse your logfile
then these <a href="#custom_regex">regular expressions should be overridden</a> in your
configuration file.<p>
The optional <a href="#userdef_regex"><i>USERDEF_FAILED_ENTRY_REGEX</i></a>
configuration parameter can be specified in order to add additional
regular expressions to DenyHosts which may allow it to identify more hacker attempts
based on your particular configuration. Therefore, these regular expressions do not
replace the non-<i>USERDEF</i> versions and are intended to extend DenyHosts hacker
recognition.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="multilog"></a>
<a name="2_15"></a>
<p align="right">A. 2.15</p><h2>Can I use DenyHosts with djb multilog?</h2><br>DenyHosts v0.9.9 (and greater) supports DJB's multilog output format.
The output format appears as: <p>
<i>
@4000000042f4e1d3057febbc Failed password for invalid user network ... <br>
@4000000042f4e1d305800ee4 Connection closed by ...
</i><p>
In order for DenyHosts to easily parse this log format, simply edit your denyhosts.cfg file
and add the following line:<p>
<i>SSHD_FORMAT_REGEX = @.*? (?P<<i>message></i>.*)</i><p>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="2_16"></a>
<p align="right">A. 2.16</p><h2>Why isn't DenyHosts recognizing successful ssh logins?</h2><br>Unfortunately, all log files are not created equally. Depending on the format of your log file,
DenyHosts may not be able to process all of the entries. You can supply a suitable
<a href="#custom_regex">custom regular expression</a> in your configuration file.<p>
For instance, if your log file has the following entry:
<p>
<pre>
error: PAM: authentication error for SOME_VALID_USERNAME from 192.168.1.1
</pre>
Then <a target="x" href="pam_auth_err.txt">adding this to your configuration file</a> should resolve the
issue.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="threshold"></a>
<a name="2_17"></a>
<p align="right">A. 2.17</p><h2>What is the difference between DENY_THRESHOLD_INVALID, DENY_THRESHOLD_ROOT
and DENY_THRESHOLD_VALID and DENY_THRESHOLD_RESTRICTED?</h2><br><i>DENY_THRESHOLD_INVALID</i> - applies to non-existent (aka invalid accounts that do not appear in
/etc/passwd) user accounts<p>
<i>DENY_THRESHOLD_ROOT</i> - applies to login attempts to the <i>root</i> user account<p>
<i>DENY_THRESHOLD_VALID</i> - applies to existent user accounts (those that exist
within /etc/passwd)<p>
<i>DENY_THRESHOLD_RESTRICTED</i> - (New in v2.1) Applies to the optionally defined usernames in
WORK_DIR/restricted-usernames. See <a href="#restricted">restricted users</a> for more
details.<p>
Typically, the value for <i>DENY_THRESHOLD_VALID</i> should be larger than the
<i>DENY_THRESHOLD_INVALID</i> value and the value for <i>DENY_THRESHOLD_ROOT</i> should be less
than <i>DENY_THRESHOLD_INVALID</i>. That is:<br>
<i>DENY_THRESHOLD_ROOT < DENY_THRESHOLD_INVALID < DENY_THRESHOLD_VALID</i>
<p>
<i>DENY_THRESHOLD_RESTRICTED</i> should typically be the same as <i>DENY_THRESHOLD_ROOT</i>.
<p>
As an example, consider a system "myhost" that has a valid user "foo" and an invalid user
"bar" (that is, "foo" exists in the /etc/passwd file on "myhost", whereas "bar" does not).
If a user at host 1.1.1.1 attempts to login to "foo@myhost" more than
<i>DENY_THRESHOLD_VALID</i> then 1.1.1.1 will be blocked (added to the <i>HOSTS_DENY</i>
file). However, if a user at 2.2.2.2 had attempted to login to "bar@myhost" then that IP
address would be blocked after <i>DENY_THRESHOLD_INVALID</i> attempts. If a user at 3.3.3.3
attempted to login to multiple accounts ("foo" and "bar") then the IP address would be
blocked as soon as either threshold was exceeded. <p>
Therefore, at most, a malicious user can attempt to gain access to your system
<i>DENY_THRESHOLD_INVALID</i> + <i>DENY_THRESHOLD_VALID</i> times before being
added to <i>HOSTS_DENY</i>.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="restricted"></a>
<a name="2_18"></a>
<p align="right">A. 2.18</p><h2>Can I specify a set of users that should never be able to login?</h2><br>New in v2.1. DenyHosts now allows you to create a file, <i>restricted-usernames</i> in the
DenyHosts <i>WORK_DIR</i>. The contents of this optional file should contain one username
per line. Each username listed is considered to be a restricted account or simply, any
username that satisfies these scenarios: <p>
<ul>
<li>An account that does not allow logins (such as <i>lpd</i>)
<li>An account that should never login via ssh (such as <i>mysql</i>)
<li>A ficticious username that often is associated with hackers (such as <i>toor</i>)
</ul>
<p>
Any username listed in the <i>restricted-usernames</i> file will be subject to the
<i>DENY_THRESHOLD_RESTRICTED</i> configuration setting (by default this will be set
to <i>DENY_THRESHOLD_ROOT</i>). <p>
To aid in creating a suitable <i>restricted-usernames</i> file there are currently 2 scripts in
the <i>scripts</i> subdirectory:
<ul>
<li><i>restricted_from_passwd.py</i> will parse the /etc/passwd
file, find each of the usernames that have <i>/sbin/nologin</i>, <i>/sbin/halt</i>
or <i>/sbin/shutdown</i> shells and output them to the console. You can either cut-and-paste
these into <i>restricted-usernames</i> or redirect the output to this file.
<li><i>restricted_from_invalid.py</i> will parse DenyHosts invalid login attempts file and
find the most frequently attacked user accounts on your system. You must provide your
WORK_DIR setting on the command line so that this script can locate the necessary file to
parse, namely <i>users-invalid</i>. You can also specify the number of usernames to display,
the default is 10.
</ul>
<p>
<b>Note:</b> This <i>restricted-usernames</i> file is loaded at start-up time so any
changes you make while the DenyHosts daemon is still running will not take effect until
you restart the daemon.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="timestamp"></a>
<a name="2_19"></a>
<p align="right">A. 2.19</p><h2>Can I specify an alternate timestamp format for the DAEMON_LOG file?</h2><br>As of DenyHosts v1.0.1, yes!<p>
By default, DenyHosts (when run in daemon mode) will timestamp log entries with an ISO8061 timestamp
format. This may be undesirable for some users and may not blend easily with 3rd party packages such as
log_check, log_watch, etc). To specify an alternate timestamp format, simply set the
<i>DAEMON_LOG_TIME_FORMAT</i> parameter in the denyhosts.cfg file. It is recommended that you refer to the
man page for <i>strftime</i> for possible values. <p>
A typical alternative timestamp may be <i>Jan 1 22:05:59</i>. To set the <i>DAEMON_LOG_TIME_FORMAT</i> to
this format, insert the following line in your denyhosts.cfg file:<p>
<i>DAEMON_LOG_TIME_FORMAT = %b %d %H:%M:%S</i>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="age_reset"></a>
<a name="2_20"></a>
<p align="right">A. 2.20</p><h2>Can failed login attempts be reset over a period of time?</h2><br>DenyHosts will automatically block hosts that fail to successfully login after a user configured
<a href="#threshold">threshold</a> is exceeded. Starting with version 1.1, DenyHosts will automatically
reset the failed login attempts to 0 when a host fails to login and the previous failed attempt from
this same host exceeds the respective <i>AGE_RESET_*</i> value.<p>
The <i>AGE_RESET_*</i> parameters are optional. If not provided, failed login attempts per host will
not be reset automatically (this is the behavior in previous versions of DenyHosts). The following
parameters can be specified in the DenyHosts configuration file:<p>
<ul>
<li><i>AGE_RESET_VALID</i> - applies to login attempts to existant users (those that appear in /etc/passwd) with the exception of the <i>root</i> user
<li><i>AGE_RESET_ROOT</i> - applies to the <i>root</i> user account
<li><i>AGE_RESET_INVALID</i> - applies to non-existant users (those that do not appear in /etc/passwd)
<li><i>AGE_RESET_RESTRICTED</i> - (new in 2.1) applies to usernames that are optionally defined
in WORK_DIR/restricted-usernames (typically, usernames that appear in /etc/passwd that should not
be able to login, such as "lpd" or "apache")
</ul>
If desired, these parameters and their values can be <a href="#timespec">specified</a> in the
DenyHosts configuration file.<p>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="reset_on_success"></a>
<a name="2_21"></a>
<p align="right">A. 2.21</p><h2>Can failed login attempts be reset automatically?</h2><br>Although the <a href="#age_reset">AGE_RESET_*</a> factility may be ideal for most situations,
DenyHosts v2.1 introduces the optional parameter <i>RESET_ON_SUCCESS</i>.
DenyHosts will automatically block hosts that fail to successfully login after a user configured
<a href="#threshold">threshold</a> is exceeded. If <i>RESET_ON_SUCCESS = yes</i> then the
failed login attempts will be reset to 0 for the respective ip address if a user successfully logs
in from this ip address. The default is <i>RESET_ON_SUCCESS = no</i>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="plugin"></a>
<a name="2_22"></a>
<p align="right">A. 2.22</p><h2>Does DenyHosts support plugins?</h2><br>In v1.1.0 and greater, DenyHosts introduces support for plugin applications to be run when DenyHosts adds
a new entry to the <i>HOSTS_DENY</i> file and when an entry is purged from <i>HOSTS_DENY</i>.<p>
Two optional configuration parameters exist to support plugins. They are:<p>
<ul>
<li><i>PLUGIN_DENY</i> - specifies the program to be run when a host is blocked by DenyHosts
<li><i>PLUGIN_PURGE</i> - specifies the program to be run when a host is no longer blocked by DenyHosts
</ul>
<b>Note</b>: <i>program</i> can be any executable (script, application, etc...).<p>
Each of the executed programs will receive the host (typically the IP address) that was denied/purged as
it's sole argument.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="spawn"></a>
<a name="2_23"></a>
<p align="right">A. 2.23</p><h2>Can TCPWRAPPERS automatically invoke DenyHosts per login attempt?</h2><br>Apparently, yes! Thanks to Tilo Winkler for providing an example of
<a href="http://tdot.blog-city.com/securing_ssh_with_denyhosts.htm" target="x">spawning DenyHosts
from TCPWRAPPERS</a>.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="environ"></a>
<a name="2_24"></a>
<p align="right">A. 2.24</p><h2>Can I dynamically specify configuration values?</h2><br>Starting with DenyHosts version 2.2, you can now specify all or part of a configuration
value to use an environment variable setting. <p>
To specify a dynamically substituted value you specify the portion of the value you
would like to replace using the syntax <i>$[ ... ]</i> where the <i>...</i> maps to an
environment variable name.
<p>
Notes: the environment variable must be specified in UPPERCASE and will be retrieved from the
local environment when DenyHosts is started. Therefor, if you make a change to the underlying
environment variable that you would like DenyHosts to use then you must restart DenyHosts.
<p>
You may wish to do this, for instance, if you run DenyHosts on several servers and would like
to use the same configuration file on each. In this case, you may want to dynamically
specify the server name for the SMTP_SUBJECT option. <p>
<i>SMTP_SUBJECT = DenyHosts report - $[HOSTNAME]</i>
<p>
If the systems HOSTNAME environment variable is defined as <i>foo.bar.com</i> then
the SMTP_SUBJECT will be interpreted as:
<p>
<i>SMTP_SUBJECT = DenyHosts report - foo.bar.com</i>
<p>
All DenyHosts configuration values can be specified to include environment variables in this way.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<h1>Using DenyHosts</h1>
<a name="firsttime"></a>
<a name="3_0"></a>
<p align="right">A. 3.0</p><h2>I've configured DenyHosts, now what?</h2><br>If you have several log files (eg. in your /var/log directory you have ssh server logs with .1,
.2, ... .n) due to log rotation then it is best to process the old files first.<p>
This can be done by invoking DenyHosts with the <i>--file=</i> flag:<br>
$ <i>python denyhosts.py --file=/var/log/secure.log.1</i><p>
Additionally, you can process several files at once:<br>
$ <i>python denyhosts.py --file=/var/log/secure.log.1 --file=/var/log/secure.log.2 .... --file=/var/log/secure.n</i><p>
<b>Note</b>: You must run DenyHosts as <i>root</i> so that it can read /var/log/ files <i>and</i> update the
/etc/hosts.deny file
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="3_1"></a>
<p align="right">A. 3.1</p><h2>Do I need to run DenyHosts as root?</h2><br>If you are running DenyHosts in <a href="#daemon">daemon mode</a> then <i>yes</i> you must run DenyHosts as root.
<p>
In all other cases, such as running DenyHosts from <a href="#cron">cron</a> then technically speaking, <i>no</i>.
However, in order to run DenyHosts as non-root you must ensure that you have read-permissions
on the /var/log/ sshd server logs. Alternatively, you can copy them to a directory where you do have read-permissions.
<p>
Also, in order for DenyHosts to block hosts, it needs write permissions for the /etc/hosts.deny file. DenyHosts will
gladly run without being able to update this file. In this mode, the hosts that should be blocked are written to stdout
(in a form suitable for pasting into /etc/hosts.deny). Also, you can use an <a href="aux">alternate HOSTS_DENY</a>
file (other than /etc/hosts.deny) which may not require root priviledges.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="3_2"></a>
<p align="right">A. 3.2</p><h2>How should DenyHosts be run?</h2><br>Version 0.9.0 introduces <a href="#daemon">daemon mode</a> support. If you run DenyHosts with the <i>--daemon</i>
flag, then DenyHosts will run constantly in the background. See the previous link for more details.
<p>
In addition to the deamon mode, DenyHosts can also be run periodically from the command line. If you do not wish to
use the daemon mode, then I recommend that DenyHosts be run from <a href="#cron">cron</a> on a routine basis.
DenyHosts is fairly lightweight and does not put an excessive drain on system resources. DenyHosts initially checks
to see if the sshd log has changed in size and if it determines that it hasn't, then it exits without further
processing. If the log has changed, DenyHosts only examines the portion that has changed.<p>
The interval between DenyHosts runs is left up to the user. Personally, I run DenyHosts every 10 minutes.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="rotate"></a>
<a name="3_3"></a>
<p align="right">A. 3.3</p><h2>When my logs are rotated will DenyHosts work properly?</h2><br>Yes. DenyHosts checks the first line of your sshd server log file and the file size. It then compares these
values to the previous invocation of DenyHosts. <p>
<ul>
<li>If the first line is different, then DenyHosts will process the entire
log file (since it is assumed that the log has been rotated).
<li>If the first line is the same it then compares the file size to the last runs offset.
<ul>
<li>If they are the same, then DenyHosts assumes that there are no changes and exits.
<li>If the current file size is greater then the last offset, then the
log file is processed from the last offset.
</ul>
<li>When DenyHosts exits it stores the first line of the processed log file and the file offset into the <i>offset</i>
file (which is located in the <i>WORK_DIR</i> that is defined in your <i>denyhosts.cfg</i> file).
</ul>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="3_4"></a>
<p align="right">A. 3.4</p><h2>I want to process the entire log file regardless of the last offset, how can I do this?</h2><br>Although I'm not sure <i>why</i> you'd want to do this, DenyHosts provides the <i>--ignore</i> command line argument for
this purpose.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="3_5"></a>
<p align="right">A. 3.5</p><h2>DenyHosts exits without producing any output, what happened?</h2><br>Since DenyHosts is intended to run from cron, by default it therefor tries to minimize output.
In general, only error conditions are output.<p>
However, if you'd like to see more details of what it's doing, you can supply the <i>--verbose</i> flag on the command
line. <p>
Alternatively, if you'd like to see all of the gory details of what DenyHosts is doing, you can invoke DenyHosts
with the <i>--debug</i> flag. It is recommened, when <a href="#bug">reporting a bug</a> that you supply the output from
running DenyHosts with the <i>--debug</i> flag.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="3_6"></a>
<p align="right">A. 3.6</p><h2>I don't want to receive an email report of hosts added to /etc/hosts.deny.</h2><br>That's not a question.<p>
Seriously, though, if you would like to disable the email reports you can either edit the <i>denyhosts.cfg</i>
file (and set the admin_email value to nothing) or run the script with the <i>--noemail</i> flag supplied.<p>
# in your denyhosts.cfg file:<br>
ADMIN_EMAIL=<p>
# command line:<br>
$ <i>python denyhosts.py --noemail</i>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="allowed"></a>
<a name="3_7"></a>
<p align="right">A. 3.7</p><h2>How can I prevent a legitimate IP address from being blocked by DenyHosts?</h2><br>Since it is quite possible for a user to mistype their password repeatedly it may be desirable to
have DenyHosts prevent specific IP addresses from being added to <i>/etc/hosts.deny</i>. To address
this issue, create a file named <i>allowed-hosts</i> in the <i>WORK_DIR</i>. Simply add an IP
address, one per line. Any IP address that appears in this file will not be blocked.
<p>
Additionally, as of v1.0.3, a valid hostname can also be placed in the <i>allowed-hosts</i> file.
For each hostname appearing in this file, the IP address will be resolved and any ssh connections
that match either this hostname <i>or</i> this resolved IP address will not be blocked.
<i>
# this is a comment line<br>
# the following line prevents DenyHosts from blocking IP address 1.1.1.1<br>
1.1.1.1<br>
# The following lines prevent IP addresses 1.1.1.2 and 1.1.1.3 from being blocked<br>
1.1.1.2<br>
1.1.1.3<br>
# <br>
# The first 3 parts of the IP address must be provided (eg. 1.2.3.)<br>
# The last part of the IP address can be a wildcard.<br>
# The wildcard can be given with an asterisk -or- as a range.<br>
# <br>
# This line prevents all IP address in the 1.1.1 network from being blocked<br>
# 1.1.1.* <br>
# <br>
# This line prevents IP addresses in the range 1.1.1.6 to 1.1.1.23 from being blocked<br>
# 1.1.1.[6-23]<br>
# the following line prevents DenyHosts from blocking the host foo<br>
foo<br>
</i>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="hostname"></a>
<a name="3_8"></a>
<p align="right">A. 3.8</p><h2>What if SSH sometimes logs hostnames rather than IP addresses<br>
How can I prevent these from being blocked?</h2><br>If your versions and configuration of sshd and tcp_wrappers sometimes/always log hostnames
rather than IP addresses then you can have DenyHosts attempt to resolve each IP address in the
<i>allowed-hosts</i> file in order to determine the corresponding hostname. In doing so, any host
that matches either this resolved IP address or the hostname will not be blocked.
<p>
To enable this feature, you must specify the following option in your configuration file:<p>
<i>ALLOWED_HOSTS_HOSTNAME_LOOKUP=yes</i>
<p>
<b>Note:</b> Depending on the number of entries in your <i>allowed-hosts</i> file, this
operation can be network intensive but only at DenyHosts startup. Therefor, It is recommended
that this option only be used when running DenyHosts in <a href="#daemon">daemon mode</a> since
this initialization only occurs once. Additionally, if hostnames never appear in your
<i>SECURE_LOG</i> then you shouldn't set this parameter at all (or set it to <i>no</i>):<p>
<i>ALLOWED_HOSTS_HOSTNAME_LOOKUP=no</i>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="3_9"></a>
<p align="right">A. 3.9</p><h2>DenyHosts reports suspicious login activity for allowed hosts, how can I stop this?
</h2><br>In DenyHosts v0.6.0, a new configuration parameter <i>SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS</i> was
added to address this issue. You can refer to the included denyhosts.cfg-dist file
for more information.
<p>
This parameter can be set to <i>YES</i> or <i>NO</i>. The default value is YES. If you wish to
change
the default behavior and only report suspicious login activity from unknown ip addresses, set this
value to
NO.<p>
Regardless of whether this value is YES or NO, if the suspicious login did not originate from
a known <a href=#allowed>allowed-hosts</a> the activity will always be reported. That is, this
parameter only applies to ip addresses in your allowed-hosts file.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="gzip"></a>
<a name="3_10"></a>
<p align="right">A. 3.10</p><h2>Can DenyHosts process gzipped logfiles</h2><br>Yes. DenyHosts v0.7.0+ will automatically detect whether a log supplied with the <i>-f</i>
parameter is gzipped (based on the <i>.gz</i> file suffix). Some system configurations compress rotated logs using
gzip (eg. <i>/var/log/messages</i> when rotated can be named <i>/var/log/messages.1.gz</i>). To process a gzipped
logfile simply provide the fullpath on the command line using the <i>-f</i> flag (just as if it were a non-gzipped
file): <p>
$ <i>denyhosts.py -f /var/log/secure.log.1.gz</i><p>
When DenyHosts encounters a gzipped logfile it will automatically open it (without uncompressing it on disk) and
process it.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="bzip"></a>
<a name="3_11"></a>
<p align="right">A. 3.11</p><h2>Can DenyHosts process bzipped (bz2) logfiles</h2><br>Yes. DenyHosts v0.8.0+ will automatically detect whether a log supplied with the <i>-f</i>
parameter is bzipped (based on the <i>.bz2</i> file suffix). Some system configurations compress rotated logs using
bzip2 (eg. <i>/var/log/messages</i> when rotated can be named <i>/var/log/messages.1.bz2</i>). To process a bzipped
logfile simply provide the fullpath on the command line using the <i>-f</i> flag (just as if it were a non-bzipped
file): <p>
$ <i>denyhosts.py -f /var/log/secure.log.1.bz2</i><p>
When DenyHosts encounters a bzipped logfile it will automatically open it (without
uncompressing it on disk) and process it.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="migrate"></a>
<a name="3_12"></a>
<p align="right">A. 3.12</p><h2>I've just upgraded to 0.8.0 (or greater) and want to update
my <i>HOSTS_DENY</i> for use with <i>PURGE_DENY</i>
</h2><br><b>Note:</b><br>
You may wish to refer to <a href="#purge">setting the <i>PURGE_DENY</i> configuration parameter</a> for information
related to this entry.
<p>
To instruct DenyHosts to migrate your <i>HOSTS_DENY</i> for use with <i>PURGE_DENY</i> invoke DenyHosts with the
<i>--migrate</i> flag:<p>
$ <i>denyhosts.py --migrate</i><p>
<b>Note:</b><br>
Using the <i>--migrate</i> flag without previously defining a value for the <i>PURGE_DENY</i>
parameter will result in an error condition such that DenyHosts will exit immediately.<p>
When DenyHosts is run with the <i>--migrate</i> flag it locates entries in the
<i>HOSTS_DENY</i> file that have not been been previously timestamped by DenyHosts and
timestamps them (using the current time). The following algorithm is used to update the
<i>HOSTS_DENY</i> file:<p>
<ol>
<li><i>HOSTS_DENY</i> is backed up to a file named <i>HOSTS_DENY.migrate.bak</i>
<li>a temp file is created, <i>HOSTS_DENY.migrate.tmp</i>
<li>the <i>HOSTS_DENY</i> is parsed and each entry that is commented or is a blank link will be written to
<i>HOSTS_DENY.migrate.tmp</i> as-is.
<li>otherwise, each <i>HOSTS_DENY</i> entry will have a comment added in the form of <i> # DenyHosts:
timestamp</i> and then written to <i>HOSTS_DENY.migrate.tmp</i>
<li>after all lines are parsed, <i>HOSTS_DENY.migrate.tmp</i> is moved to <i>HOSTS_DENY</i> (atomically-- such that
even in the case of failure, the <i>HOSTS_DENY</i> should always be present). In the event of a catastrophic
emergency you can manually move the <i>HOSTS_DENY.migrate.bak</i> back to <i>HOSTS_DENY</i>.
</ol>
<p>
<b>Note:</b><br>
If you have a manually added specific hosts to <i>HOSTS_DENY</i> (without the use of
DenyHosts, for instance) then you may wish to edit <i>HOSTS_DENY</i> and remove the timestamp
data that was appended to the line by the <i>--migrate</i> function. You may also wish to do
this for any entry that you <i>never</i> want DenyHosts to remove. Any timestamped entry
will automatically be removed by DenyHosts when it is invoked with the <i>--purge</i> flag
subject to the <i>PURGE_DENY</i> value. Refer to the <a href="#purge">purge section</a> for
more details.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="3_13"></a>
<p align="right">A. 3.13</p><h2>How can I prevent more than one instance of DenyHosts from running?</h2><br>DenyHosts v0.8.0 (and greater) uses the configuration parameter <i>LOCK_FILE</i> which should
point to some unique path. When DenyHosts is run initially it will attempt to create this
file and record it's process id (pid). If it already exists, DenyHosts will exit indicating
that DenyHosts is still running and the pid of the previous process. Upon exit, DenyHosts
will delete the <i>LOCK_FILE</i> so that it will not interfere with other instances (such as
another instance run from cron).<p>
In the event that something goes awry (or if you savagely killed the current DenyHosts
process before it had a chance to delete the <i>LOCK_FILE</i> itself) there is a chance that
the <i>LOCK_FILE</i> will not get deleted. If this occurs, you can manually clear the
<i>LOCK_FILE</i> by invoking DenyHosts with the <i>--unlock</i> flag: <p>
$ <i>denyhosts.py --unlock</i><p>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="email"></a>
<a name="3_14"></a>
<p align="right">A. 3.14</p><h2>Why does DenyHosts report "Error sending email"?</h2><br>Depending on your particular email server you may see an error message such as:<p>
<i>
Error sending email<br>
{'foo@localhost': (504, '<<i>DenyHosts></i>: Sender address rejected: need
fully-qualified address')}</i><p>
If you do receive this error message simply edit your configuration file and enter a fully
qualified email address for the <i>SMTP_FROM</i> parameter. For instance:<p>
<i>SMTP_FROM = DenyHosts <<i>nobody@yourdomain.com></i></i>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="smtp_auth"></a>
<a name="3_15"></a>
<p align="right">A. 3.15</p><h2>Can DenyHosts email reports to SMTP servers that require
authentication?</h2><br>Beginning with version 1.1.1, DenyHosts can email reports to SMTP servers that require
username/password authentication. If your SMTP server requires authentication you will
need to set the following parameters in your denyhosts.cfg file:<p>
<ul>
<li><i>SMTP_USERNAME</i> - your SMTP username.
<li><I>SMTP_PASSWORD</i> - your SMTP password.
</ul>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="daemon"></a>
<a name="3_16"></a>
<p align="right">A. 3.16</p><h2>Can DenyHosts be run as a daemon (background) process?</h2><br>DenyHosts v0.9.0 (and greater) introduces daemon support. When launched with the <i>--daemon</i> flag, DenyHosts
will run in the background and constantly monitor your <i>SECURE_LOG</i> for new activity:<p>
$ <i>denyhosts.py --daemon</i>
<b>Note:</b><br>
The following command line flags are ignored when <i>--daemon</i> is used: <i>--file, --verbose, --migrate,
--purge</i><p>
<b>Note:</b><br>
The daemon mode <b>must</b> be invoked as superuser (root)<p>
There are 3 optional configuration settings specific to daemon mode. You can refer to the included
<i>denhosts.cfg-dist</i> file for sample usage. These new values are:<p>
<ol>
<li>DAEMON_LOG: specifices the path to which DenyHosts should record activity. The default is
<i>/var/log/denyhosts</i>
<li>DAEMON_SLEEP: the amount of <a href="#timespec">time</a> that DenyHosts will pause between checking
for new activity in your <i>SECURE_LOG</i>. The default is <i>30s</i>
<li>DAEMON_PURGE: the amount of <a href="#timespec">time</a> that DenyHosts should attempt to
<a href="#purge">purge</a> historical entries from your <i>HOSTS_DENY</i> file. If left blank, purging will be
disabled. The default is <i>1h</i>
</ol>
<p>
For your convenience there is a python script <i>daemon-control-dist</i> that is located in the DenyHosts
distribution. You should copy this file to <i>daemon-control</i> and edit the 3 variables at the top to match your
environment. If you wish you can place this in your <i>/etc/init.d</i> directory. <p>
You can then invoke this script to control the DenyHosts daemon:
<ul>
<li><i>daemon-control start</i> - stats DenyHosts in daemon mode
<li><i>daemon-control stop</i> - cleanly stops the DenyHosts daemon
<li><i>daemon-control restart</i> - stop and start the daemon
<li><i>daemon-control debug</i> - Instructs the daemon to toggle between the debug and normal log output
<li><i>daemon-control status</i> - display the state of the daemon
</ul>
The <i>start</i> and <i>restart</i> commands (as of v0.9.6) can also accept command line options. For instance to
load an alternate configuration file, you can do the following:<p>
$ <i>daemon-control start --config=test.cfg</i><p>
To restart the above example in <i>debug</i> mode:<p>
$ <i>daemon-control restart --config=test.cfg --debug</i><p>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="3_17"></a>
<p align="right">A. 3.17</p><h2>I have additional questions, where can I get help?</h2><br>You can subscribe to the <a href="http://sourceforge.net/mail/?group_id=131204">DenyHosts Mailing List</a>
<p>
<i>or</i>
<p>
You can <a href="http://sourceforge.net/users/phil_schwartz/">contact me</a> directly.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="bug"></a>
<a name="3_18"></a>
<p align="right">A. 3.18</p><h2>I've found a bug, will you fix it?</h2><br>Bug? That's <i>"unpossible"</i>. <p>
In the rare and highly unlikely event that you do find what <i>you think</i> might be considered a bug (even though it's
really a <i>feature</i>) you can <a href="http://sourceforge.net/tracker/?group_id=131204&atid=720419">report it</a>
at Sourceforge.<p>
When reporting a bug, please try to include the output from DenyHosts when invoking it with the <i>--debug</i> flag:<br>
$ <i>denyhosts.py --debug</i><p>
Alternatively, You can send the bug report to <a href="http://sourceforge.net/users/phil_schwartz/">my Sourceforge
email address</a>.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="work_dir"></a>
<a name="3_19"></a>
<p align="right">A. 3.19</p><h2>What are all of the files in my DenyHosts WORK_DIR?</h2><br>The WORK_DIR contains files that DenyHosts uses for keeping track of the hackers. In addition
to these files that DenyHosts creates and updates there are also some files that are intended
as user editable files (those that which the DenyHosts user creates and edits as appropriate).
<p>
<b>User maintained files (they are optional)</b><p>
<i>allowed-hosts</i> - contains a list of ip addresses that are exempt from being denied by DenyHosts.
For further details refer to the <a href="#allowed">allowed hosts</a> FAQ entry.
<p>
<i>restricted-usernames</i> - contains a list of real or ficticious usernames that should never log into your sshd server.
Refer to <a href="#restricted">restricted usernames</a> for more information.
<p>
<b>DenyHosts maintained files</b><p>
<i>offset</i> - DenyHosts stores the offset of the last position read from your <i>SECURE_LOG</i> file. DenyHosts uses
this to quickly determine if new data is available in your logfile. This file also stores the first line of your log file
such that DenyHosts can determine if the file has been rotated between scans.
<p>
<i>purge-history</i> - (new in 2.4) contains a list of the denied hosts that have been purged from your
<i>HOSTS_DENY</i> file. Additionally, this file records the number of times this host has
been purged and the timestamp of the most recent purge. This file is only created if
DenyHosts is operating in <a href="#purge">purge mode</a>.
<p>
<i>sync-received</i> - a list of the hosts that have been received from the DenyHosts Synchronization server. Refer to <a href="#sync">sync mode</a> for more details.
<p>
<i>sync-timestamp</i> - the last time that synchronization has occurred. Refer to
<a href="#sync">sync mode</a> for more details.
<p>
<i>hosts</i> - a list of all hosts that have attempted to access your sshd server. In addition the file contains the number
of failed attempts and most recent attempt timestamp.
<p>
<i>hosts-restricted</i> -
a list of hosts that have attempted to access restricted username accounts on your server. The
file has the same format as <i>hosts</i>.
<p>
<i>hosts-root</i> - a list of hosts that have attempted to access the root account on your server. The
file has the same format as <i>hosts</i>.
<p>
<i>hosts-valid</i> - a list of hosts that have attempted to access valid username accounts on your server. The
file has the same format as <i>hosts</i>.
<p>
<i>suspicious-logins</i> - a list of suspicious login activity (that is, logins that were successful after the deny threshold
should have been reached).
<p>
<i>users-hosts</i> - a list of usernames along with the ip address that attempted to login to your sshd server. This file
also contains the number of attempts for the username/ip address along with the most recent timestamp.
<p>
<i>users-invalid</i> - a summary of non-existent usernames that were used in order to login to your server.
The file also
contains the number of attempts per usernames and the most recent timestamp.
<p>
<i>users-valid</i> - a summary of all existing usernames (including 'root') that attempts to login to your sshd server.
The file also contains the number of attempts per usernames and the most recent timestamp.
<p>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<h1>DenyHosts Synchronization Mode</h1>
<a name="sync"></a>
<a name="4_0"></a>
<p align="right">A. 4.0</p><h2>What is synchronization mode?</h2><br>DenyHosts v2.0 and later introduces <i>synchronization mode</i> which allows DenyHosts daemons the
ability to transmit denied host data to a central remote server (hosted by denyhosts.net).
Additionally, DenyHosts daemons can also receive data that other DenyHosts daemons have sent to
the central server.
<p>
This feature is intended to provide the ability to proactively deny ip addresses that have attacked
other users of DenyHosts. That is, each DenyHosts 2.0 (or later) user can benefit from other
users of Denyhosts. Similarly each DenyHosts user can benefit other DenyHosts users.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="4_1"></a>
<p align="right">A. 4.1</p><h2>What is denyhosts.net?</h2><br><a href="http://www.denyhosts.net">www.denyhosts.net</a> is the new home of DenyHosts operated
by the creator of DenyHosts.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="4_2"></a>
<p align="right">A. 4.2</p><h2>How does synchronization mode work?</h2><br>DenyHosts daemons periodically connect (based on the configuration file parameter
<i>SYNC_INTERVAL</i>) to the denyhosts.net remote server.
If hosts have been denied by this daemon then they will
automatically be transmitted to denyhosts.net. If new hosts have been denied by others (that is,
other users running DenyHosts in synchronization mode), then they will be added to your
<i>HOSTS_DENY</i><pre> </pre>file automatically (based on your
<i><a href="#sync_download_threshold">SYNC_DOWNLOAD_THRESHOLD</a></i> setting).
This allows your DenyHosts daemon to proactively deny hosts that have not
yet attacked you.
<p>
Each time that your DenyHosts daemon connects to the denyhosts.net server, only the data that
has changed since the last data synchronization is transmited.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="4_3"></a>
<p align="right">A. 4.3</p><h2>What are the requirements for synchronization mode?</h2><br>To use DenyHosts in synchronization mode, you must be using DenyHosts 2.0 or later.
Additionally, DenyHosts must be running in <a href="#daemon">daemon mode</a>
(such that it will periodically synchronize with the denyhosts.net server).
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="sync_default"></a>
<a name="4_4"></a>
<p align="right">A. 4.4</p><h2>Is synchronization mode enabled by default?</h2><br>No. To enable DenyHosts in synchronization mode you must explicitly enable it.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="sync_enable"></a>
<a name="4_5"></a>
<p align="right">A. 4.5</p><h2>How do I enable synchronization mode?</h2><br>You must add or modify several parameters in your DenyHosts configuration file
(typically, <i>denyhosts.cfg</i>).
<p>
<b>Note:</b> If you are upgrading DenyHosts to 2.0 (or later) from v1.x
then you will need to add several parameters to the configuration file. The
<i>denyhosts.cfg-dist</i> file contains several new parameters for synchronization mode.
These parameters should be manually copied to your DenyHosts configuration file.
<p>
The parameters pertaining to synchronization mode support are prefixed with <i>SYNC_</i>.
They are: <p>
<i>
<ul>
<li><b>SYNC_SERVER</b> - required
<li>SYNC_INTERVAL
<li>SYNC_UPLOAD
<li>SYNC_DOWNLOAD
<li>SYNC_DOWNLOAD_THRESHOLD
<li>SYNC_DOWNLOAD_RESILIENCY - (version 2.1 or later)
</ul>
</i>
To enable synchronization mode <i>SYNC_SERVER</i> must be defined. Currently, the corresponding
value must be set to <i>http://xmlrpc.denyhosts.net:9911</i>
<p>
If the <i>SYNC_SERVER</i> parameter is not defined then synchronization mode will be disabled. <p>
<b>Note:</b> by default synchronization mode is disabled. To enable it (recommended) you
<i>must</i> add the following to your configuration file:<p>
<i>SYNC_SERVER = http://xmlrpc.denyhosts.net:9911</i>
<p>
The other synchronization mode parameters are optional.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="4_6"></a>
<p align="right">A. 4.6</p><h2>How do I configure synchronization mode?</h2><br>Assuming you have edited your configuration file to
<a href="#sync_enable">enable synchronization mode</a> you can tweak the behavior of DenyHosts
synchronization mode by specifying appropriate values for the optional configuration parameters.
These parameters have no effect if synchronization mode is disabled (which is the default).
<p>
<i>SYNC_INTERVAL</i> - Specifies the length of time between synchronization attempts.
By default, this value is 1 hour. The minimum allowed value is 5 minutes. If your DenyHosts
daemon has not recorded any additional rogue hosts since the previous synchronization then
no data will be uploaded to denyhosts.net. If no new DenyHosts (that meet your
<i>SYNC_DOWNLOAD_THRESHOLD</i> and <i>>SYNC_DOWNLOAD_RESILIENCY</i> settings) are available
from the denyhosts.net server, then no hosts will be downloaded by your daemon.
<P>
<i>SYNC_UPLOAD</i> - Allow your DenyHosts daemon the ability to upload data. The default is "yes".
<p>
<i>SYNC_DOWNLOAD</i> - Allow your DenyHosts daemon the ability to transmit data. The default is "yes".
<p>
<i><a href="#sync_download_threshold">SYNC_DOWNLOAD_THRESHOLD</a></i> - Only download recently
denied hosts that have been blocked by this number of other DenyHosts daemons.
<p>
<i><a href="#sync_download_resiliency">SYNC_DOWNLOAD_RESILIENCY</a></i> - Only download ip addresses
that have been attacking other servers for atleast this length of time.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="4_7"></a>
<p align="right">A. 4.7</p><h2>Can I just send denied data?</h2><br>If you wish to only provide data (of the hosts that your DenyHosts daemon has blocked)
to the denyhosts.net server but not receive hosts that have been denied by others you can set
your <i>SYNC_DOWNLOAD</i> to <i>no</i>. The default is <i>yes</i> but only applies if
synchronization mode has been enabled.
<p>
<i>SYNC_DOWNLOAD = no</i>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="4_8"></a>
<p align="right">A. 4.8</p><h2>Can I just receive data?</h2><br>If you wish to only receive data (that other DenyHosts daemons have thwarted) but
not provide any data (that your DenyHosts daemon has blocked) to denyhosts.net then
you can do so by setting your <i>SYNC_UPLOAD</i> to <i>no</i>.
The default is <i>yes</i> but only applies if synchronization mode has been enabled.
<p>
<i>SYNC_UPLOAD = no</i>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="4_9"></a>
<p align="right">A. 4.9</p><h2>When receiving denied data will I get all denied hosts?</h2><br>When your DenyHosts daemon initially connects with the denyhosts.net server it will
download the most recent attacks that have been reported by other DenyHosts daemons.
<p>
Subsequently, subject to your <i>SYNC_INTERVAL</i> setting, when your DenyHosts daemon
connects with the denyhosts.net server only the data that has changed since it's last
connection will be transmitted. That is, if there are a total of 1000 denied hosts in the
system but only 5 have been added (or re-added) since the last synchronization, then only
the 5 will be transmitted to your DenyHosts daemon.
<p>
<a name="sync_download_threshold"></a>
Additionally, you can set your <i>SYNC_DOWNLOAD_THRESHOLD</i> to qualify the data being
transmitted such that you have more confidence in it. That is, each time a host is added
to the denyhosts.net server a counter is incremented for that ip address. If
your <i>SYNC_DOWNLOAD_THRESHOLD = 1</i> and the counter for an ip address is 1 (that is, a single
DenyHosts daemon transmitted this address) then your DenyHosts daemon would download it. However,
if your <i>SYNC_DOWNLOAD_THRESHOLD = 4</i> then your DenyHosts daemon would not download this
ip address until 3 other DenyHosts clients transmitted the data.<p>
<a name="sync_download_resiliency"></a>
DenyHosts 2.1 adds the <i>SYNC_DOWNLOAD_RESILIENCY</i> setting. Resiliency is defined as the
timespan between a hackers first known attack and it's most recent attack. This value is used in
conjunction with the <i>SYNC_DOWNLOAD_THRESHOLD</i> value and only hosts that satisfy both
values will be downloaded. This value has no effect if <i>SYNC_DOWNLOAD_THRESHOLD = 1</i>.
<p>
Example:
<p>
If the centralized denyhosts.net server records an attack from an ip address at 12 PM
and then again at 2 PM, the resiliency of the offending ip address is 2 hours.
Specifying a <i>SYNC_DOWNLOAD_RESILIENCY = 4h</i> (4 hours) will not download this ip address.
However, if the attacker is recorded again at 5 PM then the ip address will be downloaded
by your DenyHosts instance since the ip address has been resilient for 5 hours (12 PM until 5 PM).
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="4_10"></a>
<p align="right">A. 4.10</p><h2>How do I know that DenyHosts synchronization mode is working?</h2><br>Check your <i>DAEMON_LOG</i> file (typically /var/log/denyhosts). You will see entries
similar to the following:
<pre>
Feb 04 07:42:51 - sync : INFO received 0 new hosts
Feb 04 07:52:52 - sync : INFO sent 1 new host
Feb 04 07:52:52 - sync : INFO received 0 new hosts
Feb 04 08:02:52 - sync : INFO received 1 new host
</pre>
If you see errors, such as "connection refused" that would indicate that the centralize denyhosts.net
server is down (perhaps for maintenance). Once the server is restarted, any ip addresses that
your DenyHosts daemon has recorded since the last successful synchronization will be sent (if
your <i>SYNC_UPLOAD</i> is not set to "no").
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="sync_disable"></a>
<a name="4_11"></a>
<p align="right">A. 4.11</p><h2>I decided that I don't want to use synchronization mode, how do I disable it?</h2><br>In the unlikely event that you don't find synchronization mode useful you can easily disable it
by commenting out the <i>SYNC_SERVER</i> line in your configuration file. You will then need to
restart the DenyHosts daemon for the setting to take effect.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="4_12"></a>
<p align="right">A. 4.12</p><h2>How long will retrieved ip addresses remain in my HOSTS_DENY file?</h2><br>Addresses obtained by your DenyHosts daemon via synchronization download will be
subject to <a href="#purge">purging based on your <i>PURGE_DENY</i></a>
configuration setting. It is therefor suggested that you set a reasonable
<i>PURGE_DENY</i> value to keep your <i>HOSTS_DENY</i> file from growing
excessively large.
<p>
If the optional <i>PURGE_THRESHOLD</i> (new in v2.4) value is defined and not 0 (zero) then
a host will be purged atmost this many times. That is, if this value is set to 3, then DenyHosts
will purge a host atmost 3 times. After the host has been purged 3 times the host will remain in
your <i>HOSTS_DENY</i> forever, effectively blocking it forever (unless you change this setting).
If this value is set to 0 (the default) then DenyHosts will purge each host indefinitely
(that is, each host can be added and purged repeatedly without being blocked permanently).
<p>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="cost"></a>
<a name="4_13"></a>
<p align="right">A. 4.13</p><h2>What is the cost of the synchronization service?</h2><br>Currently there are no plans to charge for this service and I encourage anybody that
finds this feature (and DenyHosts in general) useful to <a href="#donate">donate</a>.
I am using my personal resources (servers, bandwith, etc) to provide this service to
the growing DenyHosts community. By using my own resources, there may come a time
when I am forced to charge for this service, however, it would almost certainly remain
free to individual users.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="privacy1"></a>
<a name="4_14"></a>
<p align="right">A. 4.14</p><h2>What information is collected from me?</h2><br>When your DenyHosts daemon connects with the denyhosts.net server
your ip address is transmitted (the same is true when you use your web browser to access
any internet site). Your ip address will never be shared and may be used
internally to track suspicious activity. Your ip address is also used to q
ualify the uniqueness of the denied hosts that are maintained by the
denyhosts.net server <p>
If you enable synchronization uploads, then, in addition to your ip address
being sent, all recently denied ip addresses that your DenyHosts daemon has
thwarted will be transmitted. This is of course the desired behavior and provides
all DenyHosts daemons (that have synchronization download enabled) the ability
to proactively block rogue hosts.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="privacy2"></a>
<a name="4_15"></a>
<p align="right">A. 4.15</p><h2>How will information collected from me be used?</h2><br>Although denyhosts.net may use your ip address for monitoring suspicious
behavior this information will never be transmitted to other DenyHosts daemon
clients or provided to any 3rd parties. That is, your ip address will not
be shared.<p>
The hosts that your DenyHosts daemon denies will of course be shared with
other DenyHosts daemons. Additionally, this data may be shared with
3rd parties at the discretion of the creator of DenyHosts.
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="aup"></a>
<a name="4_16"></a>
<p align="right">A. 4.16</p><h2>What is the acceptable use policy of the data that denyhosts.net provides?</h2><br>The ip addresses that are downloaded from the denyhosts.net server (for instance, by DenyHosts
daemons that have synchronization download enabled) may not be used for any commercial
purpose nor can this data be shared with the intent of profiting from it. That is, if anybody is going
to make money from the data collected it should be me!
<a href="#top"><p align="right">Return to top</p></a>
<hr>
<a name="license"></a>
<a name="4_17"></a>
<p align="right">A. 4.17</p><h2>I administer many commercial servers, can I run my own denyhosts.net server?</h2><br>You may wish to run your own (aka local) denyhosts.net server to synchronize all
DenyHosts daemons within your organization-- that is, if one server is attacked then
the other servers on your network will automatically be protected from the attacker
(based on their individual <i>SYNC_INTERVAL</i> settings). The information collected
by the local denyhosts.net server can be used by your organization for any legal purposes
and would not be shared with other DenyHosts daemons (those that are not part of your network).
<p>
Currently, the server that denyhosts.net uses to interact with DenyHosts daemons is not
publicly available. You may <a href="http://sourceforge.net/users/phil_schwartz/">contact me</a>
if you would like to license the server component. <p>
<a href="#top"><p align="right">Return to top</p></a>
<hr>
</td></tr></table></body></html>
<p>
<fieldset>
<font size=-3>
<center>
<a href="index.html">Home</a> |
<a href="faq.html">FAQ</a> |
<a href="links.html">Links</a> |
<a href="features.html">Features</a> |
<a href="http://sourceforge.net/project/showfiles.php?group_id=131204">Download</a> |
<a href="http://sourceforge.net/projects/denyhosts/">SourceForge</a>
</font>
</center>
</fieldset>
</td>
</tr>
</table>
</body>
</html>
|