Home Home > Security
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for the ‘Security’ Category

And done…. new images available

June 12th, 2014 by

Hi,

It took a bit but I am happy to report that all openSUSE 13.1 images in Amazon EC2, Google Compute Engine and Microsoft Azure public cloud environments have been refreshed. After the latest round of the GNU-TLS and OpenSSL fixes the security was, as usual, extremely efficient in providing fixed packages and these have been available in all cloud images via zypper up since last Friday. As of today the base images available in the public cloud frameworks contain the fixes by default.

In Amazon the new images are as follows:

  • ap-northeast-1: ami-79296078
  • ap-southeast-1: ami-84a7fbd6
  • ap-southeast-2: ami-41cbae7b
  • eu-west-1: ami-b56aa4c2
  • sa-east-1: ami-bffb54a2
  • us-east-1: ami-5e708d36
  • us-west-1: ami-16f2f553
  • us-west-2: ami-b7097487

In Google compute engine the image name is: opensuse-13-1-v20140609

The old image (opensuse131-v20140417) has been deprecated. To access the image you will need to add –image=opensuse-cloud/global/images/opensuse-13-1-v20140609 as the openSUSE images are not yet fully integrated into the GCE framework. Still working on that part with Google. This image also has upgrades to the google-cloud-sdk package and enable the bq (big-query) command. The gcloud command is still a bit rough around the edges, but the gcutil command should work as expected. Eventually gcutil is going to be deprecated by Google thus there is work to be done to fix the integration issues with the gcloud command. If anyone has time to work on that please send submit request to the google-cloud-sdk package in the Cloud:Tools project in OBS. Unfortunately Google still hasn’t posted the source anywhere for open collaboration 🙁 . They’ll get there eventually. I will try and push any changes upstream.

In Azure just search for openSUSE in the Gallery, it’s more of a point an click thing 😉

And that’s a wrap. Not certain we will be able to improve on the speed of such fire drill updates, but we’ll try to keep refreshing images as quickly as time allows when critical vulnerabilities in the core libraries get exposed.

Have a lot of fun….

mounting TrueCrypt volumes in GNU/Linux using cryptsetup

January 12th, 2014 by

cryptsetup as of 1.6, which shipped in openSUSE 13.1, is able to mount TrueCrypt volumes without the use of TrueCrypt code otherwise, which I previously noted is problematic due to it’s license, at least for inclusion in the openSUSE distribution.

Here, then, is how you mount it:

cryptsetup open --type tcrypt /var/run/media/username/volume_name encrypted_volume
mount /dev/mapper/encrypted_volume /mnt

For read only access, add --readonly and -o ro respectively. When done:

umount /mnt
cyrptsetup close encrypted_volume

See man 8 cryptsetup for all details and options.

Factory Progress 2011-07-01

July 1st, 2011 by

Here’s with some delay the next incarnation of Factory Progress. I’ve noticed the following changes that might interest people using and developing openSUSE Factory:

Package changes

Linux 3.0

Linux kernel 3.0 rc5 is currently on its way to factory and the header files (in package linux-glibc-devel) have already been updated for it. If your software reads the Linux kernel version, please check that it can cope with the two digits instead of the three of the new version. Best would be to not read the version at all.

Systemd

Frederic has proposed a “Road to systemd for openSUSE 12.1″. Systemd is a replacement of the SysVinit scripts that we have been using and improving in the past with many new – including some controversial – ideas. Check his blog post for additional references about systemd. The majority of the distributions are moving to systemd as well and standarizing on it, will allow to share some more code and development in this area.

We’re now in phase 1 – which means: Get systemd running as an option. Once this is working satisfactory, we can switch the default (phase 2) and decide what to do with SysVinit support.

(more…)

Securing SSH (Secure Shell) from attacker

March 22nd, 2011 by

Secure Shell or SSH is a network protocol that allows exchange of data through secure channels between two network devices.

Particularly widely used on Linux and Unix-based system to access your shell, SSHwas designed as a substitute for Telnet and other insecure remote shells, which sentinformation, especially passwords, in the form of simple text that makes it easy to be intercepted. Encryption used by SSH provides confidentiality and integrity of dataover an insecure network like the Internet.

For the Security Server We From Attacks The attacker who usually Always Use SSHAs a door Early Entry Into System To us, of course, become an admin obligation todispel various Efforts That.

There are several ways which ordinary people do to secure SSH from a variety ofattacks which one of them is by editing the file / etc / ssh / sshd_config.

before doing the configuration in the file / etc / ssh / sshd_config make sure SSH isinstalled on your linux distribution, and for openSUSE that I use it already automatically installed.

#vim /etc/ssh/sshd_config

change options, as below :

LoginGraceTime 2m
PermitRootLogin no
MaxAuthTries 3

LoginGraceTime which option is used to give a time limit of user logins, so please change these options according to your wishes.

PermitRootLogin is no option to allow the root user can login to ssh or not to give yes or no value on the options tersebut.sebaiknya give no value, so that users can not loginas root into your ssh.

MaxAuthTries 3 to give the limit on the number of errors allowed when the user logs in,this is very useful to avoid attackers do brute force on the server anda.dimana usersonly allowed to make a mistake typing the password in accordance with that alreadyset on the options.

If you want only certain users who may log into your ssh add AllowUsers option at the end of the line followed by a distinguished user name in the allowed login.

otherwise, you can install software, denyhost, for your ssh security

NB:do not enable the root user, for ssh login

Similarly, a fairly simple tutorial .. hopefully this can be useful.

Best Regards
Saydul Akram
Email : idulk@opensuse.org

updated permissions handling in 11.4

November 24th, 2010 by

In addition to supporting file system capabilities (fate#307254) I’ve also updated the permissions handling in 11.4 slightly.

There have been complaints that every SuSEconfig run also calls SuSEconfig.permissions which leads to changed file permissions at unexpected times. Therefore I’ve modified SuSEconfig.permissions to only actually set permissions when called explicitly (ie SuSEconfig –module permissions). When called by a generic SuSEconfig run SuSEconfig.permissions now only shows files with wrong permissions but doesn’t actually fix them anymore.

Since packages that have files with special permission handling do call SuSEconfig.permissions explicitly via %run_permissions in %post the change above alone isn’t sufficient to avoid surprises. Therefore I’ve introduced the new macro %set_permissions. This macro expects file names as arguments. Only permissions of those files are adjusted then. To notify packagers of that new method an rpmlint check now issues an informal message if %run_permissions is used.

On-Access virus scanning on openSUSE 11.3

September 14th, 2010 by

One of the most useful deployment scenario for Linux in enterprise or educational environment is a fileserver with on access virus scanning, to serve Windows PCs on the network of course. Long ago there used to be samba-vscan that worked very nicely, it went missing in openSUSE 11.2 so dazuko kernel module worked in its place. On 11.3 dazuko is no longer available, enter dazukofs.

(more…)

Encrypt your files quick n’ dirty

April 23rd, 2010 by

Encrypt a file can be useful when we want to keep sensitive information but do not trust the site is being stored.

GnuPG allows to quickly and easily create encrypted files without the use of public keys or complicated procedures, just run the following at a Linux terminal:

$ gpg -c test.txt _
Enter Password:
Repeat Password:
$ _

After you have run the command gpg -c, this will leave intact the original file and create another file called “test.gpg” in the same directory. This second file is the place where you want to prune without fear that information may be disclosed. You can then proceed to remove the original if needed.

To retrieve the contents of the file, perform the following process on the encrypted file:

$ gpg  test.gpg _
Enter Password:
Repeat Password:
$ _

GnuPG will automatically detect that it is an encrypted file, and request the key that first used.

Hope its useful 😉

Check your WPA2 Enterprise setup

April 20th, 2010 by

Do you have to enter user name and password to establish a link with
your wireless network? If so chances are good that WPA2 Enterprise
with EAP-TTLS or PEAP are used. Sounds familiar? Better check your
setup then. An attacker might easily impersonate your access point
and steal your password if the client you are using isn’t configured
properly.
You are likely vulnerable if you’ve disabled certificate checks
or you’ve checked some button to use a public CA but didn’t specify
any “Subject” or “Common Name” that has to match. NetworkManager for
example doesn’t even allow to enter the latter.
Read more in the paper I’ve written.

Tip: transparent editing of gpg encrypted files with vim

January 29th, 2010 by

If you are vim user and also use gpg to encrypt stuff, you might appreciate that you can teach vim to transparently open gpg encrypted files with vim gnupg plugin. Just install vim-plugin-gnupg from Contrib repository:

# zypper install vim-plugin-gnupg

Also, you should add following two lines to your .bashrc to make the plugin work properly:
GPG_TTY=`tty`
export GPG_TTY

Then, if you tell vim to open gpg encrypted file, it will ask for passphrase, transparently decrypts it and after you make changes, it will encrypt the file again.

Tip: Using KWallet or GNOME Keyring with Subversion

January 15th, 2010 by

Subversion stores all its configuration and passwords under the ~/.subversion/ directory. Wouldn’t it be cool to have your passwords in KWallet or GNOME Keyring? Recently I found out, it is pretty simple.

(more…)