LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
LinkBack Search this Thread
Old 03-14-2005, 11:44 PM   #121
johnnydangerous
Member
 
Registered: Jan 2005
Location: Sofia, Bulgaria
Distribution: Fedora Core 4 Rawhide
Posts: 431

Rep: Reputation: 30

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?
 
Old 03-15-2005, 12:27 AM   #122
sumithmk
LQ Newbie
 
Registered: Mar 2005
Location: kannur
Posts: 1

Rep: Reputation: 0
 
Old 03-15-2005, 01:02 AM   #123
johnnydangerous
Member
 
Registered: Jan 2005
Location: Sofia, Bulgaria
Distribution: Fedora Core 4 Rawhide
Posts: 431

Rep: Reputation: 30
are you posting something?

in short
#iptables -A LOGDROP -p tcp -m tcp --dport 25 -m limit --limit 1/sec -j LOG --log-prefix "spam_blacklist" #--log-level 7

this log level is not working how to seperate traffic in different files
 
Old 03-17-2005, 02:12 PM   #124
penguinlnx
Member
 
Registered: Mar 2005
Location: Ice Station Alert AFB
Distribution: Gentoo
Posts: 166

Rep: Reputation: 30
...better passwords???

(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.
 
Old 03-17-2005, 02:54 PM   #125
johnnydangerous
Member
 
Registered: Jan 2005
Location: Sofia, Bulgaria
Distribution: Fedora Core 4 Rawhide
Posts: 431

Rep: Reputation: 30
multi handshake would work perfect for me but how?
 
Old 03-18-2005, 08:58 AM   #126
penguinlnx
Member
 
Registered: Mar 2005
Location: Ice Station Alert AFB
Distribution: Gentoo
Posts: 166

Rep: Reputation: 30
SuperPassword

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.
 
Old 03-18-2005, 09:26 AM   #127
penguinlnx
Member
 
Registered: Mar 2005
Location: Ice Station Alert AFB
Distribution: Gentoo
Posts: 166

Rep: Reputation: 30
Solution B: simultaneous handshakes.

Another scenario:

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.
 
Old 03-18-2005, 02:37 PM   #128
johnnydangerous
Member
 
Registered: Jan 2005
Location: Sofia, Bulgaria
Distribution: Fedora Core 4 Rawhide
Posts: 431

Rep: Reputation: 30
I don't think I follow your signature
 
Old 03-18-2005, 08:35 PM   #129
Gibsonist
Member
 
Registered: Mar 2004
Location: Meersburg (GER)
Distribution: Cygwin,RH 7.2 7.3, SuSe 6.4 8.2 9.1,TinyLinux, Debian Sarge, Knoppix 3.*, Knoppicilin, Knoppix STD
Posts: 191

Rep: Reputation: 30
Personally - leaving out the annoyance and bandwidth usage-

securing SSH with

- Public/Private keys auth (and getting rid of the password auth),

- only allowing a small group of users to connect from a small number of known hosts/networks (if practical)

and
- enforcing complex passwords (wasn't there a option somewhere about this, well a crond john does the job too)

should actually keep the system secure, as the connecting part must have a key and must be a user that is allowed to connect.

the only risk now being that a DoS is launched
 
Old 03-19-2005, 02:55 AM   #130
penguinlnx
Member
 
Registered: Mar 2005
Location: Ice Station Alert AFB
Distribution: Gentoo
Posts: 166

Rep: Reputation: 30
Denial of Service Attack:

-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.
 
Old 03-21-2005, 09:25 AM   #131
antony.booth
LQ Newbie
 
Registered: Oct 2004
Location: UK
Distribution: Fedora
Posts: 23

Rep: Reputation: 15
A script

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.
 
Old 03-22-2005, 01:33 PM   #132
bravored
LQ Newbie
 
Registered: Mar 2005
Posts: 15

Rep: Reputation: 0
Hey All,

Anyone know how to enable the logging feature to it?
I would like to know if the user uploaded or downloaded.

Thanks
Joe
 
Old 03-27-2005, 12:43 PM   #133
emetib
Member
 
Registered: Feb 2003
Posts: 482

Rep: Reputation: 33
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.

Last edited by emetib; 03-27-2005 at 12:48 PM.
 
Old 03-28-2005, 11:43 AM   #134
Tudor Stefan
LQ Newbie
 
Registered: Mar 2005
Posts: 2

Rep: Reputation: 0
Thank you kindly. This information is very usefull for me. Great site! Thanks again!

-------------------------------------------------------------------------------------------------------
<link removed by moderator - please stop spamming our site>

Last edited by Capt_Caveman; 03-28-2005 at 04:58 PM.
 
Old 03-28-2005, 01:33 PM   #135
johnnydangerous
Member
 
Registered: Jan 2005
Location: Sofia, Bulgaria
Distribution: Fedora Core 4 Rawhide
Posts: 431

Rep: Reputation: 30
Quote:
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!
 
  


Reply

Tags
hostsdeny, keys, ssh


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ssh...log files that store the login attempts Bgrad Linux - Networking 4 03-29-2010 09:40 AM
Failed SSH login attempts Capt_Caveman Linux - Security 38 01-03-2006 03:22 PM
ssh login attempts from localhost?! sovietpower Linux - Security 2 05-29-2005 01:19 AM
SSH login attempts - how to get rid of the automated malware? alexberk Linux - Security 1 05-24-2005 04:57 AM
How do I block IP's to prevent unauthorized SSH login attempts? leofoxx Linux - Security 6 05-23-2005 09:36 PM


All times are GMT -5. The time now is 04:40 PM.

Main Menu
 
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: @linuxquestions
Open Source Consulting | Domain Registration