Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
yes this works but I want to reduce file size of /var/log/iptables by not logging stuff like DST=255.X.X.X and redirecting sshd in another file can someone help me at least at the first part?
(1) Avoiding dictionary words seems lame if password cracking software flys through every letter/number combo.
(2) In the ASCII days of DOS/pascal I could type in keystrokes by holding down(was it ALt keys?) and typing in the code number on the numeric pad, to get characters not normally type-able on the keyboard. This would surely still defeat average password guessers locally...if it was still possible to do that...
(3) But is there an equivalent for remote loggers? (i.e., impossible characters?)
(4) On a single-user system with Linux, where ONLY local users need to sign on, how can you disable entirely the ability to sign on remotely? Doesn't that completely solve the password cracking problem for those cases?
(5) Would expanding password routines to either unicode, or a simple two-password layer render all that cracking-ware obselete?
(6) What about a simple zero-knowledge probability multiple question handshake? It seems to me they had those kind of solutions back in the days of BYTE magazine!
(7) Is there anything in Linux out-of-the-box Distros like Gentoo that leave doors open when the default should be disabled for single users who never forsee needing remote log-ons, like MicroSlime Spyware Operating Systems do?
I can't seem to get a very clear answer on the (in)vulnerabiliity of Linux for dummies.
Actually I just thought of an extremely simple (and should be easy to impliment) password scheme:
Using the heuristic advantage of a real user (versus a brute force attacking program):
(1) Your machine waits as usual for an attempt to log on.
(2) You accept a 'password' of up to 255 characters (probably an arbitrary length limit...)
(3) Your machine scans the password string for a group of 5 or so 'words' which have no real connection
generally in the 'real world' (any more than any group of words from a 50,000 word dictionary).
(4) These words however, are connected by private knowledge of the user making the connection,
(e.g. : he has a cat named 'Binky', wears 'blue' socks and 'shaves'. )
(5) The idea of searching for an arbitrary group of 'keywords' in the string in any order makes checking simple and coding fast and small, while for the REAL user they are easy to remember and allow for an incredible increase in the complexity and number of possible wrong passwords, to defeat the hacker.
Keep in mind you are not limited to 'real' words, and a dictionary search no matter how large would fail.
(6) Just a few extra 'words' in the string in any order increases the number of possible entries beyond hope of brute force 'pounding' at current communication speeds. its not the speed of the computer searching for the key, but the speed of internet communication that makes cracking impossible.
(7) Real remote users only need a 'cheat sheet' they have made themselves, answering their own questions.
They can enter their combination of 'passwords' (including alphanumeric strings) in any order, and most importantly, they can re-try as many times as they like since you don't need to cut them off to stop brute-force hackers.
(8) You can cut off REAL brute-force attacks anyway, if they log in 1000 attempts per day, since no real remote user would do that.
In other words, you handle at your end in a simple software routine the problem of entering and checking REALLY LONG passwords.. and having your REAL clients remember them. The security boost would be astronomical.
You have an extra 'test' before allowing your 'client' to sign on:
.........If (PASSWORDGOOD) and (CONDITIONX=TRUE) then AllowUserToConnect;
ConditionX: A set of unused ports (on your machine) simply poll for a connection 24/7.
Your client has a program that simply connects his computer to yours via these ports.
Only you and he (your software and his) know what port of the set it should be.
The client's password only works when his machine is already connected to yours via the port.
Everytime a client successfully logs on, a random number generator decides what port from an
available list will be valid NEXT TIME he tries to log on. The list of ports can be quite small, since
clients only need to be connected for a short instant during password confirmation, and can be used again by another customer almost instantly.
His software pack could alternately generate a seeded random string quite long, to be prefixed to his password on each logon or attempt. Without knowing the seeded random generator, and being in sync with it, a remote logger cannot complete the hidden part of the password and log on. the complete password itself would be too long to crack reasonably.
Your software can check not only who is logging on the secret ports, but you can use hacker technology
yourself by setting up zombie machines that must connect to the ports at the right time, after being activated by the user. Then crackers can wack away at unlistened-to ports, for all practical purposes just wasting their own time, but not tying up real ports or functions on your server system.
-Correct me if this would fail, but wouldn't just providing an encrypted list of your (TRUE) port assignments and usages via public/private key (both ways) and only opening standard ports at pre-arranged times for setup purposes solve the 'DoS' problem?
Example:
(1) Your user connects in the standard way to subscribe to the service first at a prearranged time.
(security for this stage of operations is based upon time and IP address, as well as key info mailed out or over phone/radio )
(2) You close down all ports on your unique server (leading to your LAN if you like) normally.
(your client accesses unlisted ports at key times with ports, passwords, etc. rotated based upon info exchanged via previous connections, to allow you to schedule through the secure link.
This would be driven by software no more complex than that for scheduling chess matches.)
(3) DoS attempts now fail to hit any targets at all, due to limitations of bandwidth and time constraints.
In case anyone is interested, I have created the following script that adds ip subnets to both the hosts.deny file and the iptables.
It actually adds an entire /24 subdomain (###.###.###.0/255.255.255.0). This is so people with dynamic ip addresses are more likely to be blocked when they renew the lease.
IT DOES NOT BLOCK INVALID LOCAL USERS THAT ARE ON THE SAME CLASS C (/24) SUBNET AS THE SERVER AS DETERMINED BY COMMAND "hostname -i"
Its limitations are as follows:-
o It only compares "host.deny" and log file "secure" for new entries.
o It updates a file with the iptables, which should be restored on reboot using iptables-restore
o It has only been tested on RH ES linux and uses commands such as hostname, egrep etc. Some of these aren't fully qualified, so you should either edit the script accordingly, or make sure the PATH envronment variable includes the directories for these programs.
It could do with being more efficient, but I just wanted something quick.
Don't ask for support and use at your own risk.
Code:
#!/bin/bash
# Update ban list: Useful as a cron task.
# This script updates the hosts.deny file and adds an iptable deny entry with
# all those IP subdomains that attempted to connect using an invalid user ID.
# If a hacker attempts to use the same IP subnet ###.###.###.* (/24), they will
# be blocked.
# Note: IP Addresses that match the subnet of the server are not banned
# By Antony Booth, March 2005
declare -a inList;
declare -a outArray;
outFile="/etc/hosts.deny";
logFile="/var/log/secure";
iptables="/sbin/iptables";
save="/sbin/iptables-save";
# This should be used with 'iptables-restore' in a startup script in /etc/init.d
# E.G: iptables-restore -n /etc/sysconfig/iptables
dataFile="/etc/sysconfig/iptables";
# For getting first 3 parts (/24) of the dotted quad 255.255.255.*
regExp="^(25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9])\.(25[0-5]
|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9]|0)\.(25[0-5]|2[0-4][0-9]|[0
-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9]|0)\.";
# Get Local /24 domain
localDomain=`hostname -i | egrep -o ${regExp}`;
# Add the ip addresses in list inList to outArray if they're not
# already there.
function groupAddresses()
{
# iterate the list of addresses found
for i in "${inList[@]}"; do
found=0;
thisIp=`echo "${i}" | egrep -o "${regExp}"`;
if [ "${thisIp}" != "" ]; then
# Exclude local domain
if [ "${thisIp}" = "${localDomain}" ]; then
found=1;
fi;
# Check to see if current IP subdomain is already in the list
if [ "`echo ${outArray[@]} | egrep -o ${thisIp}`" != "" ]; then
found=1;
fi;
# Not found in list, so add it
if [ $found -ne 1 ]; then
outArray[${#outArray[@]}]="${thisIp}";
fi;
fi;
done;
}
# get all the ip addresses using invalid user accounts
inList=(`cat ${logFile} | gawk '/illegal user/ {printf("%s ", $13)}'`);
groupAddresses;
logArray=(${outArray[@]});
unset outArray;
declare -a outArray;
# get the existing subnets from the deny list
inList=(`cat ${outFile} | gawk -F":" '/ALL/ {printf("%s ", $2)}'`);
groupAddresses;
declare -a newDomains;
for i in "${logArray[@]}"; do
if [ "`echo ${outArray[@]} | egrep -o ${i}`" = "" ]; then
newDomains[${#newDomains[@]}]="${i}";
fi;
done;
# set this to 1 if you don't want a date stamp added to the hosts.deny file
label=0;
# Append the list of new banned domains to deny file and IPtables
for i in "${newDomains[@]}"; do
if [ $label -ne 1 ]; then
echo "# `date`" >> ${outFile};
label=1;
fi;
echo "ALL:${i}" >> ${outFile};
rule="-A INPUT -s ${i}0/24 -j DROP";
# save rule to file and apply now
$iptables ${rule};
$save > ${dataFile};
done;
Last edited by antony.booth; 03-22-2005 at 05:38 AM.
from looking at all of the scripts that have been wrote for updating the iptables and just blocking these attempts, i figured that i would share my script that actually tells someone (the isp) about these attempts.
you can get it here. this will ask you to save it. it's a 444 file, so you don't have to worry about it.
other than that, do what others have suggested-
sshd_config- AllowUsers - set this up properly it will disallow anyone not there
set up usernames to more than just a first name
set up good passwds
set up dsa/rsa keys
check your logs
systems should be tightened up from the config files. if people aren't being proactive in their concerns about attempted break ins, they will keep happening. that is, if people are just configing their server, then these kids will keep spreading the scripts, and keep trying others and succeeding.
i feel, it's an opinion, that if the isp doesn't know that this is happening from their blocks, even if it's an infected host, then nothing will change. we have a responsibility, as server operators, to keep the web safe for others and ourselves. when people are only focusing on their own systems security, and not helping others, then we might as well be running a bought os.
Originally posted by emetib from looking at all of the scripts that have been wrote for updating the iptables and just blocking these attempts, i figured that i would share my script that actually tells someone (the isp) about these attempts.
you can get it here. this will ask you to save it. it's a 444 file, so you don't have to worry about it.
other than that, do what others have suggested-
sshd_config- AllowUsers - set this up properly it will disallow anyone not there
set up usernames to more than just a first name
set up good passwds
set up dsa/rsa keys
check your logs
systems should be tightened up from the config files. if people aren't being proactive in their concerns about attempted break ins, they will keep happening. that is, if people are just configing their server, then these kids will keep spreading the scripts, and keep trying others and succeeding.
i feel, it's an opinion, that if the isp doesn't know that this is happening from their blocks, even if it's an infected host, then nothing will change. we have a responsibility, as server operators, to keep the web safe for others and ourselves. when people are only focusing on their own systems security, and not helping others, then we might as well be running a bought os.
I read man, forums but I want to make it right, can you give me quick tip on which command with what args will do a pair of rsa keys and which line in sshd is supposed to make it rsa based authentication and combined with password? thanks in advance!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.