Discussion:
Startup Error Message
(too old to reply)
stef
2009-01-16 00:12:37 UTC
Permalink
Hi,

I installed Mandriva One Spring (2008.1, with KDE 3.5) on a user's laptop
perhaps 8 to 10 months ago.

I checked that all was running well and then disabled the automatic update
check, so that no new packages would be installed and nothing "new" could
go wrong, since I (or anyone else) would not be there personally to fix
anything going wrong.

For months, all was fine, everything worked as planned, computer was being
mostly used for email, and browsing, instant messaging.

No upgrades or new programs have been installed, user did not have root
password.

Then all of a sudden, "/" shows up as full, and user is getting error
messages that kde cannot be started, disk is full, then: problem setting up
interprocess communication with kde, cannot read network connection
in /home/user/DCOPSERVER_localhost_0, please check that DCOPSERVER is
running.

I believe that the network problems could be caused by the underlying "/"
partition being read as full, but not sure.

I am sure "/" is being read as full as a simple df shows / as 100%....
Since no new programs or updates have been installed, this leads me to
believe the bug is there perhaps.

This is all compounded by the fact that the computer is on a different
continent, and I have to guide the compleat newb over the telephone to do
the simplest things to check and run commands--a really painful process.

I tried ssh'ing into the machine remotely (after having the remote user
start sshd) but couldn't do get past the router, perhaps a problem
forwarding the port, not really sure.

I had the user rm -rf * from ~/tmp/
Same from /var/tmp

No improvement.

Did not do: rm -rf .* thinking just the * would take care of all files but
perhaps I was wrong.

I am now being told to do same (delete all files) in /var/ftp
or /var/ftp/pub

But I doubt that will work as I am pretty sure I took out the CD media as
sources and added standard "online" mirrors, etc.

I saw on the internet that some users have been able to fix the DCOP error
message by rm -rf ~/.DCOP*

Any suggestions?
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Bit Twister
2009-01-16 00:25:26 UTC
Permalink
Post by stef
Hi,
I installed Mandriva One Spring (2008.1, with KDE 3.5) on a user's laptop
perhaps 8 to 10 months ago.
I checked that all was running well and then disabled the automatic update
check, so that no new packages would be installed and nothing "new" could
go wrong, since I (or anyone else) would not be there personally to fix
anything going wrong.
For months, all was fine, everything worked as planned, computer was being
mostly used for email, and browsing, instant messaging.
No upgrades or new programs have been installed, user did not have root
password.
Then all of a sudden, "/" shows up as full,
Part of the problem may be since the laptop was not on at 4am Sundays
the log compression is not compressing and deleting old compressed
logs.

Another space waster can be found in $HOME/.thumbnails if /home is
under /.
Peter D.
2009-01-16 01:22:18 UTC
Permalink
on Friday 16 January 2009 11:25
in the Usenet newsgroup alt.os.linux.mandriva
[snip]
Post by Bit Twister
Post by stef
Then all of a sudden, "/" shows up as full,
Part of the problem may be since the laptop was not on at 4am Sundays
the log compression is not compressing and deleting old compressed
logs.
"anacron" does that job. You will have to install it.
An hour or so after the machine is turned on anacron will check to
see which cron jobs where missed while the computer was off - and run them.

Not useful this time around, but having /var on a separate partition
prevents the log files from locking up the system.
Post by Bit Twister
Another space waster can be found in $HOME/.thumbnails if /home is
under /.
/home should definitely be on a separate partition.
--
sig goes here...
Peter D.
Eric
2009-01-16 07:50:01 UTC
Permalink
Post by Peter D.
on Friday 16 January 2009 11:25
in the Usenet newsgroup alt.os.linux.mandriva
[snip]
Post by Bit Twister
Post by stef
Then all of a sudden, "/" shows up as full,
Part of the problem may be since the laptop was not on at 4am Sundays
the log compression is not compressing and deleting old compressed
logs.
"anacron" does that job. You will have to install it.
An hour or so after the machine is turned on anacron will check to
see which cron jobs where missed while the computer was off - and run them.
Not useful this time around, but having /var on a separate partition
prevents the log files from locking up the system.
Post by Bit Twister
Another space waster can be found in $HOME/.thumbnails if /home is
under /.
/home should definitely be on a separate partition.
I like to have boot / tmp var and home on their own partitions.
My current partitioning scheme looks like this:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 46M 32M 12M 74% /boot
/dev/sda5 981M 350M 582M 38% /
/dev/sda6 7.7G 5.2G 2.2G 72% /usr
/dev/sda7 14G 5.6G 7.3G 44% /var
/dev/sda8 52G 38G 15G 73% /home

Its not perfect, might even be a little "over done" but it works out
quite well for me. /var is a little large, next time i will shrink it down a
bit. Its tough trying to come up with a good set of sizes.
Eric
stef
2009-01-16 10:43:57 UTC
Permalink
Post by Peter D.
on Friday 16 January 2009 11:25
in the Usenet newsgroup alt.os.linux.mandriva
[snip]
Post by Bit Twister
Post by stef
Then all of a sudden, "/" shows up as full,
Part of the problem may be since the laptop was not on at 4am Sundays
the log compression is not compressing and deleting old compressed
logs.
"anacron" does that job. You will have to install it.
An hour or so after the machine is turned on anacron will check to
see which cron jobs where missed while the computer was off - and run them.
I can try to install "anacron" but we are assuming the cause of the problem
is as BT outlined, but we are not sure.

Does anacron require configuration, or just install?

Some o the description:

"This package is pre-configured to execute the daily jobs of the
Mandriva Linux system. You should install this program if your system
isn't powered on 24 hours a day to make sure the maintenance jobs of
other Mandriva Linux packages are executed each day."

Seems like pre-configured so just install it and let it do its thing (?)

Does it run as a service? Needs to be enabled?
Post by Peter D.
Not useful this time around, but having /var on a separate partition
prevents the log files from locking up the system.
I hear that before and will do that next time around, along with /var
and /usr (separate partitions).
Post by Peter D.
/home should definitely be on a separate partition.
Home is on a separate partition.
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Bit Twister
2009-01-16 15:41:25 UTC
Permalink
Post by stef
I can try to install "anacron"
Hmmm, no space on /, wonder how the urpmi anacron is going to go. :(
Post by stef
but we are assuming the cause of the problem is as BT outlined,
yes
Post by stef
but we are not sure.
Yes.
Post by stef
Does anacron require configuration, or just install?
No configuration required.
Just verify that the daemon/service is marked On Boot.
Post by stef
Seems like pre-configured so just install it and let it do its thing (?)
If marked to run On Boot
Post by stef
Does it run as a service? Needs to be enabled?
Yes, yes.
stef
2009-01-16 17:45:32 UTC
Permalink
Post by Bit Twister
No configuration required.
Just verify that the daemon/service is marked On Boot.
BT,
Thanks.
How do I do that under normal circumstances? I guess in MCC, System, Manage
Sytem Services, etc.
Problem is on the remote laptop, MCC cannot be started.
User can get to a terminal though.
Which file controls the service/daemon so I can make sure it contains the
parameter to enable anacron on boot....?
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Bit Twister
2009-01-16 18:41:09 UTC
Permalink
Post by stef
Post by Bit Twister
No configuration required.
Just verify that the daemon/service is marked On Boot.
BT,
Thanks.
How do I do that under normal circumstances? I guess in MCC, System, Manage
Sytem Services, etc.
For the GUI gifted, yes.
Post by stef
Problem is on the remote laptop, MCC cannot be started.
User can get to a terminal though.
Which file controls the service/daemon so I can make sure it contains the
parameter to enable anacron on boot....?
To look/check chkconfig --list

for extra points,
man chkconfig
stef
2009-01-16 18:57:04 UTC
Permalink
To look/check     chkconfig --list
for extra points,
man chkconfig
Tx. So I guess it would be: "sudo chkconfig --add anacron --level 345" ?
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Bit Twister
2009-01-16 20:13:53 UTC
Permalink
Post by stef
Tx. So I guess it would be: "sudo chkconfig --add anacron --level 345" ?
Do not bother with --level

You may want to go ahead and boot in the failsafe mode,
cd /tmp

and remove any subdirectories found there.
cd /var/log

and remove any *log* ( that is an asterisk log asterisk ) files.

Then reboot to see what you have.
stef
2009-01-17 12:54:51 UTC
Permalink
Post by Bit Twister
Do not bother with --level
You may want to go ahead and boot in the failsafe mode,
cd /tmp
and remove any subdirectories found there.
cd /var/log
and remove any *log* ( that is an asterisk log asterisk ) files.
Then reboot to see what you have.
That was already done before posting here.
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
David W. Hodgins
2009-01-16 18:55:06 UTC
Permalink
Post by stef
How do I do that under normal circumstances? I guess in MCC, System, Manage
Don't worry about it. When the anacron package is installed, it will be set
to run on boot.

Be aware, that there is a bug in the way anacron is setup. In Mandriva 2008.1,
rebooting the computer between midnight and 4am, will cause cron.daily to be
run 65 minutes after bootup, even if it was run the prior day, as well as the
scheduled 4am run. In 2009.0, rebooting during the day (between 4am and midnight)
will cause the same. Doesn't hurt anything, but the computer will be slow while
cron.daily is running.

Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
stef
2009-01-17 16:31:59 UTC
Permalink
David W. Hodgins wrote:
anage
Post by David W. Hodgins
Don't worry about it. When the anacron package is installed, it will be
set to run on boot.
Be aware, that there is a bug in the way anacron is setup. In Mandriva
2008.1, rebooting the computer between midnight and 4am, will cause
cron.daily to be run 65 minutes after bootup, even if it was run the prior
day, as well as the
scheduled 4am run. In 2009.0, rebooting during the day (between 4am and
midnight) will cause the same. Doesn't hurt anything, but the computer
will be slow while cron.daily is running.
Regards, Dave Hodgins
OK, thanks for that.

By the way, do you know if there is away to tell from a terminal if
Mandriva's software firewall is turned on and if so disable it from the
command line?

( I am also trying to ssh into the box)
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Bit Twister
2009-01-17 17:43:34 UTC
Permalink
Post by stef
By the way, do you know if there is away to tell from a terminal if
Mandriva's software firewall is turned on and if so disable it from the
command line?
shorewall clear will leave the system wide open to the internet. :(
Post by stef
( I am also trying to ssh into the box)
If sshd is running, and you poked a hole in the firewall for ssh, then
there should not be much of a problem.

You could add a rule to /etc/shorewall/rules just for your ip if you like.
Example:

ACCEPT net:$PATS_IP all tcp ssh
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


That tells shorewall to allow whatever ip value that is in the
variable PATS_IP.

For the definition, you put a line in /etc/shorewall/params

# grep PATS_IP /etc/shorewall/params
PATS_IP=96.116.35.20


No need to run with the firewall disabled.

You might want to consider an entry in /etc/shorewall/routestopped
stef
2009-01-17 19:24:17 UTC
Permalink
shorewall clear      will leave the system wide open to the internet.
Tx. There is a NAT routeur anyway--in which I am trying to open port 22 but
cannot ssh into machine so far,
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Bit Twister
2009-01-17 20:16:22 UTC
Permalink
Post by stef
Tx. There is a NAT routeur anyway--in which I am trying to open port 22 but
cannot ssh into machine so far,
Router has to be set to forward incoming ssh attempt to target machine.

On target machine
tail -f /var/log/messages
should show the incoming ssh attempt, Example

Jan 17 14:13:58 wm81 sshd[2358]: Accepted publickey for bittwister
from 192.168.1.131 port 47124 ssh2

Worse comes to worst, you can use wireshark on target machine to prove
if router sends packet to nic.
Aragorn
2009-01-17 16:47:52 UTC
Permalink
On Saturday 17 January 2009 17:31, someone identifying as *stef* wrote
in /alt.os.linux.mandriva:/
Post by stef
By the way, do you know if there is away to tell from a terminal if
Mandriva's software firewall is turned on and if so disable it from the
command line?
( I am also trying to ssh into the box)
/etc/init.d/shorewall status

... should be able to tell you whether firewalling rules are in place - you
may need to be root in order to do that, depending on the permissions on
*/etc/rc.d/initd.d* - but bear in mind that the firewalling scripts are not
*running* during normal system operation. Instead, the default firewalling
rules are applied at system boot-up via scripts that call upon /iptables./

In addition, it would seem odd to me that you were to enable /sshd/ and then
block /ssh/ access via firewalling rules - that seems like a bad Windows
habit to me - except of course in the event that the firewall only
blocks /ssh/ access for a given range of IP addresses while allowing it
from a well-defined other range - e.g. from inside the LAN.
--
*Aragorn*
(registered GNU/Linux user #223157)
stef
2009-01-18 02:29:26 UTC
Permalink
Post by Aragorn
in /alt.os.linux.mandriva:/
Post by stef
By the way, do you know if there is away to tell from a terminal if
Mandriva's software firewall is turned on and if so disable it from the
command line?
( I am also trying to ssh into the box)
/etc/init.d/shorewall status
... should be able to tell you whether firewalling rules are in place -
you may need to be root in order to do that, depending on the permissions
on */etc/rc.d/initd.d* - but bear in mind that the firewalling scripts are
not
*running* during normal system operation. Instead, the default
firewalling rules are applied at system boot-up via scripts that call upon
/iptables./
In addition, it would seem odd to me that you were to enable /sshd/ and
then block /ssh/ access via firewalling rules - that seems like a bad
Windows habit to me - except of course in the event that the firewall only
blocks /ssh/ access for a given range of IP addresses while allowing it
from a well-defined other range - e.g. from inside the LAN.
I'm almost certain I disabled the FW since I new the user was being a NAT
router; but just want to check as I cannot understand whY I cannot ssh into
box if forwarded port 22 in Nat router,,,,,,,,
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Bit Twister
2009-01-18 03:01:10 UTC
Permalink
Post by stef
I'm almost certain I disabled the FW since I new the user was being a NAT
router; but just want to check as I cannot understand whY I cannot ssh into
box if forwarded port 22 in Nat router,,,,,,,,
If you just stop shorewall, it is a blocking firewall. If you use MCC
Security to allow ssh or everything, the firewall is open for ssh work.

You should see a reason/line/message in /var/log/messages when you
make an ssh attempt. Programs involved are sshd, shorewall and
tcpwrappers when using ssh ***@target.ip.here

After that works, you try ssh ***@node.domain.name which
leaves you with getting domain name resolution working.

I assume you have done a successful
ssh $USER@$(hostname --ip-address)
command on the target node before trying from another system.

Whoever does the reject, puts a message in /var/log/messages.

I assume you have done a
ssh -v ***@target.ip.here
ssh -v -v ***@target.ip.here
ssh -v -v -v ***@target.ip.here
to help find the problem.

I also assume you are not trying ssh ***@target.ip.here

If this command
ssh $USER@$(hostname --ip-address) works on target node,
and ***@target.ip.here fails
with no message in /var/log/messages I'll guess port forwarding in NAT
router is not working.
Peter D.
2009-01-17 06:57:57 UTC
Permalink
Post by Bit Twister
Post by stef
I can try to install "anacron"
Hmmm, no space on /, wonder how the urpmi anacron is going to go. :(
Good point.

Sometimes there is space to write small files after long files have
been refused. Also an ordinary user will be refused before root
get refused.

If you can't install anacron you can;
A) leave the computer on so that cron jobs get executed at the standard time,
B) run the scripts in /etc/cron* manually, or
C) rm <stuff you don't want>

[snip]
Post by Bit Twister
Post by stef
Does anacron require configuration, or just install?
[snip]

There is a configuration file /etc/anacrontab but 2009.0 is slightly
broken and ignores it. It runs satisfactorily out of the box.
--
Peter D.
Sig goes here...
Bit Twister
2009-01-17 10:52:19 UTC
Permalink
Post by Peter D.
If you can't install anacron you can;
A) leave the computer on so that cron jobs get executed at the standard time,
B) run the scripts in /etc/cron* manually, or
C) rm <stuff you don't want>
Suggest C since there may be no room for normal cron job to compress logs.
Robert Riches
2009-01-18 00:34:27 UTC
Permalink
Post by Peter D.
Post by Bit Twister
Post by stef
I can try to install "anacron"
Hmmm, no space on /, wonder how the urpmi anacron is going to go. :(
Good point.
Sometimes there is space to write small files after long files have
been refused. Also an ordinary user will be refused before root
get refused.
If you can't install anacron you can;
A) leave the computer on so that cron jobs get executed at the standard time,
B) run the scripts in /etc/cron* manually, or
C) rm <stuff you don't want>
[snip]
Post by Bit Twister
Post by stef
Does anacron require configuration, or just install?
[snip]
There is a configuration file /etc/anacrontab but 2009.0 is slightly
broken and ignores it. It runs satisfactorily out of the box.
Actually, /etc/anacrontab is not ignored. It just looks
that way, because there is a big hostname-dependent delay in
scripts /etc/cron.{daily,weekly,hourly}/0anacron. For more
detail, see

https://qa.mandriva.com/show_bug.cgi?id=45880

HTH
--
Robert Riches
***@verizon.net
(Yes, that is one of my email addresses.)
Peter D.
2009-01-18 01:38:36 UTC
Permalink
Robert Riches wrote:

[snip]
Post by Robert Riches
Post by Peter D.
There is a configuration file /etc/anacrontab but 2009.0 is slightly
broken and ignores it. It runs satisfactorily out of the box.
Actually, /etc/anacrontab is not ignored. It just looks
that way, because there is a big hostname-dependent delay in
scripts /etc/cron.{daily,weekly,hourly}/0anacron. For more
detail, see
https://qa.mandriva.com/show_bug.cgi?id=45880
It looks like you know more about this than I do, but I raised that
bug report. (And you post to it got cc-ed to me.)
--
Peter D.
Sig goes here...
Robert Riches
2009-01-18 01:50:37 UTC
Permalink
Post by Peter D.
[snip]
Post by Robert Riches
Post by Peter D.
There is a configuration file /etc/anacrontab but 2009.0 is slightly
broken and ignores it. It runs satisfactorily out of the box.
Actually, /etc/anacrontab is not ignored. It just looks
that way, because there is a big hostname-dependent delay in
scripts /etc/cron.{daily,weekly,hourly}/0anacron. For more
detail, see
https://qa.mandriva.com/show_bug.cgi?id=45880
It looks like you know more about this than I do, but I raised that
bug report. (And you post to it got cc-ed to me.)
Ahh, you're _THAT_ Peter D. :-)

Thank you for filing that bug report.
--
Robert Riches
***@verizon.net
(Yes, that is one of my email addresses.)
Peter D.
2009-01-20 06:58:15 UTC
Permalink
Robert Riches wrote:

[snip]
Post by Robert Riches
Post by Peter D.
Post by Robert Riches
https://qa.mandriva.com/show_bug.cgi?id=45880
It looks like you know more about this than I do, but I raised that
bug report. (And you post to it got cc-ed to me.)
Ahh, you're _THAT_ Peter D. :-)
Thank you for filing that bug report.
Guilty as charged. ;-)
--
Peter D.
Sig goes here...
stef
2009-01-16 10:45:40 UTC
Permalink
Post by Bit Twister
Part of the problem may be since the laptop was not on at 4am Sundays
the log compression is not compressing and deleting old compressed
logs.
It could be. I will have the user urpmi anacron and leave the computer on
all night to see what happens.... See my reply to Peter D.
Post by Bit Twister
Another space waster can be found in $HOME/.thumbnails if /home is
under /.
Home is a separate partition.
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Bit Twister
2009-01-16 15:32:45 UTC
Permalink
Post by stef
It could be. I will have the user urpmi anacron and leave the computer on
all night to see what happens.... See my reply to Peter D.
No need to leave computer on all night. Anacron will run upon power up.

I returned my neighbor's computer to her after I did a large update.

She asked me if "I had greased it or what".

Since I had powered up the system in the same day, all the batch jobs
had already executed. She defiantly saw a difference on her AMD
Athlon(tm) 64 Processor 3800+ 1 gig memory system 32 bit install.
Post by stef
Post by Bit Twister
Another space waster can be found in $HOME/.thumbnails if /home is
under /.
Home is a separate partition.
I have my $HOME/.bash_logout do a
/bin/rm -rf $HOME/.thumbnails
Peter D.
2009-01-17 07:10:10 UTC
Permalink
Post by Bit Twister
Post by stef
It could be. I will have the user urpmi anacron and leave the computer on
all night to see what happens.... See my reply to Peter D.
No need to leave computer on all night. Anacron will run upon power up.
[snip]

Yes. Anacron exists specifically because some people don't want to leave
their computers running 24x7.
--
Peter D.
Sig goes here...
stef
2009-01-19 23:08:27 UTC
Permalink
Here is what I have done so far.

I had user bypass the router and connect directly to DSL modem which I had
previously set as a bridge (as opposed to NAT).

I tried to have user rm -rf various crap as was suggested here ~/tmp
and /var/log by giving user specific commands to type.

I then had user service start sshd and finally was able to ssh into it as
root but unable to as user.

It may have been for the fact that had no passwords (and was set to
autolog.) I don't know. I did notice that ssh does not seem to let you
log in to a user with no password, and keeps asking you for one--even if
you type <enter> with field blank.

I also tried typing ! as password as I read that users with no passwords get
assigned the ! character but I must have misread. Anyway, didn't work so
had to log in as root.

I then went to ~/tmp and noticed it was NOT empty despite the fact user
should have deleted everything there. So I deleted all.

I then went to /var/log and that was FULL. So deleted all there as well.

I had done the du -axk / | sort -nr | head -n 50 and noticed /var/log was
number 5 on the list....

Thanks guys for the suggestion to delete log files--that was the reason "/"
was showing up as full or 100%.

It instantly went down to 89% (this is a dual boot WinXP/Mandriva One box)
and much less than half is dedicated to Linux (unfortunately.)

Could still not get KDM to run and had to write an etc/sysconfig/desktop
with: DISPLAYMANAGER=kdm in it.

I found and deleted the .DCOP* in ~, even though user had assured me no such
files existed.... I am not sure this was totally necessary but had come up
in the original error message.

I then config'ed sshd to startup automatically at boot with a:
chkconfig sshd on, so I could reboot remotely and log back on without user
being there to restart sshd.

I also had to remove the autologin option for user, and I added a password.

I installed autocron and nano.

I created a brand new user as a substitute for old user, should it prove
necessary to migrate.

If you haven't fallen asleep by now, read on ;)

I then rebooted for the nth time; and kdm started up, showing both users.

Typed in user name and pw; and back in. All pretty much normal.

Except for the fact that user still had some error message to check kdm log
files which is here below--if anyone sees any clues to what else to fix,
please let me know.

<http://pastebin.ca/1312858>

May not even be the right log file.....

Thanks to all of you guys who helped, btw :)

Now back to the latest error message to check kdm log file that Mandriva
gives on boot....
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Bit Twister
2009-01-20 00:34:11 UTC
Permalink
Post by stef
I then had user service start sshd and finally was able to ssh into it as
root but unable to as user.
I ssh in without user password all the time. Then again, I boot system
at runlevel 3, not 5 as you have it setup. My user accounts have passwords.
Post by stef
(and was set to autolog.) I don't know. I did notice that ssh does
not seem to let you log in to a user with no password, and keeps
asking you for one--even if you type <enter> with field blank.
Might be because ~/.bash_profile has a call to keychain on target node.

Or maybe you may have not done a
ssh-copy-id -i ~/.ssh/id_dsa.pub $***@target.node
to send dsa key or rsa key if you did a ssh-keygen -t rsa.

For logging in from a new client, steps are:
cd ~/.ssh
chmod 700 .
chmod 600 *
ssh-keygen -t dsa
and just Enter on phrase question.
ssh-copy-id -i ~/.ssh/id_dsa.pub ***@target.node
Log into target.node
cd ~/.ssh
chmod 700 .
chmod 600 *
Post by stef
<http://pastebin.ca/1312858>
XF86Info stuff seems to indicate some old stuff on an old release.
stef
2009-01-20 13:25:44 UTC
Permalink
Post by Bit Twister
Or maybe you may have not done a
to send  dsa key or rsa key if you did a ssh-keygen -t rsa.
cd ~/.ssh
chmod 700 .
chmod 600 *
ssh-keygen -t dsa
and just Enter on phrase question.
Log into target.node
cd ~/.ssh
chmod 700 .
chmod 600 *
I have not done the above.
But if I set a password for the user account, even without the above I can
log in.
Am I not a safe as I should be not having done that procedure you describe?
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Bit Twister
2009-01-20 14:05:24 UTC
Permalink
Post by stef
I have not done the above.
But if I set a password for the user account, even without the above I can
log in.
Hmmm, you know, I never tried. When I want to learn how to do
something, I'll google to get list of commands. Check documentation
about what each command does. Play with commands on a test machine
and/or test account. Document procedure in my brain book and never
look back.

See snippet at end of post.
Post by stef
Am I not a safe as I should be not having done that procedure you describe?
As I misunderstand it, the procedure creates a key entry in the target
node's .ssh/known_hosts. Anyone trying to sneak in with your account
name on their machine should get a "man in the middle" message and
refuse the ssh connection.

Brain book snippet follows:

$ uh ssh
cannot connect to x server xhost +$(hostname) before ssh
scp ssh fuzzy 69.92.58.44 ***@fuzzy:
sshd config/message /etc/syslog.conf /etc/ssh/sshd_config (set PermitRootLogin no)
ssh01 mkdir ~/.ssh
ssh02 cd ~/.ssh
ssh03 chmod 700 .
ssh04 chmod 600 *
ssh05 ssh-keygen -t rsa/dsa to generate passphrase key which will be stored in
ssh06 the ~/.ssh/id_* files. All RSA/DSA keys listed in file will
ssh07 be able to log in as you after completing RSA authentication.
ssh08 If you are doing this for auto login via ssh, do not supply a password.
ssh09 ssh-copy-id -i of your ~/.ssh/id_*.pub ***@target.node
ssh11 Repeat this process for every ID on every machine you wish to
ssh12 use your *SA key for. For instance, if you wanted to log in as
ssh13 "sysadmin" on the system "remotehost", you would copy the data from
ssh14 your identity.pub file into the ~/.ssh/authorized_keys file on
ssh15 "remotehost".
ssh16 Always set protection tight
ssh17 cd ~/.ssh
ssh18 chmod 700 .
ssh19 chmod 600 *
ssh50 Adding to ssh
ssh51 ***@sshclient:~$ ssh-keygen -t dsa
ssh52 ***@sshclient:~$ ssh-copy-id -i ~/.ssh/id_dsa.pub ***@target.node
ssh53 ***@sshclient:~$ ssh ***@target.node
ssh54 Set protection tight
ssh55 ***@sshserver:~$ chmod 700 .
ssh56 ***@sshserver:~$ chmod 600 .ssh/authorized_keys
ssh57 Above assumes sshd is running on target.node
another backup cmd rsync -rAHv -e ssh /src/ ***@new_machine:/dest
stef
2009-01-20 14:22:29 UTC
Permalink
Bit Twister wrote:

I might have followed an RSA key generation when installing sshd...come to
think of it.

It needs a key to function so it must be there.

I will ssh into it later on and look at the ~/.ssh dir, etc.

Tx.
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Peter D.
2009-01-20 07:11:01 UTC
Permalink
stef wrote:

[snip]
Post by stef
Except for the fact that user still had some error message to check kdm log
files which is here below--if anyone sees any clues to what else to fix,
please let me know.
<http://pastebin.ca/1312858>
[snip]

That looks like it is substantially a copy of /var/log/Xorg.0.log.
There do not seem to be a lot of errors or warnings.

[cut'n'paste]
#
Markers: (--) probed, (**) from config file, (==) default setting,
#
(++) from command line, (!!) notice, (II) informational,
#
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
--
Peter D.
Sig goes here...
stef
2009-01-22 14:25:16 UTC
Permalink
problem is back unfortunately....

"/" is again showing 100%.

Once I ssh into ***@ip, I cannot switch to su
I get an password error message--but I am sure the pw is right since I
changed it a few days ago to a very simple one (during an ssh session.)

$ du -axk / | sort -nr | head -n 50
du: cannot read directory `/etc/lvm/cache': Permission denied
du: cannot read directory `/etc/skel/tmp': Permission denied
du: cannot read directory `/etc/cups/ssl': Permission denied
du: cannot read directory `/tmp/screens/S-root': Permission denied
du: cannot read directory `/lost+found': Permission denied
du: cannot read directory `/var/lib/mlocate': Permission denied
du: cannot read directory `/var/lib/PolicyKit': Permission denied
du: cannot read directory `/var/lib/nfs/statd': Permission denied
du: cannot read directory `/var/lib/nfs/sm': Permission denied
du: cannot read directory `/var/run/hald': Permission denied
du: cannot read directory `/var/run/xdmctl/dmctl': Permission denied
du: cannot read directory `/var/run/sudo': Permission denied
du: cannot read directory `/var/run/PolicyKit': Permission denied
du: cannot read directory `/var/run/ConsoleKit': Permission denied
du: cannot read directory `/var/run/cups/certs': Permission denied
du: cannot read directory `/var/lock/lvm': Permission denied
du: cannot read directory `/var/tmp/kdecache-root': Permission denied
du: cannot read directory `/var/cache/hald': Permission denied
du: cannot read directory `/var/spool/at': Permission denied
du: cannot read directory `/var/spool/cron': Permission denied
du: cannot read directory `/var/spool/cups': Permission denied
du: cannot read directory `/root': Permission denied
du: cannot read directory `/.kde': Permission denied
3888508 /
2193976 /usr
1191384 /usr/lib
1006760 /dead.letter
851296 /usr/share
560500 /var
489164 /var/log
299528 /usr/lib/ooo-2.4
191176 /usr/lib/ooo-2.4/program
184968 /usr/share/locale
127640 /usr/bin
122840 /var/log/messages
122328 /var/log/syslog
121724 /var/log/user.log
105328 /usr/lib/ooo-2.4/share
104124 /usr/share/icons
90984 /var/log/security.log
82404 /usr/lib/aspell-0.60
82372 /usr/share/foomatic
82352 /usr/share/foomatic/db
82332 /usr/share/foomatic/db/source
69888 /usr/share/apps
66948 /usr/share/fonts
64424 /usr/lib/kde3
62536 /lib
61640 /var/lib
61092 /usr/lib/python2.5
58380 /usr/lib/mono
55076 /usr/share/foomatic/db/source/opt
51120 /usr/share/dict
51112 /usr/share/dict/ooo
50656 /usr/lib/seamonkey-1.1.9
46208 /usr/lib/dri
45556 /usr/lib/mono/gac
44924 /usr/share/icons/crystalsvg
42392 /var/lib/rpm
40872 /usr/lib/ooo-2.4/share/template
40856 /usr/lib/perl5
40136 /usr/share/doc
38888 /lib/modules
38884 /lib/modules/2.6.24.4-desktop586-1mnb
38748 /usr/lib/firefox-2.0.0.13
36688 /usr/lib/python2.5/site-packages
35392 /usr/lib/ooo-2.4/share/registry
34564 /etc
32172 /usr/lib/xorg
32100 /usr/share/man
31460 /usr/lib/ooo-2.4/share/registry/res
30544 /usr/lib/xorg/modules
30356 /var/log/security

What is /dead.letter size 1006760 ????

Without root access, I really don't know how to again delete that file is
needed, logs, etc.

$ df
Filesystem Size Used Avail Use% Mounted on
/dev/hda6 3.9G 3.8G 0 100% /
/dev/hda8 1.3G 240M 1012M 20% /home
/dev/hda1 12G 10G 1.3G 89% /media/hd
/dev/hda5 12G 9.7G 1.7G 86% /media/hd2

If I got root access, and cleaned up the logs, etc,; I could always do an
urpmi --auto-update -auto to update the box--perhaps it would fix whatever
problem by updating.... But without root access....
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Jim Whitby
2009-01-22 15:29:34 UTC
Permalink
Post by stef
problem is back unfortunately....
"/" is again showing 100%.
message--but I am sure the pw is right since I changed it a few days ago
to a very simple one (during an ssh session.)
<snip>

ssh in as a user. su -
check in etc/ssh/sshd_config for:
PermitRootLogin without-password
change "without-password" to "Yes" ( no quotes ).

For whatever reason Msec will change it back tonite.

Then you can ssh ***@whatever.net
--
"Ada is the work of an architect, not a computer scientist."
- Jean Icbiah, inventor of Ada, weenie
----------------------
Mandriva Linux release 2009.0 (Official) for x86_64
2.6.27.7-desktop-1mnb AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
----------------------
stef
2009-01-22 16:37:44 UTC
Permalink
Post by Jim Whitby
ssh in as a user. su -
PermitRootLogin without-password
change "without-password" to "Yes" ( no quotes ).
Jim,

I checked and this already in the file....
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
stef
2009-01-22 16:31:14 UTC
Permalink
Post by Jim Whitby
ssh in as a user. su -
PermitRootLogin without-password
change "without-password" to "Yes" ( no quotes ).
For whatever reason Msec will change it back tonite.
Jim,

Thanks but cannot go to su - or any form of it....
su, su -, sudo su -, etc....
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
stef
2009-01-22 16:38:04 UTC
Permalink
Post by Jim Whitby
ssh in as a user. su -
PermitRootLogin without-password
change "without-password" to "Yes" ( no quotes ).
Jim,

I checked and that is already in the file....
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Jim Whitby
2009-01-23 01:04:43 UTC
Permalink
Post by stef
Post by Jim Whitby
ssh in as a user. su -
PermitRootLogin without-password
change "without-password" to "Yes" ( no quotes ).
Jim,
I checked and that is already in the file....
You can ssh ***@whatever.net, but can't do su after you login????

Are you absolutely sure you have the correct root password?
--
"Eureka!" -Professor
"Did you build the Smell-o-scope?" -Fry
"No. I remembered that I built one last year." -Professor
----------------------
Mandriva Linux release 2009.0 (Official) for x86_64
2.6.27.7-desktop-1mnb AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
----------------------
stef
2009-01-23 16:02:18 UTC
Permalink
Post by Jim Whitby
Are you absolutely sure you have the correct root password?
This is now all academical....

While trying to facilitate ssh'ing into box, I had user by pass router
(could not set up router to forward ssh port 22, it just would not stick)
and machine was connected directly to DSL modem. The DSL Modem has been
previously set up as a Bridge to avoid double NAT (on top of Router NAT)
which ended up leaving the machine completely exposed.

It got port scanned and virus came in, gained root access, changed root
password so I could not gain root privileges (so it turns out
the "incorrect password" message in original post was accurate; and started
port scanning other machines form that box, starting up as many as 100
ssh-scan processes, etc.

I finally noticed all that, and shut the box down.

I will have to reinstall from scratch, the Linux OS....from a Live CD.

Live and learn, I suppose.

Some things I would say: use a strong enough password for root, block ssh
and only allow known IP addresses, never run machine without some type of
firewall, etc.
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Aragorn
2009-01-24 00:17:12 UTC
Permalink
On Friday 23 January 2009 17:02, someone identifying as *stef* wrote
in /alt.os.linux.mandriva:/
Post by stef
While trying to facilitate ssh'ing into box, I had user by pass router
(could not set up router to forward ssh port 22, it just would not stick)
and machine was connected directly to DSL modem. The DSL Modem has been
previously set up as a Bridge to avoid double NAT (on top of Router NAT)
which ended up leaving the machine completely exposed.
It got port scanned and virus came in, gained root access, changed root
password so I could not gain root privileges (so it turns out
the "incorrect password" message in original post was accurate; and
started port scanning other machines form that box, starting up as many as
100 ssh-scan processes, etc.
That cannot be a virus. What you're describing is most likely a brute force
or dictionary password /ssh/ attack. The attacker uses a tool that
attempts multiple root logins per second, each time with a new password,
until it succeeds. GNU/Linux has mechanisms to defend itself against this
kind of attacks - read up on PAM, or browse your MCC "security" section for
available settings - but I've been singing the song of not allowing root
logins over /ssh/ for ages now. <grin>

Either way, once the login was successful, the software was installed and
the root password changed by a human user. There are no GNU/Linux viruses
in the wild, and this kind of operation needs human interaction on UNIX.
Post by stef
[...]
Some things I would say: use a strong enough password for root,
... And disallow all direct root logins, both on the console and via ssh.
Don't use the MCC to do it, but edit */etc/sshd/sshd_conf* - or whatever
it's called on your system - and */etc/securetty* yourself. Hint: the
latter should be empty to disallow all root logins at the console.
Post by stef
block ssh
What good would that do? Then why are you running /sshd/ in the first
place?
Post by stef
and only allow known IP addresses, never run machine without some type of
firewall, etc.
The latter is FUD - I'm sorry, but it is; you are spreading your own panic.

A firewall is only needed if you're running a high-profile server with a
known domain name and IP address. A home user should not need any
firewall, unless you are constantly being attacked or portscanned from the
same IP address or range. In that case, you can set up an /iptables/ rule
to drop all packets originating from within that range.

Most people forget that a firewall is intended to block access to a machine
from a given host or range of hosts, and they forget because that's not
what a firewall is used for in Windows, and sadly enough, people tend to
think "the Microsoft way".

If you don't want any services on your machine exposed to the internet, then
don't run them, except when your machine is a server to a LAN and you need
those services there. Then you can start thinking of firewalling, but most
common services - i.e. /ftp,/ /ssh/ - have configuration options to already
specify which hosts/groups/users have access to the system via those
services or not; you do not need a firewall for that.

As for /ftp,/ I personally encourage the use of /sftp,/ which is an
embedded /ftp/ in your /sshd/ server and which uses SSL-encryption. If you
need a GUI browser to connect to it, Konqueror does the job well enough.
IE doesn't recognize it, but too bad for people using IE then.

Sorry for the rant, but your misunderstanding of how these things work leads
to more misunderstanding, with demotivation and fear on top of it, for the
newbie lurkers. Microsoft has been doing a good enough job at spreading
FUD already for years, so we don't need to pour more oil onto that fire.
--
*Aragorn*
(registered GNU/Linux user #223157)
stef
2009-01-24 01:54:22 UTC
Permalink
Post by Aragorn
That cannot be a virus. What you're describing is most likely a brute force
or dictionary password /ssh/ attack. The attacker uses a tool that
attempts multiple root logins per second, each time with a new password,
until it succeeds. GNU/Linux has mechanisms to defend itself against this
kind of attacks - read up on PAM, or browse your MCC "security" section
for available settings - but I've been singing the song of not allowing
root logins over /ssh/ for ages now. <grin>
Either way, once the login was successful, the software was installed and
the root password changed by a human user. There are no GNU/Linux viruses
in the wild, and this kind of operation needs human interaction on UNIX.
It's a moot point but I disagree. I believe the attack cam in from an
another computer infected with same virus/malware, etc.; the program is a
program written in C, that installs itself once root access has been gained
via the brute force or dict. attack; and root password is changed
automatically. I am 95% sure of it.

The "virus" is Linux/Rst-B. It is nothing new...been around for a while.

The "developers" even sign the virus, I forget the name but one was Rootfu.k
(if you know what I mean.)
Post by Aragorn
... And disallow all direct root logins, both on the console and via ssh.
Don't use the MCC to do it, but edit */etc/sshd/sshd_conf* - or whatever
it's called on your system - and */etc/securetty* yourself. Hint: the
latter should be empty to disallow all root logins at the console.
I don't understand what you mean by disallow root login at console. I can't
actually believe that you would not let the sysadmin
su to root; but perhaps I am misunderstand what you are saying.
Post by Aragorn
Post by stef
block ssh
What good would that do? Then why are you running /sshd/ in the first
place?
I never said I wanted to block ssh. That woul be stupid. However, only
allowing it from trusted IP's could be a solution.
Post by Aragorn
A firewall is only needed if you're running a high-profile server with a
known domain name and IP address. A home user should not need any
firewall, unless you are constantly being attacked or portscanned from the
same IP address or range.
That's a ridiculous statement....a firewall IS needed, whether it is a NAT
feature via your DSL or Cable Modem, a router or a software firewall.

That is VITAL and anything to the contrary and extremely bad advice. It
opens you to being port scanned constantly, etc.

There are plenty of zombie machines out there that each day generate a new
list of hundreds of IP's and then scan them--all of which unbeknown to the
user of the infected machine....

So please, run with your ports wide open if you'd like, but again, it is
very bad practice..... almost risible....
Post by Aragorn
In that case, you can set up an /iptables/ rule
to drop all packets originating from within that range.
Sure, why not complicate things....
Post by Aragorn
Most people forget that a firewall is intended to block access to a
machine from a given host or range of hosts, and they forget because
that's not what a firewall is used for in Windows, and sadly enough,
people tend to think "the Microsoft way".
Pleaaaase. Read up on NAT a bit.....
Post by Aragorn
Sorry for the rant, but your misunderstanding of how these things work
leads to more misunderstanding
Completely laughable. You mean YOUR misunderstanding, and bad advice which I
hope is not followed by anyone in the newsgroup.

Sheeesh.......

(FYU,I won't be starting a war and responding to any flames, etc.)
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Aragorn
2009-01-24 02:57:49 UTC
Permalink
On Saturday 24 January 2009 02:54, someone identifying as *stef* wrote
in /alt.os.linux.mandriva:/
Post by stef
Post by Aragorn
That cannot be a virus. What you're describing is most likely a brute
force or dictionary password /ssh/ attack. The attacker uses a tool that
attempts multiple root logins per second, each time with a new password,
until it succeeds. GNU/Linux has mechanisms to defend itself against
this kind of attacks - read up on PAM, or browse your MCC "security"
section for available settings - but I've been singing the song of not
allowing root logins over /ssh/ for ages now. <grin>
Either way, once the login was successful, the software was installed and
the root password changed by a human user. There are no GNU/Linux
viruses in the wild, and this kind of operation needs human interaction
on UNIX.
It's a moot point but I disagree. I believe the attack cam in from an
another computer infected with same virus/malware, etc.; the program is a
program written in C, that installs itself once root access has been
gained via the brute force or dict. attack; and root password is changed
automatically. I am 95% sure of it.
Impossible, since anything you install would need to get execute permission
first before it can do anything at all. It is however possible that the
steps needed in all of this are executed by copy/pasting a number of
consecutive commands in a terminal emulator window and executing them. I
know /putty/ on Windows offers this functionality.

But then either way, that which does the execution is running on the
clientside of the connection, i.e. on the computer of the blackhat.
Through this method of execution however, it is possible to have the shell
execute an ftp request to some other machine, from which then a rootkit is
downloaded. Mind you, a rootkit is not software to help you take over a
machine, but software that disguises the fact that the machine has been
taken over.
Post by stef
The "virus" is Linux/Rst-B. It is nothing new...been around for a while.
Without sufficient documentation, I will stick to my above explanation.
Post by stef
The "developers" even sign the virus, I forget the name but one was
Rootfu.k (if you know what I mean.)
Rootkits are not viruses.
Post by stef
Post by Aragorn
... And disallow all direct root logins, both on the console and via ssh.
Don't use the MCC to do it, but edit */etc/sshd/sshd_conf* - or whatever
it's called on your system - and */etc/securetty* yourself. Hint: the
latter should be empty to disallow all root logins at the console.
I don't understand what you mean by disallow root login at console. I
can't actually believe that you would not let the sysadmin
su to root; but perhaps I am misunderstand what you are saying.
Using /su/ to root is allowed, of course, but only to users in the /wheel/
group, and you should limit the amount of users in that group to the bare
minimum. I also recommend not using /sudo./

Furthermore, disallowing root login simply means that root cannot directly
log in, even on the console. In other words, he has to log in as a user in
the /wheel/ group and then use /su./

There is one exception, though, which I also recommend, and that is to have
single user maintenance mode - i.e. runlevel 1 - require the root password
before offering a shell. I also recommend setting up GRUB with an
encrypted password. If you use LILO, you can also use a password, but not
an encrypted one. In that case, you must set the permissions on
*/etc/lilo.conf* to 400.
Post by stef
Post by Aragorn
Post by stef
block ssh
What good would that do? Then why are you running /sshd/ in the first
place?
I never said I wanted to block ssh. That woul be stupid. However, only
allowing it from trusted IP's could be a solution.
The problem is that most client connections in Belgium - yes, I live there
too - have a dynamic IP address, which makes allowing access to trusted
machines very difficult, especially if you're using a laptop with "hotspot"
access somewhere. In that case, you'll have to start using SSL keys, which
you can use perfectly well in combination with login passwords.
Post by stef
Post by Aragorn
A firewall is only needed if you're running a high-profile server with a
known domain name and IP address. A home user should not need any
firewall, unless you are constantly being attacked or portscanned from
the same IP address or range.
That's a ridiculous statement....a firewall IS needed, whether it is a NAT
feature via your DSL or Cable Modem, a router or a software firewall.
I've had internet at home since april 2000, and I've never run a firewall on
my machines. Never had any problems.
Post by stef
That is VITAL and anything to the contrary and extremely bad advice. It
opens you to being port scanned constantly, etc.
Port scans aren't hazardous in themselves. Either way, I've only ever had
portscans from my ISP itself, not from anybody else. Just because someone
is attempting to connect to port 23586 on your computer doesn't mean that
they can, as long as no service is listening on that port.
Post by stef
There are plenty of zombie machines out there that each day generate a new
list of hundreds of IP's and then scan them--all of which unbeknown to the
user of the infected machine....
Those zombies are typically used for spreading spam, not so much for
portscanning, because an ISP notices that a client is doing portscanning
and can - and in most cases immediately will - terminate the client's
internet subscription.
Post by stef
So please, run with your ports wide open if you'd like, but again, it is
very bad practice..... almost risible....
Really? Well, be my guest and try on my machine. I'm not running a
firewall. I am running /sshd/ on the standard port, although this port
might be closed to anyone from beyond the Telenet client subnet. Be my
guest at trying to break in.
Post by stef
Post by Aragorn
In that case, you can set up an /iptables/ rule to drop all packets
originating from within that range.
Sure, why not complicate things....
Complicating things? /iptables/ is the firewalling method in all Linux 2.6
kernels. It is the tool you use for setting up NAT/routing/firewalling.
Aren't you the one who's so paranoid about firewalls?
Post by stef
Post by Aragorn
Most people forget that a firewall is intended to block access to a
machine from a given host or range of hosts, and they forget because
that's not what a firewall is used for in Windows, and sadly enough,
people tend to think "the Microsoft way".
Pleaaaase. Read up on NAT a bit.....
Pleaaaase, what makes you think you're the only one in the world with a NAT?
Post by stef
Post by Aragorn
Sorry for the rant, but your misunderstanding of how these things work
leads to more misunderstanding
Completely laughable. You mean YOUR misunderstanding, and bad advice which
I hope is not followed by anyone in the newsgroup.
Bad advice, given to someone who knows even less than me then, or so it
would seem, given that you don't even know what I'm talking about when I
mention disallowing direct root login on the console.

I'm willing to compare how I have set up my computer here with how you've
set up yours any day, and I'm also willing to bet that mine will turn out
having been set up a lot more securely than yours.
Post by stef
Sheeesh.......
(FYU,I won't be starting a war and responding to any flames, etc.)
Whatever. I'm really beginning to believe Edsger Dijkstra when he said that
people who've had previous exposure to Windows are braindamaged for life.

Sheesh back at ya, and no cheers!
--
*Aragorn*
(registered GNU/Linux user #223157)
stef
2009-01-25 12:11:02 UTC
Permalink
Post by Aragorn
in /alt.os.linux.mandriva:/
Impossible, since anything you install would need to get execute permission
first before it can do anything at all. It is however possible that the
steps needed in all of this are executed by copy/pasting a number of
consecutive commands in a terminal emulator window and executing them. I
know /putty/ on Windows offers this functionality.
Everything is possible once you gain root access; and that can be done
automatically via a brute force, dict attack, etc. Then a script can be
run with root privileges to wget any questionable program, install it with
executable rights, etc. It's called...programming
Post by Aragorn
But then either way, that which does the execution is running on the
clientside of the connection, i.e. on the computer of the blackhat.
Through this method of execution however, it is possible to have the shell
execute an ftp request to some other machine, from which then a rootkit is
downloaded. Mind you, a rootkit is not software to help you take over a
machine, but software that disguises the fact that the machine has been
taken over.
Not a rootkit. You are making even more assumptions....
Post by Aragorn
Post by stef
The "virus" is Linux/Rst-B. It is nothing new...been around for a while.
Without sufficient documentation, I will stick to my above explanation.
Easy to look up.
Post by Aragorn
Rootkits are not viruses.
See above. And they certainly fall in tha category of
viruses/malware/unwanted programs,
Post by Aragorn
There is one exception, though, which I also recommend, and that is to
have single user maintenance mode - i.e. runlevel 1 - require the root
password
before offering a shell. I also recommend setting up GRUB with an
encrypted password. If you use LILO, you can also use a password, but not
an encrypted one. In that case, you must set the permissions on
*/etc/lilo.conf* to 400.
The above sounds like a good idea.
Post by Aragorn
The problem is that most client connections in Belgium - yes, I live there
too - have a dynamic IP address, which makes allowing access to trusted
machines very difficult, especially if you're using a laptop with "hotspot"
access somewhere. In that case, you'll have to start using SSL keys,
which you can use perfectly well in combination with login passwords.
Yes, correct, upon reflection, it would make it difficult to only allow
certain IP's especially if you the "sysadmin" is traveling from location to
location, with a different iP all the time.
Post by Aragorn
I've had internet at home since april 2000, and I've never run a firewall on
my machines. Never had any problems.
I know you were going to say something like the above re/ your firewall.
Good for you you have not had problems, but that is NOT a basis to neglect
a vital security policy" always run with a firewall, at the very least a
NAT feature.

You may not be aware that almost ALL DSL or CAble modems have NAT enabled by
default when shipped to end users....so you very well may have had that
feature to protect you--as opposed to being bare, exposed; which is
_extremely bad practice_.
Post by Aragorn
Post by stef
That is VITAL and anything to the contrary and extremely bad advice. It
opens you to being port scanned constantly, etc.
Port scans aren't hazardous in themselves. Either way, I've only ever had
portscans from my ISP itself, not from anybody else. Just because someone
is attempting to connect to port 23586 on your computer doesn't mean that
they can, as long as no service is listening on that port.
Again, I completely disagree with the above statement--it is based on: the
inverse of Murphy's law: all will be fine. I wholeheartedly disagree and
strongly recommend *always* running witha firewall/NAT, as the case may be.
Post by Aragorn
Post by stef
There are plenty of zombie machines out there that each day generate a
new list of hundreds of IP's and then scan them--all of which unbeknown
to the user of the infected machine....
Those zombies are typically used for spreading spam, not so much for
portscanning, because an ISP notices that a client is doing portscanning
and can - and in most cases immediately will - terminate the client's
internet subscription.
You are making so many assumptions; but you really have no idea.... There
are countless zombie machines out there doing many more than only send
spam, etc.
Post by Aragorn
Post by stef
So please, run with your ports wide open if you'd like, but again, it is
very bad practice..... almost risible....
Really? Well, be my guest and try on my machine. I'm not running a
firewall. I am running /sshd/ on the standard port, although this port
might be closed to anyone from beyond the Telenet client subnet. Be my
guest at trying to break in.
The problem with you is that you assume everyone else is a "geek", welcoming
challenges from hackers, viruses, etc. You perhaps might even welcome and
enjoy it.
For others like me that have a regular job, and would rather spend their
time doing real work, etc., those can run their box completely exposed....
Why not....
Post by Aragorn
Complicating things? /iptables/ is the firewalling method in all Linux 2.6
kernels. It is the tool you use for setting up NAT/routing/firewalling.
Aren't you the one who's so paranoid about firewalls?
If you are on a LAN (as lots of people are), you need a LAN firewall with
NAT. That is the point (public access/public IP) where the security needs
to be set, predominently--not with iptables on a single machine. You may
not be familiar (apparently) with routers, etc.
Post by Aragorn
Bad advice, given to someone who knows even less than me then, or so it
would seem, given that you don't even know what I'm talking about when I
mention disallowing direct root login on the console.
I do know--you are just not doing a very good job in clearly expressing
yourself....
Post by Aragorn
Sheesh back at ya, and no cheers!
Well, again, good luck running with your fixed ideas.
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
stef
2009-01-25 12:19:33 UTC
Permalink
Post by Aragorn
in /alt.os.linux.mandriva:/
Impossible, since anything you install would need to get execute permission
first before it can do anything at all. It is however possible that the
steps needed in all of this are executed by copy/pasting a number of
consecutive commands in a terminal emulator window and executing them. I
know /putty/ on Windows offers this functionality.
Everything is possible once you gain root access; and that can be done
automatically via a brute force, dict attack, etc. Then a script can be
run with root privileges to wget any questionable program, install it with
executable rights, etc. It's called...programming
Post by Aragorn
But then either way, that which does the execution is running on the
clientside of the connection, i.e. on the computer of the blackhat.
Through this method of execution however, it is possible to have the shell
execute an ftp request to some other machine, from which then a rootkit is
downloaded. Mind you, a rootkit is not software to help you take over a
machine, but software that disguises the fact that the machine has been
taken over.
Not a rootkit. You are making even more assumptions....
Post by Aragorn
Post by stef
The "virus" is Linux/Rst-B. It is nothing new...been around for a while.
Without sufficient documentation, I will stick to my above explanation.
Easy to look up.
Post by Aragorn
Rootkits are not viruses.
See above. And they certainly fall in tha category of
viruses/malware/unwanted programs,
Post by Aragorn
There is one exception, though, which I also recommend, and that is to
have single user maintenance mode - i.e. runlevel 1 - require the root
password
before offering a shell. I also recommend setting up GRUB with an
encrypted password. If you use LILO, you can also use a password, but not
an encrypted one. In that case, you must set the permissions on
*/etc/lilo.conf* to 400.
The above sounds like a good idea.
Post by Aragorn
The problem is that most client connections in Belgium - yes, I live there
too - have a dynamic IP address, which makes allowing access to trusted
machines very difficult, especially if you're using a laptop with "hotspot"
access somewhere. In that case, you'll have to start using SSL keys,
which you can use perfectly well in combination with login passwords.
Yes, correct, upon reflection, it would make it difficult to only allow
certain IP's especially if you the "sysadmin" is traveling from location to
location, with a different iP all the time.
Post by Aragorn
I've had internet at home since april 2000, and I've never run a firewall on
my machines. Never had any problems.
I knew you were going to say something like the above re. your firewall.
Good for you you have not had problems, but that is NOT a basis to neglect
a vital security policy: always run with a firewall, at the very least a
NAT feature.

You may not be aware that almost ALL DSL or Cable modems have NAT enabled by
default when shipped to end users....so you very well may have had that
feature to protect you--as opposed to being bare, exposed; which is
*extremely bad practice*
Post by Aragorn
Post by stef
That is VITAL and anything to the contrary and extremely bad advice. It
opens you to being port scanned constantly, etc.
Port scans aren't hazardous in themselves. Either way, I've only ever had
portscans from my ISP itself, not from anybody else. Just because someone
is attempting to connect to port 23586 on your computer doesn't mean that
they can, as long as no service is listening on that port.
Again, I completely disagree with the above statement--it is based on: the
inverse of Murphy's law: all will be fine. I wholeheartedly disagree and
strongly recommend *always* running with a firewall/NAT, as the case may be.
Post by Aragorn
Post by stef
There are plenty of zombie machines out there that each day generate a
new list of hundreds of IP's and then scan them--all of which unbeknown
to the user of the infected machine....
Those zombies are typically used for spreading spam, not so much for
portscanning, because an ISP notices that a client is doing portscanning
and can - and in most cases immediately will - terminate the client's
internet subscription.
You are making so many assumptions; but you really have no idea.... There
are countless zombie machines out there doing much more than only send
spam, etc.
Post by Aragorn
Post by stef
So please, run with your ports wide open if you'd like, but again, it is
very bad practice..... almost risible....
Really? Well, be my guest and try on my machine. I'm not running a
firewall. I am running /sshd/ on the standard port, although this port
might be closed to anyone from beyond the Telenet client subnet. Be my
guest at trying to break in.
The problem with you is that you assume everyone else is a "geek", welcoming
challenges from hackers, viruses, etc. You perhaps might even welcome and
enjoy such challenges, etc. Such can run with their box completely open and
exposed, why not? Lots of fun it can create....

For others like me that have a regular job, and would rather spend their
time doing real work, etc., run behind a firewall well configured.
Post by Aragorn
Complicating things? /iptables/ is the firewalling method in all Linux 2.6
kernels. It is the tool you use for setting up NAT/routing/firewalling.
Aren't you the one who's so paranoid about firewalls?
If you are on a LAN (as lots of people are), you need a LAN firewall with
NAT. That is the point (public access/public IP) where the security needs
to be set, predominently --not with iptables on a single machine. You may
not be familiar (apparently) with routers, etc.
Post by Aragorn
Bad advice, given to someone who knows even less than me then, or so it
would seem, given that you don't even know what I'm talking about when I
mention disallowing direct root login on the console.
I do know--perhaps you are just not expressing yourself clearly enough....
Post by Aragorn
Sheesh back at ya, and no cheers!
Well, again, good luck to you running with your fixed ideas.
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Bit Twister
2009-01-25 14:16:06 UTC
Permalink
Post by stef
Yes, correct, upon reflection, it would make it difficult to only allow
certain IP's especially if you the "sysadmin" is traveling from location to
location, with a different iP all the time.
That is where port knocking can help.
Post by stef
For others like me that have a regular job, and would rather spend their
time doing real work, etc., run behind a firewall well configured.
I think all systems should come with a firewall installed an running upon boot.
That would keep the newbie out of trouble. I would say the majority of
the newbies are windows power users and would soon be starting
services for vnc, ssh, ftp, web server....

More so as systems will not run windows7/vista. Those systems probably
will be used to experiment with linux. With more malware crawling
around on the LAN from infected DOZE boxes, each system has to defend
it's self even if it is behind a NAT/firewalled router.
Mark Madsen
2009-01-25 14:40:49 UTC
Permalink
Post by stef
You are making so many assumptions; but you really have no idea....
</irony>
Moe Trin
2009-01-26 02:03:58 UTC
Permalink
On Sun, 25 Jan 2009, in the Usenet newsgroup alt.os.linux.mandriva, in article
Post by stef
Everything is possible once you gain root access; and that can be done
automatically via a brute force, dict attack, etc.
---------------------
BlockHosts http://www.aczoom.com/cms/blockhosts
v2.4.0 May 17, 2008 (last checked 12/16/08)
iptables, tcp_wrappers, permanent AND 12 hours (adjustable)

DenyHosts http://denyhosts.sourceforge.net
v2.6 Dec 7, 2006 (last checked 12/16/08)
tcp_wrappers, permanent AND possibility of PURGE (suggested = days)

bruteforceblocker http://danger.rulez.sk/projects/bruteforceblocker
v1.2.3 Mar 6 2006
pf (OpenBSD) permanent and mail

fail2ban http://www.fail2ban.org
V0.8.3 Jul 17, 2008 (last checked 12/16/08)
iptables temp (banTime default= 10 min) perm (banTime negative value)

PortSentry
http://heanet.dl.sourceforge.net/sourceforge/sentrytools/
portsentry-1.2.tar.gz
v1.2 May 23 2003 (v2.0b1 mentioned, but probably dead - 2008)
Not really a log reader. detected connection attempts, and could
permanently block via routing, firewall, or tcp_wrappers. Was more
aimed at blocking port-scanners.
---------------------

NOTE: I DO NOT RECOMMEND ANY OF THE TOOLS ABOVE - most people will
manage to mis-configure them and wind up shooting themselves in the
wobbly bits. They'll probably prevent brute force attacks (which is
what they're designed to do), even if the "attacks" are due to fumble
fingering by the administrator or other authorized user. Certainly
wouldn't be the first time that kind of st00pidity occurred. They
also ignore the possibility of IP spoofing, even if they're aware
that it can occur.
Post by stef
Yes, correct, upon reflection, it would make it difficult to only
allow certain IP's especially if you the "sysadmin" is traveling from
location to location, with a different iP all the time.
So you're constantly jumping from country to country, continent to
continent, with never a chance to pack a bag, much less look at which
address range is used where. Must be hell. Try googling for the
words 'port knocking' in your spare time. And before anyone starts
whining about "security through obscurity", kindly remember that port
knocking does not disable the normal authentication mechanism used with
network applications - you still need the appropriate username and
authentication token, but you don't get to try those until you've
gotten the server to even listen to your connection attempt. The
biggest disadvantage is that the firewall at the location you are
attempting to connect FROM may block packets to the non-standard port
numbers normally used in port knocking.
Post by stef
Post by Aragorn
Port scans aren't hazardous in themselves. Either way, I've only
ever had portscans from my ISP itself, not from anybody else. Just
because someone is attempting to connect to port 23586 on your
computer doesn't mean that they can, as long as no service is
listening on that port.
the inverse of Murphy's law: all will be fine. I wholeheartedly
disagree and strongly recommend *always* running with a firewall/NAT,
as the case may be.
So you can connect to any port, even if there is no server listening?
You might want to share that knowledge with Theo de Raadt (OpenBSD and
the OpenSSL project), as one of the security strong points of OpenBSD
is that it runs no servers in the out-of-box configuration - they're
all disabled even if you do install them.

Old guy
stef
2009-01-24 02:33:47 UTC
Permalink
Perhaps, reading this (amongst other things) might help.....

<http://www.happyassassin.net/2009/01/20/on-linux-security/>

The above link is referred by a top Linux security expert/software engineer
at one of the main Linux Distros--perhaps one you've even used....
--
Mandriva Free 2008.1 (x86_64)
KDE 3.5.9 - zsh
Aragorn
2009-01-24 03:09:18 UTC
Permalink
On Saturday 24 January 2009 03:33, someone identifying as *stef* wrote
in /alt.os.linux.mandriva:/
Post by stef
Perhaps, reading this (amongst other things) might help.....
<http://www.happyassassin.net/2009/01/20/on-linux-security/>
The above link is referred by a top Linux security expert/software
engineer at one of the main Linux Distros--perhaps one you've even
used....
Then perhaps he should have gone to bed, as he was planning to do, according
to his first paragraph, instead of blowing things out of proportion. <grin>

Yes, no computer is ever fully secure. Yes, a lot depends on the biological
unit between the keyboard and the chair. But to say that GNU/Linux is only
"marginally" more secure than Windows is absolute idiocy.

And yes, trustworthy packages are signed, and yes, Mandriva users know that
they should only install packages from trusted repositories. If the user
screws up and installs malware on his own system because he's too careless,
then the operating system is not to blame and then stating that the
operating system is less secure is pure insanity, sorry.

As for the difference between a multi-user environment and a home
environment, there is no technical difference. People who lose their data
are people who don't make backups. It's their responsability, not that of
the operating system.
--
*Aragorn*
(registered GNU/Linux user #223157)
Frank Peelo
2009-01-26 14:00:47 UTC
Permalink
Post by stef
Perhaps, reading this (amongst other things) might help.....
<http://www.happyassassin.net/2009/01/20/on-linux-security/>
The above link is referred by a top Linux security expert/software engineer
at one of the main Linux Distros--perhaps one you've even used....
ok, so he's saying that it's as easy for a Linux user to wreck his/her
files as it is for a Windows user; also that a Linux user with the root
password can break a Linux box just as easily as Windows users can break
theirs. That's a truism; network access isn't even required, just
rm -Rf blah /* instead of rm -Rf blah/*

But what has that got to do with converting a port scan into gaining
root access?

You seem to have been saying that not running a firewall means that your
ports will be scanned, and therefore someone will log in as root. But I
would have thought that makes some big assumptions about what the port
scan will find. Getting through would depend on you having enabled an
unsafe service on one of your ports -- not on the lack of a firewall.

Probably I've misunderstood or missed something. Could you tell me what,
please?

Frank
Moe Trin
2009-01-26 20:00:48 UTC
Permalink
On Mon, 26 Jan 2009, in the Usenet newsgroup alt.os.linux.mandriva, in article
Post by Frank Peelo
ok, so he's saying that it's as easy for a Linux user to wreck his/her
files as it is for a Windows user; also that a Linux user with the
root password can break a Linux box just as easily as Windows users
can break theirs.
Q: What's small and yellow and highly dangerous?
A. A canary with the root password.
Post by Frank Peelo
That's a truism; network access isn't even required, just
rm -Rf blah /* instead of rm -Rf blah/*
That's but one of many ways. Any time you are using a '-r' or '-R'
option to ANY command, you're probably setting yourself up for a
disaster. Typ0s are always entertaining if you aren't the recipient,

one Ohnosecond - shortest amount of time known in computing

The speed at which a mistyped command executes is directly
proportional to the amount of damage done.

but those are true for any operating system.

Old guy
Frank Peelo
2009-01-27 18:24:03 UTC
Permalink
Post by Moe Trin
On Mon, 26 Jan 2009, in the Usenet newsgroup alt.os.linux.mandriva, in article
Post by Frank Peelo
ok, so he's saying that it's as easy for a Linux user to wreck his/her
files as it is for a Windows user; also that a Linux user with the
root password can break a Linux box just as easily as Windows users
can break theirs.
Q: What's small and yellow and highly dangerous?
A. A canary with the root password.
Post by Frank Peelo
That's a truism; network access isn't even required, just
rm -Rf blah /* instead of rm -Rf blah/*
That's but one of many ways. Any time you are using a '-r' or '-R'
option to ANY command, you're probably setting yourself up for a
disaster. Typ0s are always entertaining if you aren't the recipient,
It was the first example to come to mind.

But I still would like the low-down on what stuff happens when the
firewall is not right, and on Linux viruses in general. After Stef's
earlier post, naming the Linux/Rst-B virus, I did some googling. Found
that Sophos has a recogniser for it, so I ran that; it didn't find any
instances of the virus, which was a relief. But I also have an sshd
server, allowing login only of a specific user with low privileges on a
nonstandard port with a delay between allowed logins to prevent
brute-force attacks.

And there's a NAT filter on the router, and some iptables rules... but I
still wonder if there is anything at all to what Stef is saying?

Because stuff happens... apparently a chain mail was forwarded to a
large number of people from my son's email account. My son checks his
email account about as often as he tidies his room, and the email was
apparently sent when he would have been in bed anyhow. I would have
thought someone was spoofing the sender address in an Outlook virus, BUT
the think is in his "Sent" folder! Seems only to have happened once, but
I don't know how... (Thunderbird, with Mandriva 2008.0)

(I ran ClamAV afterwards, and it found nothing, but I noticed the virus
definitions were a few weeks old.)

Frank
Aragorn
2009-01-27 21:30:51 UTC
Permalink
On Tuesday 27 January 2009 19:24, someone identifying as *Frank Peelo* wrote
in /alt.os.linux.mandriva:/
Post by Frank Peelo
Post by Moe Trin
On Mon, 26 Jan 2009, in the Usenet newsgroup alt.os.linux.mandriva, in
Post by Frank Peelo
ok, so he's saying that it's as easy for a Linux user to wreck his/her
files as it is for a Windows user; also that a Linux user with the
root password can break a Linux box just as easily as Windows users
can break theirs.
Q: What's small and yellow and highly dangerous?
A. A canary with the root password.
:-)
Post by Frank Peelo
Post by Moe Trin
Post by Frank Peelo
That's a truism; network access isn't even required, just
rm -Rf blah /* instead of rm -Rf blah/*
That's but one of many ways. Any time you are using a '-r' or '-R'
option to ANY command, you're probably setting yourself up for a
disaster. Typ0s are always entertaining if you aren't the recipient,
It was the first example to come to mind.
But I still would like the low-down on what stuff happens when the
firewall is not right, and on Linux viruses in general. After Stef's
earlier post, naming the Linux/Rst-B virus, I did some googling. Found
that Sophos has a recogniser for it, so I ran that; it didn't find any
instances of the virus, which was a relief.
Here are the details of the virus...:

http://us.mcafee.com/virusInfo/default.asp?id=description&virus_k=99978

The virus already dates back to 2002, and is quite obviously a "proof of
concept" virus, i.e. it needs to be explicitly downloaded, given execute
permissions and started by the root user. It does not use privilege
escalations or security leaks.

In other words, it is malicious code, but it's threat factor should be
considered harmless.
Post by Frank Peelo
But I also have an sshd server, allowing login only of a specific user
with low privileges on a nonstandard port with a delay between allowed
logins to prevent brute-force attacks.
And there's a NAT filter on the router, and some iptables rules... but I
still wonder if there is anything at all to what Stef is saying?
In my humble but sufficiently educated opinion - of which I'm sure Stef will
disagree - he's only spreading his own fear, uncertainty and doubt as the
gospel, infecting other people's mindsets with his paranoia.

As I presume that he's got prior experience with Windows, it's somewhat
understandable. Yet the fact that he can't seem to distinguish between the
inherent insecurities of the Windows platform and the robustness of an
operating system in the UNIX family - notably GNU/Linux, which isn't
perfect but which comes very close and which is the operating system of
choice on many of the world's servers, clusters, mainframes and
supercomputers for a reason - suggests that he's still got his own mindset
in the Windows atmosphere.
Post by Frank Peelo
Because stuff happens... apparently a chain mail was forwarded to a
large number of people from my son's email account. My son checks his
email account about as often as he tidies his room, and the email was
apparently sent when he would have been in bed anyhow. I would have
thought someone was spoofing the sender address in an Outlook virus, BUT
the think is in his "Sent" folder! Seems only to have happened once, but
I don't know how... (Thunderbird, with Mandriva 2008.0)
Maybe he just got out of bed when he couldn't sleep, fired up his computer,
got that chain mail and forwarded it on. I get such chain mails all the
time, and I know that they are deliberately sent to me by someone who
believes that "the chain must not be broken". So they're not sent by any
virus.
Post by Frank Peelo
(I ran ClamAV afterwards, and it found nothing, but I noticed the virus
definitions were a few weeks old.)
ClamAV scans for Windows viruses, because that's what it's intended to do,
and because there are no GNU/Linux viruses in the wild. All GNU/Linux
viruses so far have always been "proof of concept" viruses, i.e. malware
written so as to demonstrate that an ELF binary can be infected, and using
a scenario of unlikely sysadmin-driven circumstances so as to get the virus
installed and given execute permission on the target machine in the first
place.

No computer connected to any network can ever be considered 100% secured,
but there is a huge difference here between Windows and GNU/Linux. Yes,
the Linux kernel and the GNU userland may still have a few root exploits
lingering around, but these are constantly hunted down and solved. Even
Microsoft regularly releases security patches.

However, there are many other reasons as to why Windows is less secure than
GNU/Linux, and these reasons have nothing to do with escalation of
privileges through security holes in the programming, but all the more with
the very nature of the platform.

GNU/Linux was designed from the ground up as a UNIX-style operating system,
and thus with multi-user functionality and security in mind. The UNIX
architecture was already long proven to be technically the best, most
secure, most portable and most versatile operating system architecture.

On the other hand, we've got Windows, an operating system that only *became*
an operating system by integrating a GUI - and the GUI is actually what
Windows is - with a VMS-clone kernel. For legal reasons as well as for the
suitability of this VMS-clone kernel - read: NT - for use in Windows NT and
followers, many of the features were stripped out, and the security relies
solely on the use of access control lists (ACLs), which are by nature of
the Windows platform - and thus not by any bug or programming flaw -
intentionally left bypassable.

In addition, the Windows layer itself was never intended as a multi-user
environment but was basically a single-user GUI based upon some elements
from the OS/2 GUI and some elements from the early Apple MacIntosh
operating systems. The Microsoft philosophy is and has always been that
Windows must behave like a single-user operating system because in their
view all computers are "personal computers" and are thus to be used by only
one person at the same time. As such, they've added the ACL security layer
for "more specialized environments", but it still is only an additional
layer and not a core component of the system itself, considering that it
was _designed_ to be bypassable.

When I got into computers, I considered computers to be machines that must
have an operating system on them, but what this operating system would
eventually be was something I considered to be the choice of the computer's
owner and administrator. For most people however, an /x86/ computer meant
"a single-user computer with Windows on it", and so the thought of
installing anything other on it than Windows was considered "an alternative
choice".

I never saw things that way, and so I was never conditioned by the Microsoft
way of thinking. Unfortunately, most other users are, and even when
running another operating system than Windows, their mindset still thinks
along the lines of all the risks and all the quirks of Windows and the
Microsoft paradigm. This is wrong, and until we manage to avoid that most
of the brandname PCs are sold with Windows pre-installed - which I don't
ever see happening, to be honest - the FUD will keep on spreading.

Now, there is no doubt in my mind that Stef believes what he's writing - as
opposed to that he would be a troll or a paid Microsoft shill - but he's
projecting his own fears and doubts onto others, and as such, he's actually
advocating the Microsoft stupidity without realizing it, and contributing
to the spreading of FUD. He's knowledgeable enough to know about the
threats that exist, but not knowledgeable enough to understand why those
threats can work on Windows, while they have a far less chance of
succeeding on GNU/Linux.

A careful man is a wise man, but a panicking man is a stampeding fool.

<stepping off my beercase again>
--
*Aragorn*
(registered GNU/Linux user #223157)
Moe Trin
2009-01-28 01:20:20 UTC
Permalink
On Tue, 27 Jan 2009, in the Usenet newsgroup alt.os.linux.mandriva, in article
Post by Aragorn
GNU/Linux was designed from the ground up as a UNIX-style operating
system, and thus with multi-user functionality and security in mind.
The UNIX architecture was already long proven to be technically the
best, most secure, most portable and most versatile operating system
architecture.
Getting a bit far on the advocacy side. Tone it down.

Both O/S have coding problems. Linux has had reasonable success
because it's not aimed at the most st00pid user. There have been and
are exploits out there, and in _most_ cases, they are exploiting
user problems. If you look at Bugtraq, a lot of the problems that
are reported are the result of user stupidity. The most common
exploit now seems to be effecting PHP, which is cross platform. It
seems that admins think that any piece of code found under some rock
on the Internet is better than actually learning what the system is
doing, and some of the crap code that is out there makes the coding
standards at microsoft look good.
Post by Aragorn
A careful man is a wise man, but a panicking man is a stampeding fool.
I can accept that.
Post by Aragorn
<stepping off my beercase again>
Geez, they ought to outlaw those things.

Old guy
Aragorn
2009-01-28 04:44:19 UTC
Permalink
On Wednesday 28 January 2009 02:20, someone identifying as *Moe Trin* wrote
in /alt.os.linux.mandriva:/
Post by Moe Trin
On Tue, 27 Jan 2009, in the Usenet newsgroup alt.os.linux.mandriva, in
Post by Aragorn
GNU/Linux was designed from the ground up as a UNIX-style operating
system, and thus with multi-user functionality and security in mind.
The UNIX architecture was already long proven to be technically the
best, most secure, most portable and most versatile operating system
architecture.
Getting a bit far on the advocacy side. Tone it down.
I am both open about and known to be a FOSS and GNU/Linux activist, so why
would I tone it down?

I may be sounding a bit fanatic here, but the way I see it, in a world where
everyone still thinks that Windows is the greatest thing since sliced bread
- and if the majority of people in this newsgroup doesn't feel this way,
then why do most have dual-boot systems with Windows and still think in
Microsoft terms and "point & click"-iness? - and where GNU/Linux still
doesn't get the recognition it deserves - I am talking of the /x86/ market
here - I don't think GNU/Linux advocacy is a bad thing. On the contrary,
I'd say it's definitely needed.
Post by Moe Trin
Both O/S have coding problems.
I have never denied that, and I even believe I wrote something like that in
my previous post.
Post by Moe Trin
Linux has had reasonable success because it's not aimed at the most
st00pid user. There have been and are exploits out there, and in _most_
cases, they are exploiting user problems.
I was not denying that there weren't any exploits, Moe. I have explicitly
mentioned that, even.
Post by Moe Trin
If you look at Bugtraq, a lot of the problems that are reported are the
result of user stupidity.
User stupidity is not a bug. If you put someone behind the wheel of a
Ferrari when they don't have a driver's license and they ram the damn thing
into an electricity pole or a wall and lose an arm and a leg in the
process, then this is not a flaw of the Ferrari.

I'm not saying GNU/Linux doesn't have bugs - I repeat for the third time
that I have even literally said so myself - but if the bug is in the
biological unit between the keyboard and the chair, then blaming GNU/Linux
for it would be unfair.
Post by Moe Trin
The most common exploit now seems to be effecting PHP, which is cross
platform. It seems that admins think that any piece of code found under
some rock on the Internet is better than actually learning what the system
is doing, and some of the crap code that is out there makes the coding
standards at microsoft look good.
Many system administrators aren't worth their wages. If they were, then
there would be far less UNIX servers with rootkits on them.
Post by Moe Trin
Post by Aragorn
<stepping off my beercase again>
Geez, they ought to outlaw those things.
Beercases? Then how are you going to bring all them bottles home from the
supermarket? :p
--
*Aragorn*
(registered GNU/Linux user #223157)
Frank Peelo
2009-01-28 18:31:04 UTC
Permalink
Post by Aragorn
in /alt.os.linux.mandriva:/
...
Post by Aragorn
Yet the fact that he can't seem to distinguish between the
inherent insecurities of the Windows platform and the robustness of an
operating system in the UNIX family - notably GNU/Linux, which isn't
perfect but which comes very close and which is the operating system of
choice on many of the world's servers, clusters, mainframes and
supercomputers for a reason
...

But that's not all there is to the story! The OS kernel does not get run
in isolation. There are viruses targeted not at Windows, but at Outlook
Express, for example.

It would not surprise me if, for example, Thunderbird could be attacked
independently of the operating system it was running on.
Post by Aragorn
Post by Frank Peelo
Because stuff happens... apparently a chain mail was forwarded to a
large number of people from my son's email account. My son checks his
email account about as often as he tidies his room, and the email was
apparently sent when he would have been in bed anyhow. I would have
thought someone was spoofing the sender address in an Outlook virus, BUT
the think is in his "Sent" folder! Seems only to have happened once, but
I don't know how... (Thunderbird, with Mandriva 2008.0)
Maybe he just got out of bed when he couldn't sleep, fired up his computer,
Haha. Hahaha. Him, get out of bed without being forced. That's funny :)

And there are two passwords to get through (the BIOS password was added
when he started using a live CD to get around the user password),
neither of which he knows. I'm sure he could try to get past them, but
he knows he would lose pocket money if he did.
Post by Aragorn
got that chain mail and forwarded it on. I get such chain mails all the
time, and I know that they are deliberately sent to me by someone who
believes that "the chain must not be broken". So they're not sent by any
virus.
More likely I would do it myself, trying to click on something else and
fumbling the mouse. And fumbling gets more common in the wee small hours.

And it hasn't happened again, so maybe it was done through human
intervention. But the selection of addressees is bizarre if it was done
by a person. It's a mystery. I wonder if it's possible to receive an
email with a faked address, that goes straight into the "sent" folder?

Frank
Aragorn
2009-01-28 19:20:40 UTC
Permalink
On Wednesday 28 January 2009 19:31, someone identifying as *Frank Peelo*
wrote in /alt.os.linux.mandriva:/
Post by Frank Peelo
Post by Aragorn
Yet the fact that he can't seem to distinguish between the
inherent insecurities of the Windows platform and the robustness of an
operating system in the UNIX family - notably GNU/Linux, which isn't
perfect but which comes very close and which is the operating system of
choice on many of the world's servers, clusters, mainframes and
supercomputers for a reason
...
But that's not all there is to the story! The OS kernel does not get run
in isolation. There are viruses targeted not at Windows, but at Outlook
Express, for example.
Yes, but they operate using the same mechanism you will find all throughout
Windows, i.e. the "Windows scripting" language, also known as Visual Basic
Script and Visual Basic for Applications. Such malware uses that language
to have Outlook Express send an e-mail to everyone in its addressbook, and
similar feats.

This is a mechanism that doesn't exist in GNU/Linux, because first of all
the operating system layer is separate from the GUI layer, and secondly the
individual GUI components also have their very own ways of doing things,
which are not always compatible. There is no unified scripting interpreter
connecting all GUI components the way this is done in Windows.
Post by Frank Peelo
It would not surprise me if, for example, Thunderbird could be attacked
independently of the operating system it was running on.
In theory, it could, but then there still is the fact that Thunderbird
doesn't use any scripting language to connect its components with and have
one component automatically do something in another component, like the
selecting of all e-mail addresses in the Outlook (Express) addressbook and
then sending an e-mail to them via Outlook (Express) itself.

Such malware uses the Windows Scripting language as its own operating
system. They are macroviruses - cfr. the "I love you" virus - but there is
no such thing in Thunderbird - or at least not to my knowledge - and such a
thing doesn't exist in GNU/Linux either.
Post by Frank Peelo
Post by Aragorn
Post by Frank Peelo
Because stuff happens... apparently a chain mail was forwarded to a
large number of people from my son's email account. My son checks his
email account about as often as he tidies his room, and the email was
apparently sent when he would have been in bed anyhow. I would have
thought someone was spoofing the sender address in an Outlook virus, BUT
the think is in his "Sent" folder! Seems only to have happened once, but
I don't know how... (Thunderbird, with Mandriva 2008.0)
Maybe he just got out of bed when he couldn't sleep, fired up his computer,
Haha. Hahaha. Him, get out of bed without being forced. That's funny :)
Well, many people who can't catch sleep get out of bed and jump at their
keyboards, so it was not such a wild guess. :-)
Post by Frank Peelo
And there are two passwords to get through (the BIOS password was added
when he started using a live CD to get around the user password),
neither of which he knows. I'm sure he could try to get past them, but
he knows he would lose pocket money if he did.
Oh, okay, now I have a better understanding of the situation. See, I
thought the computer was his and that he could power it up or off at will.
Post by Frank Peelo
Post by Aragorn
got that chain mail and forwarded it on. I get such chain mails all the
time, and I know that they are deliberately sent to me by someone who
believes that "the chain must not be broken". So they're not sent by any
virus.
More likely I would do it myself, trying to click on something else and
fumbling the mouse. And fumbling gets more common in the wee small hours.
Well... There you have it... Maybe you've been fumbling yourself...? :p
Post by Frank Peelo
And it hasn't happened again, so maybe it was done through human
intervention.
I'd say that this was most likely the case, yes.
Post by Frank Peelo
But the selection of addressees is bizarre if it was done by a person.
It's a mystery. I wonder if it's possible to receive an email with a faked
address, that goes straight into the "sent" folder?
Well, I don't use Thunderbird - I use KMail instead - but I suppose
Thunderbird allows for the setting up of filters as well. And once you've
got a filter set up for a given sender address, you can tell KMail where to
store the e-mails sent to you from that address.

And then of course, you can use the "sent" folder as the recipient for
incoming e-mails from the address you've set up the filter too, although
that would be a bizarre choice. ;-)

I'm sure there must be some logical explanation, but right now your guess is
as good as mine. :-)
--
*Aragorn*
(registered GNU/Linux user #223157)
Moe Trin
2009-01-28 01:17:59 UTC
Permalink
On Tue, 27 Jan 2009, in the Usenet newsgroup alt.os.linux.mandriva, in article
Post by Frank Peelo
Post by Moe Trin
That's but one of many ways. Any time you are using a '-r' or '-R'
option to ANY command, you're probably setting yourself up for a
disaster. Typ0s are always entertaining if you aren't the recipient,
It was the first example to come to mind.
It's fine. It's also fun to see people mis-using the 'chmod' and
'chown' commands - especially when they throw in the -r option. Aim
the gun very carefully at your foot - squeeze the trigger gently...
Post by Frank Peelo
But I still would like the low-down on what stuff happens when the
firewall is not right
Back around 1996 or so, the most common open mail relay was a Linux
box, with sendmail configured to relay from/to everywhere, and every
daemon known to man (at the time) running with a default password.
"Install (and enable) everything" was one of the install choices.
Amazingly, the distributions finally figured out that this was not the
optimum installation procedure, and (for example) the Sendmail FAQ
(http://www.sendmail.org/faq/) still has sections explaining why
sendmail is only bound to the loopback rather than the eth0 interface.

Reach over, and unplug your computer from the network. Next, disable
or otherwise stop the firewall (how - depends on your setup). Find a
command line, and run the command

[compton ~]$ netstat -antu
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
[compton ~]$

Hmmm, not a whole lot open. Actually on this system, port 22 is also
firewalled, such that it accepts connections from the other systems on
the LAN (but not the router), and from a /22 and two /24s (a total of
1533 addresses) out on the Internet. Now if you have more things than
this open (yes, you can ignore those on 127.0.0.1), find out what it is
(netstat -anptu will give the process ID that owns a port) and why it's
here. You may want to repeat the test with the firewall running as
normal, just to make sure there are no surprises.
Post by Frank Peelo
and on Linux viruses in general.
There aren't that many out there. I've been more concerned with the
attacks from last August, where a bit of malware uses stolen keys from
other systems on the net to log in to your system. Once they gain
access, they use any available unpatched vulnerability to gain root,
and then install a 'phalanx2' root kit (which does a pretty good job
of hiding itself). That kit looks for SSH keys on your system, and
mails them to a drop-box, but the next version may add features like
mailing bomb threats to the wife of the late dictator in Spamistan, who
would otherwise be willing to share her ill-gotten wealth with you or
let you know you won the national lottery with her help. Main defense
(in addition to keeping your system up to date) is to restrict where
external connections can come from.

One of the advantages of Linux is the fact that it's not a single or
even a few versions. To the poor sods who have to support Linux, this
does make life more complicated (each of the thousand-odd distributions
knows the ``right'' way to do things - to bad they can't agree what it
might be), but a piece of mal-ware built for Mandriva 2007 may not run
Slackware 12, SUSE 11.0, Fedora 9, Debian 'etch', Ubuntu 8.10, Xandros
4.1, or... (never mind other versions of a given release).
Post by Frank Peelo
After Stef's earlier post, naming the Linux/Rst-B virus, I did some
googling. Found that Sophos has a recogniser for it, so I ran that;
it didn't find any instances of the virus, which was a relief.
I put very little faith in the average anti-mal-ware tools. They are
reacting - generally late - to what the mal-ware looked like when last
seen/reported. Could it be changed/modified since then? Harrumph.
Post by Frank Peelo
But I also have an sshd server, allowing login only of a specific user
with low privileges on a nonstandard port with a delay between allowed
logins to prevent brute-force attacks.
That's good, and the only thing I'd suggest adding is a restriction on
the IP address where the login attempt comes from. As of about two
weeks ago, there were 2,771,249,848 IPv4 addresses in use in 93,300
networks in the world. You really don't need to allow access to each
and every one. You're in Ireland, right? They have 214 networks from
ARIN and RIPE:

[compton ~]$ zgrep IE ARIN.gz | cut -d' ' -f3 | sort -n | uniq -c
2 255.255.255.0
[compton ~]$ zgrep IE RIPE.gz | cut -d' ' -f3 | sort -n | uniq -c | column
1 255.240.0.0 13 255.255.192.0 43 255.255.255.0
1 255.248.0.0 42 255.255.224.0 1 255.255.255.128
2 255.252.0.0 28 255.255.240.0 2 255.255.255.240
3 255.254.0.0 34 255.255.248.0 1 1536
11 255.255.0.0 12 255.255.252.0 1 7680
6 255.255.128.0 11 255.255.254.0
[compton ~]$

That's 4188064 IP addresses in total. You probably won't need access
from every one, but even if you did, that's about 1/8th of one percent
of the addresses available. (Allow from this, that, and the other
address that you KNOW you need, Default reject.)
Post by Frank Peelo
And there's a NAT filter on the router, and some iptables rules... but
I still wonder if there is anything at all to what Stef is saying?
Even if your router is auto-forwarding everything to a "local" address
on your LAN (mine doesn't), is anything _listening_ on that host? If
you've also chosen the forwarding such that to reach your SSH server,
they've got to send packets to port 15369 (or something equally at
random) on your public IP address, the odds are pretty much on your
side. Not many skript kiddiez and/or 'bots are going to waste time and
bandwidth trying to find where you hid stuff when there are millions of
other (easy) targets.
Post by Frank Peelo
Because stuff happens... apparently a chain mail was forwarded to a
large number of people from my son's email account. My son checks his
email account about as often as he tidies his room, and the email was
apparently sent when he would have been in bed anyhow. I would have
thought someone was spoofing the sender address in an Outlook virus,
BUT the think is in his "Sent" folder!
I assume that is 'thing' rather than 'think'.
Post by Frank Peelo
Seems only to have happened once, but I don't know how...
(Thunderbird, with Mandriva 2008.0)
Hardly enough details to tell - but 1) I don't recommend using a web
browser for everything; 2) what "plugins were active (I only enable
Java when I'm desperate and it's needed at the only site that has what
I'm looking for - rest of the time, I'm using a text ONLY browser when
I need web stuff); 3) what ELSE was running?
Post by Frank Peelo
(I ran ClamAV afterwards, and it found nothing, but I noticed the
virus definitions were a few weeks old.)
A well designed rootkit does it's thing from in memory and doesn't need
to be stored on disk where the average anti-mal-ware tools will look.

Perhaps a bit brutal to say (and no insult intended), but all the
anti-mal-ware tools in the world are no substitute for common sense.
It just so happens that the most frequently used vector to date is that
of user stupidity. (Why is it that we laugh at the cartoon animal who
falls for the "stand here and press this button" gag, but so many of us
seem content to "click here and be amazed"?)

Most anti-mal-ware for use on Linux is looking for windoze crap on a
Samba server. The windoze "virus de heure" doesn't run on Linux. There
have been a number of worms/trojans aimed at Linux - and with few
exceptions they're vanishingly rare. The common Linux anti-mal-ware
(chkrootkit, rkhunter, OSSEC) look for about 70 rootkits - some as old
as 2000, and I really don't expect very many people are still using
wuftpd-2.6, glibc-2.0, sendmail 8.8.x, or bind-4.9.3 any more. Hence,
a lot of the Linux anti-mal-ware is looking for non-existent stuff and
I can only assume they do so to inflate their perceived capabilities.
Also, they commonly look for filenames - and I can't imagine that a
malware author would be so dastardly as to change the filename that he
knows the anti-mal-ware is looking for... right?

There are vulnerabilities. Recently, I saw posts in a security news
group from someone running a bunch of Ubuntu 8.04 systems who got 0wn3d
because, while he WAS keeping things up-to-date, he was unaware of a
vulnerable SSH authentication key mechanism (predictable keys) caused
by an error in a Debian application. He had replaced the application,
but not generated new keys - the old ones were vulnerable, and down the
tubes he goes.

With reasonable thought and care, the vulnerabilities are minimal, and
may even be controllable. Does that make Linux bullet-proof? No, you
are still required to think.

Old guy
Frank Peelo
2009-02-05 08:18:37 UTC
Permalink
Post by Moe Trin
On Tue, 27 Jan 2009, in the Usenet newsgroup alt.os.linux.mandriva, in article
<useful stuff about security>

thanks for that, and to Aragorn.
Post by Moe Trin
Post by Frank Peelo
Because stuff happens... apparently a chain mail was forwarded to a
large number of people from my son's email account. My son checks his
email account about as often as he tidies his room, and the email was
apparently sent when he would have been in bed anyhow. I would have
thought someone was spoofing the sender address in an Outlook virus,
BUT the think is in his "Sent" folder!
I assume that is 'thing' rather than 'think'.
yup
Post by Moe Trin
Post by Frank Peelo
Seems only to have happened once, but I don't know how...
(Thunderbird, with Mandriva 2008.0)
Hardly enough details to tell - but 1) I don't recommend using a web
browser for everything; 2) what "plugins were active (I only enable
Java when I'm desperate and it's needed at the only site that has what
I'm looking for - rest of the time, I'm using a text ONLY browser when
I need web stuff); 3) what ELSE was running?
Thunderbird is a mail client. Firefox is the web browser. I don't think
Thunderbird has plugins. I don't know how to find out what was running
at the time; ps aux doesn't show anything that looks out of the ordinary.

Anyway, nothing untoward seems to have happened since, so I hope the
problem (whatever it was) happened on the chair in front of the keyboard
and not inside the box.

Frank
Mark Madsen
2009-02-05 10:41:13 UTC
Permalink
Post by Frank Peelo
Thunderbird is a mail client. Firefox is the web browser. I don't think
Thunderbird has plugins.
Think again ;-)
Frank Peelo
2009-02-05 23:35:20 UTC
Permalink
Post by Mark Madsen
Post by Frank Peelo
Thunderbird is a mail client. Firefox is the web browser. I don't think
Thunderbird has plugins.
Think again ;-)
Oh goody! Where are they hidden?

Ah. Tools|Add-ons. Dictionary shouldn't be a problem, but what's this
"DOM Inspector"? Google told me it's to "inspect and edit the live DOM
of any web document or XUL application" and similar descriptions, which
is Greek to me. So it's disabled.

Ta

Frank

Moe Trin
2009-02-06 00:40:17 UTC
Permalink
On Thu, 05 Feb 2009, in the Usenet newsgroup alt.os.linux.mandriva, in article
Post by Frank Peelo
Post by Moe Trin
Post by Frank Peelo
Seems only to have happened once, but I don't know how...
(Thunderbird, with Mandriva 2008.0)
Hardly enough details to tell - but 1) I don't recommend using a web
browser for everything; 2) what "plugins were active (I only
enable Java when I'm desperate and it's needed at the only site that
has what I'm looking for - rest of the time, I'm using a text ONLY
browser when I need web stuff); 3) what ELSE was running?
Thunderbird is a mail client. Firefox is the web browser. I don't think
Thunderbird has plugins.
What _else_ does it do? You're using it as a news reader, so it's more
than a simple mail client like /bin/mail. One would hope it doesn't
automatically open included links/URLs, such as http://tldp.org/guides.html
which might need to be rendered as <http://tldp.org/guides.html>.
Post by Frank Peelo
Anyway, nothing untoward seems to have happened since, so I hope the
problem (whatever it was) happened on the chair in front of the keyboard
and not inside the box.
Now THOSE happen more often than one would hope. ;-)

Old guy
Maurice Batey
2009-01-24 17:55:32 UTC
Permalink
Post by Aragorn
most
common services - i.e. /ftp,/ /ssh/ - have configuration options to already
specify which hosts/groups/users have access to the system via those
services or not;
I've looked in etc/ssh/sshd_config but can't figure out how to
limit ssh access to certain users.

Was that the right place to look?
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Aragorn
2009-01-25 02:19:24 UTC
Permalink
On Saturday 24 January 2009 18:55, someone identifying as *Maurice Batey*
wrote in /alt.os.linux.mandriva:/
Post by Maurice Batey
Post by Aragorn
most
common services - i.e. /ftp,/ /ssh/ - have configuration options to
already specify which hosts/groups/users have access to the system via
those services or not;
I've looked in etc/ssh/sshd_config but can't figure out how to
limit ssh access to certain users.
Was that the right place to look?
Yes, but it may not be in there by default. According to the /man/ page
for /sshd_conf,/ there are the following provisions to that regard...:

(Note: The "[...]" marker below refers to sections from the /man/ page which
I have omitted from this excerpt for relevance.)

<quote from /man/ page>

AllowGroups
This keyword can be followed by a list of group name patterns,
separated by spaces. If specified, login is allowed only for
users whose primary group or supplementary group list
matches one of the patterns. `*' and `'? can be used as
wildcards in the patterns. Only group names are valid; a numerical
group ID is not recognized. By default, login is allowed for all
groups.

[...]

AllowUsers
This keyword can be followed by a list of user name patterns,
separated by spaces. If specified, login is allowed only for
user names that match one of the patterns. `*' and `'? can be
used as wildcards in the patterns. Only user names are valid;
a numerical user ID is not recognized. By default, login is
allowed for all users. If the pattern takes the form ***@HOST
then USER and HOST are separately checked, restricting logins
to particular users from particular hosts.

[...]

DenyGroups
This keyword can be followed by a list of group name patterns,
separated by spaces. Login is disallowed for users whose
primary group or supplementary group list matches one of the patterns.
`*' and `'? can be used as wildcards in the patterns. Only
group names are valid; a numerical group ID is not recognized.
By default, login is allowed for all groups.

DenyUsers
This keyword can be followed by a list of user name patterns,
separated by spaces. Login is disallowed for user names that
match one of the patterns. `*' and `'? can be used as
wildcards in the patterns. Only user names are valid; a numerical
user ID is not recognized. By default, login is allowed for all
users. If the pattern takes the form ***@HOST then USER and HOST are
separately checked, restricting logins to particular users from
particular hosts.

</quote from /man/ page>
--
*Aragorn*
(registered GNU/Linux user #223157)
Maurice Batey
2009-01-25 12:52:41 UTC
Permalink
According to the /man/ page for /sshd_conf,/
Many thanks for the info!

I hadn't realised there was a separate 'man' option for sshd_config
(not sshd_conf)).
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Maurice Batey
2009-01-26 17:52:22 UTC
Permalink
Post by Aragorn
AllowUsers
then USER and HOST are separately checked, restricting
logins to particular users from particular hosts.
I tried that, but it blocked ssh access. If I remove the "@HOST"
component (i.e. just leaving USER), it works.

(I assume that 'HOST' represents the same string as "wirelesspc" when
doing e.g. "ssh ***@wirelesspc".)

Rather than naming specific users to be 'allowed', is there any way of
limiting ssh access simply to anyone on the LAN only, which is what I
would prefer (to avoid anyone out on the WAN dummying up valid
strings).
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Aragorn
2009-01-26 19:00:56 UTC
Permalink
On Monday 26 January 2009 18:52, someone identifying as *Maurice Batey*
wrote in /alt.os.linux.mandriva:/
Post by Maurice Batey
Post by Aragorn
AllowUsers
then USER and HOST are separately checked, restricting
logins to particular users from particular hosts.
component (i.e. just leaving USER), it works.
(I assume that 'HOST' represents the same string as "wirelesspc" when
Rather than naming specific users to be 'allowed', is there any way of
limiting ssh access simply to anyone on the LAN only, which is what I
would prefer (to avoid anyone out on the WAN dummying up valid
strings).
The /man/ pages states that the wildcard characters "?" and "*" may be used,
so I would suggest a /*@IP_RANGE/ value, where /IP_RANGE/ represents the
mask for your LAN.
--
*Aragorn*
(registered GNU/Linux user #223157)
Maurice Batey
2009-01-26 19:40:09 UTC
Permalink
the mask for your LAN.
But then anyone on the WAN could presumably hit on an SSH call that
would satisfy that spec.
What I am after is explictly 'LAN-only' access, not any access that
will satisfy a wild-card pattern.

Of course, that could be regarded as bolting the door unneccessarily
tightly, and I would be interested to hear views on that!
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Aragorn
2009-01-26 19:57:04 UTC
Permalink
On Monday 26 January 2009 20:40, someone identifying as *Maurice Batey*
wrote in /alt.os.linux.mandriva:/
Post by Maurice Batey
the mask for your LAN.
But then anyone on the WAN could presumably hit on an SSH call that
would satisfy that spec.
What I am after is explictly 'LAN-only' access, not any access that
will satisfy a wild-card pattern.
Of course, that could be regarded as bolting the door unneccessarily
tightly, and I would be interested to hear views on that!
<from the /sshd_config/ /man/ page>

AllowUsers
This keyword can be followed by a list of user name patterns,
separated by spaces. If specified, login is allowed only for
user names that match one of the patterns. `*' and `'? can be
used as wildcards in the patterns. Only user names are valid; a
numerical user ID is not recognized. By default, login is
allowed for all users. If the pattern takes the form ***@HOST
then USER and HOST are separately checked, restricting logins to
particular users from particular hosts.

</from the /sshd_config/ /man/ page>

Aso, if we extrapolate the above to a LAN with three machines, one being
your server at 192.186.0.1 and the other two being UNIX workstations at
192.168.0.10 and 192.168.0.11, you could put the following line in your
*/etc/ssh/sshd_config* file...:

AllowUsers *@192.168.0.10 *@192.168.0.11

This will allow all users from all groups - since neither /AllowGroups/
nor /DenyGroups/ are specified - on the two UNIX client machines in your
LAN to connect to the server at 192.168.0.1.
--
*Aragorn*
(registered GNU/Linux user #223157)
Maurice Batey
2009-01-26 22:45:39 UTC
Permalink
I see two problems with that:

(1) What is to stop some WAN ssh call concocting an address that
would fit that pattern and thus creeping under the wall?

(2) The ***@HOST form doesn't appear to work (at least not the
"***@hostname" format). However, I realise I've not tried e.g.
***@192.168.0.123.
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Aragorn
2009-01-27 00:22:50 UTC
Permalink
On Monday 26 January 2009 23:45, someone identifying as *Maurice Batey*
wrote in /alt.os.linux.mandriva:/
Post by Maurice Batey
(1) What is to stop some WAN ssh call concocting an address that
would fit that pattern and thus creeping under the wall?
I'm not an expert in networking, particularly not when it comes to IP
spoofing, but insofar as I have witnessed myself, spoofed IP addresses are
typically not used for login attempts, but rather for DDoS attacks and
smurf attacks, not just in order to hide the IP address of the attacker -
which is mainly a moot subject now that botnets exist, with over 85% of all
Windows PCs on the planet being part of at least one botnet - but also so
as to create a denial of service that *appears* to come from *within* the
local area network, and thus from *behind* the firewall.

With regard to unauthorized login attempts however, it is my experience that
these are generally conducted from other compromised machines, and that the
administrators of those machines bluntly don't care about it.

For a long time, I've always sent complete logs to the administrators of
those domains with regard to the fact that their machines were rooted and
being used for break-in attempts on other machines, along with instructions
on how to disable remote root logins to their machines, and a request for
information on the perpetrator, which they could get out of their own
system logs, so that we could take legal steps against the actual
perpetrators themselves. Not a single one of those administrators has
replied to us.

Either way, this is all beside the point. If they could spoof the IP
address during a login attempt, then they will still need to provide a
correct login and password, and you should set up your system so as to
introduce a delay in between the login attempts after three consecutive
login failures. This is standard PAM technology, and you will find out how
to do that by reading the documentation. If I recall correctly, then
Mandrake Linux - the predecessor of Mandriva - used to even come set up
like that by default.
Presumably it didn't work because you used hostnames that were not already
known to the server - see the sections on known hosts and check whether you
can ping any of the client machines from the server by their hostnames -
and because you might have forgotten to reload your /sshd/ configuration
file into the running /sshd./

If you're really paranoid, use port knocking, have /sshd/ listening on a
non-standard port, use the /AllowGroups/ option along with /AllowUsers,/
and enable SSL key authentication *in* *addition* *to* a the need to log in
using a fully qualified login account and password. And if that's not
enough, block whatever port you're using for /ssh/ logins from the internet
side using /iptables./

I think all of the above together is about the best you can do with regard
to securely determining who gets to log in and who doesn't.
--
*Aragorn*
(registered GNU/Linux user #223157)
Maurice Batey
2009-01-27 16:37:56 UTC
Permalink
you should set up your system so as to introduce a delay in between
the login attempts after three consecutive login failures.
Sounds good idea.
This is standard PAM technology, and you will find out how to do
that by reading the documentation.
Have read documentation, but - as it is a reference rather than a
tutorial - I was unable to figure out what to do or even where to
start, let alone check it out...
that were not already known to the server.
Well, the "***@192.169.0.xx" form in sshd_config works fine,
whereas "***@desktop" doesn't, even though 'desktop' is defined in
/etc/hosts with that IP address, and e.g.'ssh fred@<hostname> works
fine.
Seems sshd - when using the /etc/ssh/sshd_config file - does not
look up the host name in /etc/hosts. Shouldn't it?
... you might have forgotten to reload your /sshd/ configuration
file into the running /sshd./
How is that done, please?

(I have found it necessary to re-boot after changing sshd_config.)
... block whatever port you're using for /ssh/ logins from the
internet side using /iptables./
Sounds good idea! How is that done, please?
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Frank Peelo
2009-01-27 18:37:10 UTC
Permalink
...
Post by Maurice Batey
... you might have forgotten to reload your /sshd/ configuration
file into the running /sshd./
How is that done, please?
As root,
service ssh restart

Or
/etc/init.d/ssh restart

but on Mandriva, the "service" command should do it.

You may be interested in
http://www.linux.com/feature/61061

Some of it went over my head, but some was useful :)

Frank
Maurice Batey
2009-01-27 18:52:43 UTC
Permalink
Post by Frank Peelo
As root,
service ssh restart
Or
/etc/init.d/ssh restart
Many thanks, Frank (and for the 'ssh raid' assurance).
Much appreciated...

Now, if only I could understand why sshd_config's AllowUsers use of
"***@wirelesspc" didn't work when "***@192.xxx.x.xxx" did (where
/etc/hosts gives the mapping between 'fred' and '192.xxx.x.xxx').
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Bit Twister
2009-01-27 19:34:32 UTC
Permalink
Post by Maurice Batey
fine.
Seems sshd - when using the /etc/ssh/sshd_config file - does not
look up the host name in /etc/hosts. Shouldn't it?
Sounds like a DNS order/resolution problem. Could be a simple host order
change to a config file, search path in /etc/resolv.conf, or you need
to install a resolver like bind.

First suggestions are config files:

$ cat /etc/host.conf
order hosts,bind
multi on
nospoof on
spoofalert on

$ grep hosts: /etc/nsswitch.conf
hosts: files dns

$ hostname --domain

$ grep search /etc/resolv.conf
search home.test

$ head -4 /etc/hosts
127.0.0.1 localhost.localdomain localhost
192.168.1.1 gateway.home.test cm
192.168.1.11 fw.home.test fw
192.168.1.131 wm81.home.test wm81

If you decide to install bind, I think you might could use some
scripts to automate new install and/or maintain zone files.

For my LAN I installed bind, built a set_home_zone script to read
/etc/hosts and build named zone files. My install_changes script calls
set_home_zone, configures named.conf, and touches up ifcfg-eth? with
node's ip address and sets up resov.conf.

Snippet from my install_changes script follow:

#********************************************************
#* check for bind/named installed and set it up if so
#********************************************************

if [ -e /usr/sbin/named ] ; then
_fn=/var/lib/named/etc/named.conf
if [ ! -e ${_fn}_orig ] ; then
echo "fixing $_fn"
cp $_fn ${_fn}_orig
/bin/cp /dev/null $_fn
while read -r line ; do
set -- $line
if [ "$1" = "query-source" ] ; then
line="query-source address * port *;"
fi

if [ "$2" = "forwarders" ] ; then
line="forwarders { 208.67.222.222; 208.67.220.220; };"
fi
echo "$line" >> $_fn
done < ${_fn}_orig

echo "
zone \"$(hostname --domain)\" IN {
type master;
file \"master/home.zone\";
allow-update { none; };
};

zone \"1.168.192.in-addr.arpa\" IN {
type master;
file \"reverse/home.reversed\";
allow-update { none; };
};
" >> $_fn

/local/bin/set_home_zone

for _in_fn in /etc/sysconfig/network-scripts/ifcfg-eth? ; do
/bin/cp /dev/null > /tmp/ifcfg
chmod 755 /tmp/ifcfg
while read -r line ; do
set -- $line
_sub=${line:0:4}
if [ "$_sub" = "DNS1" ] ; then
line=DNS1=$(hostname --ip-address)
fi
if [ "$_line" = "PEERDNS=yes" ] ; then
_line=PEERDNS=no
fi
if [ "$_line" = "PEERYP=yes" ] ; then
_line=PEERYP=no
fi
echo "$line" >> /tmp/ifcfg
done < $_in_fn
/bin/cp /tmp/ifcfg $_in_fn
done

if [ ! -e /etc/resolv.conf_orig ] ; then
cp /etc/resolv.conf /etc/resolv.conf_orig
fi
/bin/cp /etc/resolvconf/resolv.conf.d/head /etc/resolv.conf
echo "nameserver $(hostname --ip-address)" >> /etc/resolv.conf
echo "search $(hostname --domain)" >> /etc/resov.conf

chkconfig named on
fi # end if [ ! -e ${_fn}_orig ]
fi # end if [ -e /usr/sbin/named ]





Copy of my set_home_zones script follows:
#!/bin/bash
#*******************************************************************
#*
#* set_home_zone - create named/bind home.(zone/reverse) files
#* from /etc/hosts
#*
#* Note: _out_fn names have to match zone names in /etc/named.conf
#*
#* set_home_zone expects your /etc/hosts to look something like
#*
#* $ head -4 /etc/hosts
#* 127.0.0.1 localhost.localdomain localhost
#* 192.168.1.11 fw.home.invalid fw
#* 192.168.1.130 wb.home.invalid wb
#* 192.168.1.131 beta.home.invalid beta
#*
#* and names do not contain an underscore
#*
#* See http://www.rfc-editor.org/rfc/rfc2606.txt
#*
#* Assume you called this script from install_changes
#* and have the xmessage package installed.
#*
#* Can be called anytime /etc/hosts file change.
#*
#*******************************************************************


_debug=0 # 0=production 1=check/testing

_exe=$0
_log_fn=$(echo /tmp/$(basename $_exe).log)
_time_out="-timeout 16"

#*************************************
#* get this node's domain, tld2,
#* name and ip
#*************************************

_dom=$(hostname --domain)
_ns=$(hostname --fqdn)
_alias=$(hostname --alias)
set -- $(IFS='.'; echo $_dom)
_tld2=$2
set -- $(echo "$(grep $_ns /etc/hosts)")
_ns_ip=$1

_zone_loc=/var/lib/named/var/named/master
_zone_fn=home.zone
_rev_loc=/var/lib/named/var/named/reverse
_rev_fn=home.reversed

if [ $_debug -gt 0 ] ; then # we create files in our account
_zone_loc=$PWD # for testing
_rev_loc=$PWD
_time_out="-timeout 6"
fi

#*************************************
#* build forward zone
#*************************************

_out_fn=$_zone_loc/$_zone_fn

echo "\$TTL 1D
@ IN SOA ${_ns}. admin.${_ns}. (
$(date +%Y%m%d)01 ; Serial num yyymmddnn
1D ; Refresh
6H ; Retry
1W ; Expire
1H ; Minimum TTL
)
; DNS Servers
IN NS ${_ns}.
;
; Machine Names
mail IN CNAME ${_ns}.
news IN CNAME ${_ns}.
localhost A 127.0.0.1" > $_out_fn
while read line
do
eval set -- $line
_ip=$1
_node=$2
if [ "${_ip:0:3}" = "192" ] ; then
if [ "${#_node}" -lt 15 ] ; then
printf "%s.\t\tIN\tA\t%s\n" $_node $1 >> $_out_fn
else
printf "%s.\tIN\tA\t%s\n" $_node $1 >> $_out_fn
fi
fi
done < /etc/hosts
chmod 644 $_out_fn

#*************************************
#* build reverse zone
#*************************************

_out_fn=$_rev_loc/$_rev_fn

echo "\$TTL 1D
@ IN SOA ${_ns}. ${_ns}.(
$(date +%Y%m%d)01 ; Serial num yyymmddnn
8H ; Refresh
4H ; Retry
1W ; Expire
1D ; Minimum TTL
)
;
NS ${_ns}.
; Machine Ip addresses " > $_out_fn
while read line
do
eval set -- $line
_fq=$2
set -- $(IFS='.'; echo $1)
if [ "$2" = "168" ] ; then
printf "%s\tIN\tPTR\t%s.\n" $4 $_fq >> $_out_fn
fi
done < /etc/hosts
chmod 644 $_out_fn

#*************************************
#* test results
#*************************************


if [ $_debug -eq 0 ] ; then
_cmd="named-checkconf -t /var/lib/named /etc/named.conf"
echo "# $_cmd "
$_cmd > $_log_fn
if [ $? -ne 0 ] ; then
echo "$_cmd failure" >> $_log_fn
xmessage $_time_out-display :0 -file $_log_fn &
fi
cat $_log_fn

printf "\n# service named restart\n"
service named restart
printf "\n# nslookup $(hostname --fqdn )\n"
nslookup $(hostname --fqdn)
printf "\n# nslookup $(hostname --alias)\n"
nslookup $(hostname --alias)
printf "\n# nslookup $_ns_ip\n"
nslookup $_ns_ip
fi
_cmd="named-checkzone -t $_zone_loc ${_dom} $_zone_fn"
echo "# $_cmd "
$_cmd > $_log_fn
if [ $? -ne 0 ] ; then
echo "$_cmd failure" >> $_log_fn
echo "$_zone_loc/$_zone_fn" >> $_log_fn
xmessage $_time_out -display :0 -file $_log_fn &
fi
cat $_log_fn

printf "\n# cat -n %s/%s\n" $_zone_loc $_zone_fn
cat -n $_zone_loc/$_zone_fn


_cmd="named-checkzone -t $_rev_loc 1.168.192.in-addr.arpa $_rev_fn"
echo "$ $_cmd"

$_cmd > $_log_fn 2>&1
if [ $? -ne 0 ] ; then
echo "$_cmd failure" >> $_log_fn
echo "$_zone_loc/$_rev_fn" >> $_log_fn
xmessage $_time_out -display :0 -file $_log_fn &
fi
cat $_log_fn

printf "\n$ cat -n %s/%s\n" $_rev_loc $_rev_fn
cat -n $_rev_loc/$_rev_fn

_cmd="grep ${_dom} /etc/named.conf"
_cnt=$($_cmd | grep -c { )
if [ $_cnt -ne 1 ] ; then
echo "ERROR: " > $_log_fn
echo "/etc/named.conf does not contain a" >> $_log_fn
echo "zone \"${_dom}\" IN {" >> $_log_fn
echo "stanza" >> $_log_fn
echo " " >> $_log_fn
xmessage $_time_out -display :0 -file $_log_fn &
cat $_log_fn
fi
/bin/rm -f $_log_fn

#**************** end set_home_zone *****************
Maurice Batey
2009-01-27 19:50:25 UTC
Permalink
Post by Bit Twister
Could be a simple host order
change to a config file, search path in /etc/resolv.conf,
Latter looks different from yours (which has "search home.test"):

[***@desktop ~]# cat /etc/resolv.conf
-----------------------------------------------------------------
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE
OVERWRITTEN
nameserver 192.168.0.1
-----------------------------------------------------------------

and in /etc/hosts I just have (at top):
127.0.0.1 localhost
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Bit Twister
2009-01-27 20:08:38 UTC
Permalink
Post by Maurice Batey
Post by Bit Twister
Could be a simple host order
change to a config file, search path in /etc/resolv.conf,
-----------------------------------------------------------------
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE
OVERWRITTEN
nameserver 192.168.0.1
Yep, I was guessing that was the first problem.
No/wrong search string
Post by Maurice Batey
-----------------------------------------------------------------
127.0.0.1 localhost
That makes me guess, your are running DHCP or Automatic IP selection
for your nic.

My router hands out DHCP leases. I chose to hard code my node's ip
address. That way other nodes on my LAN knows my address and I can
communicate on the LAN if the router becomes AFU .

What is the output from
hostname --domain
Maurice Batey
2009-01-27 21:56:11 UTC
Permalink
That makes me guess, your are running DHCP or Automatic IP selection for
your nic.
Correct!
My router hands out DHCP leases. I chose to hard code my node's ip
address. That way other nodes on my LAN knows my address and I can
communicate on the LAN if the router becomes AFU .
I've organised my router to provide fixed IP addresses for each
station on the LAN. (These are reflected in /etc/hosts.)
What is the output from
hostname --domain
[***@desktop ~]# hostname --domain
mab.unregistered
--
/\/\aurice

(Replace "nomail.afraid" by "bcs" to reply by email)
Bit Twister
2009-01-27 22:28:25 UTC
Permalink
Post by Maurice Batey
I've organised my router to provide fixed IP addresses for each
station on the LAN. (These are reflected in /etc/hosts.)
Not in the one you posted. :(
Post by Maurice Batey
mab.unregistered
So, back to your problem. Does putting
search mab.unregistered (followed by a carriage return) in /etc/resolv.conf
set your domain back in the sshd config file, service sshd restart,
solve your problem?
Maurice Batey
2009-01-27 22:46:27 UTC
Permalink
Does putting search mab.unregistered (followed
by a carriage return) in /etc/resolv.conf....
Just closing down for the night; will try that tomorrow. Thanks, BT!

(But there is a warning in that file: " DO NOT EDIT THIS FILE BY
HAND -- YOUR CHANGES WILL BE OVERWRITTEN".
So how does one make the 'search...' entry permanent?)
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Aragorn
2009-01-27 22:58:04 UTC
Permalink
On Tuesday 27 January 2009 23:46, someone identifying as *Maurice Batey*
wrote in /alt.os.linux.mandriva:/
Post by Maurice Batey
Does putting search mab.unregistered (followed
by a carriage return) in /etc/resolv.conf....
Just closing down for the night; will try that tomorrow. Thanks, BT!
(But there is a warning in that file: " DO NOT EDIT THIS FILE BY
HAND -- YOUR CHANGES WILL BE OVERWRITTEN".
So how does one make the 'search...' entry permanent?)
Disallow your DHCP client from updating the file - see the /man/ page for
the DHCP client you're using - or disable DHCP altogether. Your nodes are
all on a LAN where they are given static IP addresses, so there's nothing
preventing you from configuring the GNU/Linux clients with a static IP
address set in the operating system itself.

Another approach, albeit one that's not the proper way to do it, is to make
*/etc/resolv.conf* immutable by using /chattr/ - again, see the /man/ page
for that command. A file marked as immutable cannot be written to, not
even by the root user or a process with root privileges. It's the file
equivalent of a read-only root filesystem.
--
*Aragorn*
(registered GNU/Linux user #223157)
Bit Twister
2009-01-27 23:16:37 UTC
Permalink
Post by Maurice Batey
Does putting search mab.unregistered (followed
by a carriage return) in /etc/resolv.conf....
Just closing down for the night; will try that tomorrow. Thanks, BT!
(But there is a warning in that file: " DO NOT EDIT THIS FILE BY
HAND -- YOUR CHANGES WILL BE OVERWRITTEN".
So how does one make the 'search...' entry permanent?)
You might try adding

DOMAIN=mab.unregistered to your nic config file. Example:

Yours
$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.1.131
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
ONBOOT=yes
METRIC=10
MII_NOT_SUPPORTED=no
USERCTL=no
DNS1=192.168.1.131 <===== these values show up into resolv.conf
DNS2=208.67.222.222 <===== as nameserver x.x.x.x
DOMAIN=home.test <===== Becomes search value
PEERDNS=no <== If set to 'no', do not modify /etc/resolv.conf
RESOLV_MODS=no
IPV6INIT=no
IPV6TO4INIT=no

I do not recommend changing permissions for preventing changes unless
it is a last resort.

For extra points, there is
locate /sysconfig.txt

and read it.
Bit Twister
2009-01-27 23:36:37 UTC
Permalink
Yours would be somewhat different.
During nic configuration, you can click advanced and there may be a
search box to fill in. That is added to the nic's configuration file.

I would recommend you setting an opendns.org name server as your
backup dns server just in case 192.168.0.1 dies..
DNS1=192.168.0.1
DNS2=208.67.222.222
Maurice Batey
2009-01-28 19:12:33 UTC
Permalink
Post by Bit Twister
During nic configuration,
Could you remind me of where that is done, please, BT?
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Bit Twister
2009-01-28 19:47:47 UTC
Permalink
Post by Maurice Batey
Post by Bit Twister
During nic configuration,
Could you remind me of where that is done, please, BT?
Yeah, right. Like I would remember that when I only set it during an
install. :)

You can find it just as easily as I.
su - root
cp /etc/hosts /etc/hosts_works
cp /etc/sysconfig/network /etc/sysconfig/network_works

Click Network & Internet in MCC.
Click Remove a connection. (all connections)
Click Set up a new network interface (LAN, ISDN, ADSL, ...)

Start answering questions and click any Advanced or other button
selections on each screen. Take notes in your Admin diary.

As a suggestion, I would set your desktop connection Manual instead of
Automatic/dhcp for the one time your router might be AFU.

For dns I would set both as 208.67.222.222 208.67.220.220
(opendns.org free servers)

That way if your router gets cracked you would not be using
cracker's dns servers.


Now restore what MCC dinks up during network setup.

cp /etc/hosts_works /etc/hosts
cp /etc/sysconfig/network_works /etc/sysconfig/network
Maurice Batey
2009-01-28 22:49:07 UTC
Permalink
Yeah, right....
Many thanks, BT! Much appreciated...
--
/\/\aurice

(Replace "nomail.afraid" by "bcs" to reply by email)
Maurice Batey
2009-01-29 17:11:44 UTC
Permalink
Post by Bit Twister
You might try adding
DOMAIN=mab.unregistered to your nic config file
That did work, by the way (i.e. now get "search mab.unregistered" in
/etc/resolv.conf).

Pity the password dialogue then screwed up, as reported earlier...
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Maurice Batey
2009-01-29 17:48:47 UTC
Permalink
Post by Maurice Batey
Pity the password dialogue then screwed up, as reported earlier...
Belay that! I didn't think I had time today to re-try that, but I now
have - and this time it has worked!

So perhaps the DOMAIN= adjustment to the NIC config file has somehow
cleared up the password glitch.

Will update the other 2 stations when I get back from weekend trip.
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Maurice Batey
2009-02-01 20:18:25 UTC
Permalink
Post by Maurice Batey
So perhaps the DOMAIN= adjustment to the NIC config file has somehow
cleared up the password glitch.
Will update the other 2 stations when I get back from weekend trip.
Just returned - but the password problem has *not* gone away.

From the laptop, if I try:

ssh ***@mainpc (which /etc/hosts maps onto 192.168.0.xxx)

then what happens - depending on the AllowUser in mainpc's sshd_config - is:

AllowUser ***@192.168.0.yyy (success):

***@laptop ~]$ ssh ***@mainpc
Last login: Sun Feb 1 17:10:46 2009
[***@desktop ~]$

AllowUser ***@laptop (correct password entered, though should not be needed):

[***@laptop ~]$ ssh ***@mainpc
***@mainpc's password:
Permission denied, please try again.
***@mainpc's password:.....

I find all that most puzzling...
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Maurice Batey
2009-02-01 20:43:18 UTC
Permalink
Post by Maurice Batey
Last login: Sun Feb 1 17:10:46 2009
Damn! That should have read:

***@laptop ~]$ ssh ***@mainpc
Last login: Sun Feb 1 17:10:46 2009
[***@mainpc ~]$
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Maurice Batey
2009-02-05 21:22:09 UTC
Permalink
Post by Maurice Batey
I find all that most puzzling...
No clues forthcoming so will raise a bug report...
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Maurice Batey
2009-01-28 16:26:30 UTC
Permalink
Does putting search mab.unregistered (followed
by a carriage return) in /etc/resolv.conf set your domain back in the sshd
config file, service sshd restart, solve your problem?
No, I'm afraid not. But it did change the failure!

Instead of 'connection refused', it got as far as inviting me to
enter the target user's password, but then said "Permission refused".
(Tried several times; checked no 'case' problem.)

So, for the time being I think I'll just stay with using the form
"***@192.168.0.xxx" in the AllowUser entry in the sshd_config file.

But I do feel the design asymmetry between outgoing ssh and
receiving sshd w.r.t. this host name resolution should be addressed,
so am considering raising a bug report...
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Frank Peelo
2009-01-28 18:43:23 UTC
Permalink
Post by Maurice Batey
Does putting search mab.unregistered (followed
by a carriage return) in /etc/resolv.conf set your domain back in the sshd
config file, service sshd restart, solve your problem?
No, I'm afraid not. But it did change the failure!
Instead of 'connection refused', it got as far as inviting me to
enter the target user's password, but then said "Permission refused".
(Tried several times; checked no 'case' problem.)
Linux Format #113 (Christmas 2008) had a "Tip of the month" which I
think I'll have to try.

The command
ssh-keygen -t rsa
should make a public key and a private key in two files, id_rsa.pub and
id_rsa. Copying the public key to any machine that should connect to you, by
cat id_rsa.pub>>~/.ssh/authorized_keys
should let you log on without typing a password; setting the value for
PasswordAuthentication in /etc/ssh/sshd_config to "no" would get rid of
the possibility of brute-force attacks to get around the password.

But would this make accessing my machine easier if the calling machine
was compromised? Or maybe the "black hat" has the public key, but no
idea who to ssh into?

I only saw this last night. Haven't tried it. Apologies to anyone who
has posted this here already, I don't have time to read everything.

Frank
Maurice Batey
2009-01-28 19:10:28 UTC
Permalink
Post by Frank Peelo
should let you log on without typing a password;
I've already got that set up between laptop and desktop, Frank.

My suspicion with the password problem with the 'search' fix in
/etc/resolv.conf is that the attempt to get past the 'connection
refused' failure has then screwed up on the password path.
So I'm abandoning the attempt to use "***@hostname" entries in
AllowUser in sshd_config.
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Frank Peelo
2009-01-27 18:34:31 UTC
Permalink
Post by Maurice Batey
(1) What is to stop some WAN ssh call concocting an address that
would fit that pattern and thus creeping under the wall?
I'm no guru, but I think the address resolution will protect you here.

To send an ethernet packet, your machine will need to know the MAC
address. It will send out an ARP request, saying "Who has <IP address>?
Tell <your PC's MAC address>".

If a PC on the LAN has that IP address, it sends a reply to your PC's
MAC address, saying "Yoohoo, I'm here" and including its MAC address.
You can then send the packet to that MAC address.

For WAN IP addresses, the gateway that has a route to that WAN IP
address would reply, sending its MAC address. Your PC sends its packet,
which gets to the gateway. The gateway looks at the IP address in the
packet, sees that it's for the WAN and forwards it on.

But now, what happens if a packet arrived in somehow, and got to your
PC, from the WAN but with an IP address matching your LAN? Your PC will
want to reply, and will ask who has the MAC address.

Maybe it's another PC on the LAN, and the conversation dies because that
PC didn't ask to talk to you in the first place.

Maybe it's the gateway, so your PC sends its packet there. But if the
gateway does get the packet, it will look at the IP address, and see
that it's a LAN address; it will not forward your reply to the WAN.

So you should be safe.

I don't see how the above is wrong. If I made a mistake, maybe someone
will point it out and I'll learn something :)


Frank
Moe Trin
2009-01-29 01:51:24 UTC
Permalink
On Tue, 27 Jan 2009, in the Usenet newsgroup alt.os.linux.mandriva, in article
Post by Frank Peelo
To send an ethernet packet, your machine will need to know the MAC
address. It will send out an ARP request, saying "Who has <IP address>?
Tell <your PC's MAC address>".
If a PC on the LAN has that IP address, it sends a reply to your PC's
MAC address, saying "Yoohoo, I'm here" and including its MAC address.
You can then send the packet to that MAC address.
Correct - it's also possible to have /sbin/arp "hard code" MAC
addresses so ARP isn't needed, but that's not very common.
Post by Frank Peelo
For WAN IP addresses, the gateway that has a route to that WAN IP
address would reply, sending its MAC address.
No. The sending computer will only ARP for IP addresses it knows to
be "local" - that's the purpose of the network mask. Look at the
system routing table:

[example ~]$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 89948 eth0
192.168.2.0 192.168.1.6 255.255.255.0 UG 0 0 32165 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 388 lo
0.0.0.0 192.168.1.248 0.0.0.0 UG 0 0 2673 eth0
[example ~]$

Here, this system would ARP for any host on '192.168.1.x'. If you want
to send a packet to 192.168.2.15, the routing table says that's not a
local system, and you would have to send the packet to 192.168.1.6 and
let it forward the packet. This host isn't looking for the MAC address
of 192.168.2.15, because that address isn't on "this" wire, and isn't
involved in the transmission. This host knows (from the routing table)
that it wants to talk to 192.168.1.6, and would ARP for that if the
value were not in the cache. Same concept for packets going to
192.168.34.51.... how do you get there? It's not the first three
routes, so send it to the default at 192.168.1.248 and let it do it's
thing.
Post by Frank Peelo
But now, what happens if a packet arrived in somehow, and got to your
PC, from the WAN but with an IP address matching your LAN? Your PC will
want to reply, and will ask who has the MAC address.
No - exactly the same as above. Send the packet to the gateway that
should be able to forward it. Repeating - if the IP address isn't a
local, the packet goes to the appropriate gateway. In the routing
table above, how would the gateway at 192.168.1.248 know the MAC
address of 192.168.71.144? No direct route is being show, so it's not
likely to be directly attached to 192.168.1.248.
Post by Frank Peelo
I don't see how the above is wrong. If I made a mistake, maybe someone
will point it out and I'll learn something :)
The only time a computer would say "Yoohoo, I'm here" is when you are
asking about an address on "this" wire (LAN, WAN, MAN don't define the
relationship well enough). The single exception to this is when a
host _isn't_ on this wire, but has an address considered local (same
subnet if you will). Picture the situation of a local network on
192.168.14.x, but one of the computers is actually connected via a
serial link (ppp0 interface) using one of the hosts on this network
as the go-between.

192.168.14.15 192.168.14.233 192.168.14.201
---------- computer A -------ppp_link------------ computer X
LOCALNET

Now computer 192.168.14.31 wants to send a packet to 192.168.14.201
and looks at the address and determines "it's on this wire". So it
ARPs for "192.168.14.201 - where are you?" except that 192.168.14.201
never hears that request. But if computer A is set to "Proxy-ARP"
(man pppd and look for that option) and IPv4_FORWARDING, it will
reply using the eth0 interface and say "Yoohoo, I'm here". If
192.168.14.31 is ultra-paranoid, it might notice the MAC address
really belongs to 192.168.14.15 (unlikely), but now it has a MAC
address to send the packet. Computer A will notice the IP address is
for computer X, and will silently forward the packet, and 192.168.14.31
will be none the wiser.

MAC addresses are a _local_ phenomena. You only see those that are on
"your" wire. Where I work, the network switches, routers and servers
know what MAC addresses belong to what IP address (we don't use DHCP
as the computers don't go wandering). If they notice a strange MAC
address, or a MAC/IP mismatch, they send mail to Security and to the
Network Operations desk, and it's a race to see who gets to the
intruder first - an ugly sys-admin, or one of the People Who Do Not
Smile (and who may be armed - we're serious). Hit your favorite
search engine, and look for a tool named 'arpwatch'.

Old guy
Frank Peelo
2009-02-05 08:28:56 UTC
Permalink
Post by Moe Trin
On Tue, 27 Jan 2009, in the Usenet newsgroup alt.os.linux.mandriva, in article
...
Post by Moe Trin
Post by Frank Peelo
For WAN IP addresses, the gateway that has a route to that WAN IP
address would reply, sending its MAC address.
No. The sending computer will only ARP for IP addresses it knows to
be "local" - that's the purpose of the network mask.
ok, thanks. I saw the packets being sent to the gateway, and my machine
using ARP to get the gateway's MAC, and jumped to a conclusion. Should
have noticed the IP address in the ARP.
Post by Moe Trin
Post by Frank Peelo
But now, what happens if a packet arrived in somehow, and got to your
PC, from the WAN but with an IP address matching your LAN? Your PC will
want to reply, and will ask who has the MAC address.
No - exactly the same as above. Send the packet to the gateway that
should be able to forward it.
"with an IP address matching your LAN"...

The OP was asking, what happens if someone somehow gets packets to the
ssh server, that look like they are coming from an IP address on the
subnet. (I don't know if that is possible, just considering what would
result if it /did/ happen.) So the local PC (the ssh server) will think
it's talking to someone on its subnet. So I would have thought it would
not send the packet to the gateway.

Frank
Moe Trin
2009-02-06 00:41:58 UTC
Permalink
On Thu, 05 Feb 2009, in the Usenet newsgroup alt.os.linux.mandriva, in article
Post by Frank Peelo
Post by Moe Trin
Post by Frank Peelo
But now, what happens if a packet arrived in somehow, and got to
your PC, from the WAN but with an IP address matching your LAN?
Your PC will want to reply, and will ask who has the MAC address.
No - exactly the same as above. Send the packet to the gateway that
should be able to forward it.
"with an IP address matching your LAN"...
Whoops! Missed that. OK, three RFCs - the first replaced by the
second, the third adding to the second:

2267 Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing. P. Ferguson, D. Senie.
January 1998. (Format: TXT=21032 bytes) (Obsoleted by RFC2827)
(Status: INFORMATIONAL)

2827 Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing. P. Ferguson, D. Senie.
May 2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Updated
by RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE)

3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola.
March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also
BCP0084) (Status: BEST CURRENT PRACTICE)

Simple terms - your perimeter should be silently dropping packets from
the "outside" that claim to have "inside" source addresses. More
paranoid terms - all of your routers should be dropping packets (but
possibly logging the details) when packets arrive on one interface that
have a "source" IP address that should be on a different interface. By
this, I mean a packet arriving on eth0 (192.168.1.0/24) with a source
address that belongs on eth1 (192.168.3.0/24) or similar.

RFC1812 (Requirements for IP Version 4 Routers) speaks to the problem
of NOT passing certain packets. For example, a perimeter router should
drop unroutable packets (those using RFC3330 addresses - but there is
also RFC5156 for IPv6 address ranges).
Post by Frank Peelo
The OP was asking, what happens if someone somehow gets packets to the
ssh server, that look like they are coming from an IP address on the
subnet. (I don't know if that is possible, just considering what would
result if it /did/ happen.)
This is why the perimeter filtering is a good idea. Is IP address
spoofing _possible_ at all. The answer is a definite yes. However one
must consider the protocol _within_ the IP datagram. UDP is spoofed
very often - by spammers sending windoze Messenger spam (packets that
are directed to UDP ports 1025-1030, and containing what appears to be
a windoze pop-up error message) such as:

STOP! WINDOWS REQUIRES IMMEDIATE ATTENTION.

Windows has found 55 Critical System Errors.

To fix the errors please do the following:

1. Download Registry Update from: www.spammers.web.site
2. Install Registry Update
3. Run Registry Update
4. Reboot your computer

FAILURE TO ACT NOW MAY LEAD TO SYSTEM FAILURE!

This one was seen last year. Notice that the URL leads to some site
not associated with microsoft. I've seen these packets supposedly
coming from IP ranges that haven't been issued by IANA to the Regional
Internet Registries, never mind assigned/allocated to some entity.
ICMP is another trivially spoofed protocol, because like UDP, it's a
one way message, with no need to reply to convey the data.

TCP is a whole 'nother problem entirely, and the ability to spoof is
operating system dependent. If you look at figure 3 of RFC0793 (page
15 top) which shows the TCP header, you'll note that it has two 32 bit
"sequence numbers" (one for each direction in a connection). Most
sanely designed network stacks generate an initial sequence number
based on a random number generator - thus, you have no way to predict
what that number might be. Assume you try to spoof a TCP connection,
you start by sending a packet to the victim saying "I want to talk"
(SYN), and including a sequence number. The victim responds by sending
a response acknowledging the request and sending back the last sequence
number it received in "this" conversation, and including it's own
random sequence number (SYN+ACK) - but it sends that to the spoofed
source. Now if you are going to continue the conversation, you have to
send back a third packet (ACK) that includes the sender's 32 bit
sequence number... which because it wasn't sent to you, you don't
have... See the problem? If you have the 'nmap' application
installed, see the very extensive documentation that comes with it - as
it includes some tools that depend on being able to spoof the sequence
number, and Fyodor includes a lot of material discussing sequence
number generation/prediction.
Post by Frank Peelo
So the local PC (the ssh server) will think it's talking to someone on
its subnet. So I would have thought it would not send the packet to
the gateway.
Depends on where the spoofing computer and victim are located. From a
practical point, the spoofer almost has to be local, so that it can
(depending on network topology) hear those sequence numbers. It's
actually a real ball of wax with lots of interesting problems inside.

Old guy
Loading...