Linux Security Tips

Phantasm66 · Jul 25, 2002

Here's a great article on Linux Security Tips

Linux Security Tips

While writing this text I'm thinking that you already know how to install linux and you also know the basic commands, in other words I assume that you already know how to mess with linux. If you think this is a step by step document your are wrong, here are given ideas and thoughts that will help you to secure your box. When you end this text you'll have a secure box/network, but, remember that nothing is 100% secure, be paranoid. You won't be treated as a newbie to all this, because I'm assuming you aren't.

The only 3 things you need to keep going through:

- Brain (I guess there's no problem with this one)
- Linux Knowledge
- Coffee or something with caffein

So let's start this shall we?

"To protect yourself you need to see your system from the attackers eyes"

<-- Your mission Mr. Sysadmin is Securing your box -->
------------------------------------------------------

The first step on securing a box is re-installing your system. Your are
probably asking why? Well if we really want to secure a system, we need to have
100% sure that it wasn't compromised before you started implementing security
measures, otherwise it can just be a complete waste of time. Lets suppose that
you have just finished installing again your favorite linux distro, and you are
ready to secure it.

Selecting services
------------------

Log in as root.
First thing is to check what daemons are running as default, we can use
netstat for that.

# netstat -a

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:ftp *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 *:telnet *:* LISTEN
tcp 0 0 *:smtp *:* LISTEN
tcp 0 0 *:finger *:* LISTEN
tcp 0 0 *:www-http *:* LISTEN
tcp 0 0 *op3 *:* LISTEN
tcp 0 0 *:shell *:* LISTEN
raw 0 0 *:icmp *:* 7
raw 0 0 *:tcp *:* 7

#

Well for what I'm checking I can tell that this is a newbie linux version,
probably RedHat or Mandrake. Why do I say that? Because those distros come with
plenty of active daemons, this way if the user need it don't need to try to
configure it. Unfortunately the default configurations aren't what we can call
secure so let's get working.

Finger and shell daemons should be shuted ASAP. Why?

- Finger daemon gives away info to everyone that requests it, even if it's not
much, it gives valid usernames for brute force attempts.

- Shell daemon, is one of the so called the r* services, the characteristic in
all of this services is that no authentification is needed. It's all based in
trusted host. If you still wanna run those be sure you set kerberos
identification.

- r* services running without kerberos or any other kind of auth method:
There's a file (.rhosts) where the trusted IPs are and if the IP trying to
login matches with the ones of the file, you get access to the box. So an IP
Spoffing attack would do the job, and you would get your box in trouble.

Now we still have the following services running:

- ftp (File Transfer Protocol)
- ssh (Secure Shell)
- telnet (actually this one should also be shuted after all we have ssh)
- smtp (Simple Mail Transfer Protocol)
- www-http (Web server)
- pop3 (Post Office Protocol 3)

Now you have to ask yourself a question. What do I pretend to do with my box?

- If you want to do a shell provider, you probably want to leave ftp daemon so
users can upload things to their shells, ssh open, and unfortunately telnet
too because there are many people (mostly windows users wanting to get a *nix
shell) that don't know what ssh is and don't have clients for it.

- If you want a mail server, you probably would close every port besides smtp,
and pop3.

NOTE: If the smtp daemon that you are using is sendmail, check if it's the
latest version, actually you should do this with every daemon, but specially
with sendmail. Why? Well because sendmail daemon is a massive coding with over
80.000 lines of code. So as you can imagine it's heaven for exploit writers. In
the past there actually was the joke "So what's this week sendmail
vulnerability?". If you really need a smtp daemon also think in changing from
sendmail to qmail (www.qmail.org).

- If you want a web server you should leave www-httpd daemon and ftp daemon. Or
even better if you have physical access to the web server and you can access
it regurally shut the ftp daemon too, and when there's need to upload things
just log locally.

- If you want a standalone box, just for you why not to close every single port
you have. But let's say that you want to play around in your box trying to
exploit the services, but you don't want nobody to access them besides you, so
it's still a standalone box but for everyone else besides you. The solution is
to set a firewall with deny policy, we'll have a little discussion about that
later.

WHAT YOU ALREADY SHOULD NOW: To open/close ports you need to edit the file
/etc/inetd.conf. If the service you wanna close
isn't listed there check init scripts that can
be found in the /etc/rc.d directory or /etc/init.d
deppend on what initialization system your distro
uses.

IMPORTANT: Remember it's really important that you will ALWAYS running the
latest daemons versions. Subscribe BugTraq mailing list
(http://www.securityfocus.com) to know about the latest exploits and
patches. If deamons allow, drop user permissions to normal users
that just own that deamon. Create new users for each deamon you are
running.

Avoiding to get in trouble
--------------------------

Well in the last section I gave 4 examples of what you could want to make with
your box:

- shell provider
- Mail server
- Web server
- Standalone box

Well in this section the standalone option won't be discussed by obvious
reasons.

Let's first see what measures we could take about in the shell provider.

Shell provider
--------------

In this kind of server you'll have plenty of people around the server,
probably even giving passwords to friends for their shells, it can be a really
dark environment for the sysadmin.

Services Running:

- FTP
- SSH
- TELNET

Tips:

- Do not allow root to login remotely

- Remove, or at least change passwords from default accounts.

- Do not allow anonymous ftp users to login, nor root, nor any user has to
much power to login by ftp, bin, daemon, and other pseudo users from
root.

- Check all files with SUID bit, and check their man page, if they say
that they can run without SUID bit just take it out. Files like at,
mount, umount should always be without the SUID bit..If they have it in
your system just take it out

- Chroot() user in is own home directory when login by ftp.

- Use shadow passwords

- Delete su from your system and get sudo instead, if you really want to
be secure or your the only sysadmin remove both

- Don't allow normal users to use commands like, mount, umount, uname,
netstat, w, who, and others that can give some kind of info from your
machine not actually needed

- Use npasswd instead of passwd, or use vpass with passwd

- Install Crack (remember to set permission to rwx------) and once a week
run a check in passwords of your system. Remember that it can take hours
or even days if your system as many users, but you also have to remember
that it can make your box secure. Set cron to run it and report by mail.

- If you want secure passwords, and crypt() accepts long passwords use
ppgen (password generator) that will generate passwords for users,
instead of being them to give passwords

- Warn users about possible social engineer attacks.

- Make users change their pass often

- Always display something like "This host logs everything you do,
break in attempts will be punished by law" at the login prompt and motd.
It's always good to do this, it won't secure your box but might put some
script kiddie think twice.

URLs:

sudo (ftp://ftp.courtesan.com/pub/sudo/)
npasswd (ftp://ftp.cc.utexas.edu/pub/npasswd/)
ppgen (ftp://coast.cd.purdue.edu/pub/tolls/unix/ppgen/)
crack (http://www.users.dircon.co.uk/~crypto/)

Mail server
-----------

Actually we can think that this kind of servers won't be in such danger as a
Shell provider, but that's not true, a Mail server is sometimes in MORE danger
that a shell provider. Why? Well because sendmail daemon is really buggy, POP3
can be brute forced to get passwords from users, and even if this host doesn't
allow any kind of remote login, the passwords of the users should be the same in
other hosts of the same network right? So you starting to imagine a chaos
environment, that's good, your opening your eyes to the reality.

Services Running:

- SMTP
- POP3

Tips:

- Give a try with qmail daemon instead of sendmail one.

- Check if the commands vrfy and expn, they probably are, but if they aren't
disable them.

- In POP3, if possible, set lock account so that if in an amount of time
there's a large number of failed login attempts. Remember to get an
auto-unlock mechanism too, something like, after 30 minutes unlock account.
If there's no such option you can alway login into the account that is being
attack, and nobody can login again until you logout (I'm are talking about
pop3 login).

Phantasm66 · Jul 25, 2002

Web server
----------

Web servers are the ones that are most attack by script kiddies, everything
they wanna do is their "31337 defacings" saying things like "I 0wN yOuR ***
*****", using exploits gotten from bugtraq which they have no ****ing clue on
what they do. For the Web Server this kiddiots are one of the biggest
danger, but remember they will just sucefull if you are lazy and don't upgrade
and patch holes otherwise they don't have a clue on what to do.
Still there's always the dark cenario of a DoS attack comming for a kiddie that
is almost crying because after trying the 1000 exploit he had that hadn't
nothing to do with services running he didn't manage to crack security.
Solution --> FIREWALL

Services running:

- www-http
- ftp (most of the times)

IMPORTANT: If you have a web server with ftp daemon and you let people people
upload to a world writable directory, REMEMBER chroot() ftp and chroot() http IN
DIFFERENT DIRECTORIES, that can't be accessible each other. Otherwise scripts

can be uploaded to root your server.

Tips:

- If you use CGI scripts check if you don't have vulnerable CGI scripts, if you
have them delete them.

- If using a world writable ftp directory like /incoming check it reguraly,
like each 3 days, or each week, don't get it more than 1 week, after that
period of time delete everything in that directory, if some package should be
preserved change them to a dir where only you can write and other can just
read. If you don't do this your server will become the newest warez spot, in
the place, in no time.

- Never run http daemon as root, you probably saying that ports lower than 1023
(standard ones) they have to ran as root, well friend they have to be STARTED
as root, but they can drop permissions like apache does. Use a unique user for
httpd, set /bin/false and shell of that user and put his name on the
/etc/ftpusers file.

List of vulnerable CGI script
----------------------------

NOTE: This isn't by any means a complete list.

- phf - htmlscript - view-source
- Count.cgi - pfdisplay - campas
- test-cgi - perl.exe - nph-test-cgi
- php.cgi - wwwboard.pl
- handlers - www-sql
- webgais - service.pwd
- websendmail - users.pwd
- webdist.cgi - aglimpse
- faxsurvey - man.sh

Maintaining FileSystem Integrity
--------------------------------

Maintaining FileSystem Integrity? What's that?

Well basically it's the act of maintaining files unchanged against our
wish. But hey, I'm not talking about corrupted files, but about trojanned
files. Ever heard of something called root kits? Well those kits have most used
*nix commands, but trojanned, some of them are ps, ls, netstat....
There's an excellent tool to do this checking it's called Tripwire and u
can find it at http://www.tripwiresecurity.com. What it does is when installed
gets a mathematical fingerprint of each file and store it in a database, each
time you run Tripwire a check between the database fingerprint and the present
fingerprint, if they match it's everything ok, if it don't the file has been
changed. This was one of the reasons that I said that we should start
re-installing the system, in this way we are sure that tripwire is generating
fingerprint of the real files, instead of some bogus ones that we could already
have without we knowing.

Below is a diagram showing how tripwire works
Code:
------------------- -------------------- 
-------------- | new database | | Database generated | 
| tw.config | --------> | genarated using | | at tripwire | 
-------------- | tw.config file | | installation | 
------------------- -------------------- 
| | 
| | 
| | 
---------> <--------- 
| 
| 
--------------- 
| COMPARATION | 
--------------- 
| 
| 
--------------- 
| Apply Any | 
| Masks Needed | 
--------------- 
| 
| ------------------------ 
------> | OUTPUT: Result Report | 
------------------------ 
When we fire up tripwire just two files are used tw.config, where files that
should be checked are listed and the database generated at installation that has
the original fingerprints.

A tw.config file entry looks like:

/bin/mount +p+i+u+g+s+a

This entry tells tripwire to check the permission bits, the inode number, the
number of links, the user and group ID of owner, size of the file and access
timestamp. This are the flags that are applied in the Apply Masks phase. For
more info about flags check the information that comes with Tripwire.
After changes or file adding that you want to keep Tripwiring you can add and
update the database with the new fingerprints.

Firewalls
----------

Knowing about firewalls is always a good thing, specially if you want to
protect your LAN, from the pure chaos that internet can be. In this section we
will talk a little about firewalls and some ways of setting them.

Firewalls have two mainly functions:

- Don't let the "guys" from outside get in.
- Don't let the "guys" from inside get out.

Yes, actually are both, not just the first as many users thinks. Well actually
most of the people that are reading this probably already know it.
One of the most known firewalls is our beloved ipchains firewall.As is said
in the man page of ipchains:

"Ipchains is used to set up, maintain, and inspect the IP
firewall rules in the Linux kernel. These rules can be
divided into 4 different categories: the IP input chain,
the IP output chain, the IP forwarding chain, and user
defined chains."

Now as you read ipchains inspect the IP firewall rules in the Linux kernel,
which means that you can handle every package in the most low level you can
make, which is really good. You actually don't receive it process it and then
send to firewall to analyze like it happens with some so called "firewalls" from
windows.

And as you can also see it talks about the 3 functions I told you, calling
them

IP input chain, this is where rules are set for all the incoming data
IP output chain, this is where rules are set for all the outgoing data
IP forwarding, this is where rules are set for routing and proxying data

Let's now see some examples.

Example 1 (standalone):
Code:
--------------- /\/\/\/\/\/\/\ 
| Standalone |_________________| THE | 
| system | | INTERNET | 
---------------- \/\/\/\/\/\/\/ 
If you are in a standalone system you don't need to have forwarding enable, it
even would get you an high security risk. Why?
Well let's see in this way you most have the ipchains rules for accept the
loop back (lo), this means connection FROM your host TO your host. Now if you
have ip forwarding enabled this means that someone can send data to forwarded in
the firewall to your own host. In this case they are using the firewall as a
router, this will be seen has a loop back and accepted. What you couldn't be
accepted directly was accepted with a little routing trick.

Phantasm66 · Jul 25, 2002

Example 2 (the oldie packet-filtering firewall):

/\/\/\/\/\/\/\/\ -----------------
| THE |__________________| Router |
| INTERNET | | (firewall) |
\/\/\/\/\/\/\/\/ -----------------
|
|
|
00000000000000000
0 PROTECTED 0
0 LAN 0
00000000000000000

This example is the most basic packet filtering used by many companies who
want to filter their LAN. As you can see in the diagram there's a router that
connects the protected LAN to the internet, this can work under ip-masquerading
if you have a dial-up system with dynamic ip having a private network all behind
of the router. In this type of cases the traffic from the internet to the
protected is all or at least some blocked, on the hand the LAN can access the
entire internet, unless the sysadmin blocks sites like www.hotporn.com so
employees don't waste time watching porn **** instead of working.
Now, if the firewall allow at least outsider to enter the protected LAN, like
SMTP daemon, companies often set up one, the entire network can be in danger,
since attackers have a way in. Actually this kinds of attacks are discussed in
the Firewall HOWTO, check it for more detailed explanation.
In this kind of topologies there is, actually, a direct contact between the
protected LAN and the internet, the router just does that it routes, it's a
gateway but has the particularity that it sometimes blocks packages, still when
it isn't blocking it's just another gateway like the many ones where the
internet is based on.

EXAMPLE 3 (DMZ system)

/\/\/\/\/\/\/\/\ ---------------
| THE |____________| Router |
| INTERNET | | |
\/\/\/\/\/\/\/\/ ---------------
|
| -----------
*********** | Router |
* DMZ *---------| |
*********** ------------
|
|
|
00000000000000000
0 PROTECTED 0
0 LAN 0
00000000000000000

WOW, kinda complex isn't it?
Well at lets my ASCII skills are getting better and better just because of
all this schemes

But let's get back into this shall we. Well some of you are asking yourself
what does DMZ means. Well DMZ stands for Demilitarized Zone, hum...nice name,
but what in fact is a Demilitarized Zone aka DMZ, not in the word meaning
because that we understand but in the network?
The DMZ is a small network subnet, that as we can see in the diagram is
between the two routers. Now the two routers have a filtering policy that the
only thing that is accessible by the LAN and by the internet is the DMZ, this
means no direct contact, the only network known to both is the DMZ. And what's
in that subnet? All the hosts that have the services you want to be accessed by
the internet, like DNS servers, DHCP server, etc. This kind of network if good
configured is very secure, since it will become really difficult to an outsider
redirect traffic to the protected that is in fact an HIDDEN LAN.

Logging
-------

You have to remember logs are one of your best friends when you are trying to
find problems and intruders in your network.
First thing you have to realize is that you don't just go check the logs when
you start having a problem , you NEED to check the logs in a regular interval,
like week to week, but what's the best is that as soon as you get a message
problem you should get an alert message.

Syslog
-------

The syslog is a logging that comes with every linux distro. His
configuration file it located at /etc/syslog.conf it's syntax his very simple:

selector (composed by facility.priority) action

The selector is what type of messages will trick that rule
The action will tell where to log them

Example:

kern.warn /var/log/warn

To create the file you need to touch it. Like:

# cd /var/log
# touch warn
# chmod 750 warn

To see all the facility and priority key names check syslog.conf man page.

If a standalone box generates about 30kb of logs each day, a internet
server may generate some megabytes each day. And isn't really easy to look for
problems in a 100mb log. The solution for it is a tool called swatch.

Swatch
------

As I already said, and you probably already know, Log checking if often
ignore by sysadmins since tons of lines are generated by day, sysadmins prefer
to check their logs just when they have already been compromised. This behaviour
is totally wrong. Swatch has two fundamental uses, it can be an active
monitor, checking for messages as they are being logged via syslog or it can
also be for auditing, checking logs from the past. Swatch has been design for
syslog but it can also monitor any log file like sulog, web access log, fail
log... The developers of Swatch (Simple WATCHer), had in mind to
write a program that would help the sysadmin to check the problems that their
host(s) can be having, actually they had four goals which are:

- Easy to use
- Perform certain actions as response of certain messages
- Support customization by users so they could define their actions
- Be reconfigurable without being need to check the manual to know how to do it

Swatch can trigger events if a expression match like "Filesystem Full", "Bad
Login", "EVILCRACKER.org". Since you can configure the events, let's say that
you have a cell phone that has a email address receiving emails as SMS, you
could trigger and event like

echo LOGGING ALERT | mail cellphone@phoneprovider.sms.org

That you would know that you would have troubles.

You can find swatch in http://www.stanford.edu/~atkins/swatch/

Maintining Security
-------------------

Well now that you have taken all the measures said, installed tripwire,
Swatch, subscribed Bugtrag... There's just one more thing that you should always
do to insure a good security level. What's that you ask? Well check for security
problems! If that can be hard and boring for some people it's not that hard and
fun for others. But that's not we are discussing here. If you want to look up
problems like misconfigurations, non-password accounts, mismatching permissions,
and all those tiny details that can get your box in danger well be my guest, but
for the ones that have to much things to do, or are just lazy, or dunnow where
to start there's a really two good program for you, called COPS (Computer Oracle
and Password System) and Tiger.

COPS (Computer Oracle and Password System)
------------------------------------------

COPS is a vunerability testing program, it checks for common security
problems that can happen in your box, like non-passworded accounts, or
word-writable directories that shouldn't be.
The list of what is specially checked is below.

- danger permissions on important system files and directories

- all files with SUID bit (like I always say SUID bit is a ****)

- world-readable/writable file systems

- Null passwords fields in /etc/passwd

- guessability of account passwords

- ilegitimate filesystem changes

- users home directory isn't world writable

- paths and files on crontab file again to see if they aren't world writable

- paths and files on /etc/rc* same reason as last one

This is in what COPS focus, still doesn't mean that it just searchs for
this security problems. It may take some time to install COPS since it has to
be configured specially to your system but after that it will spare you a
couple of hours checking for problems that might affect the security.

You can get COPS from ftp://coast.cs.purdue.edu/pub/tools/unix/cops/

For you all security experts out there (they are probably wishing to
kill me right now), yes I know that COPS is not what people can get as the
more up-to-date security program , STILL COPS rocks even if it was release
for it's first time 11 years ago (1990).

The program comes with extensive documentation, so I think no further
explanations are needed.

Ending Notes
------------

Well I hope that this text has give you some good orientation on how to secure
your box or network agains crackers and script kiddiots. Any feedback is
appreciated, and remember the golden rule "To protect yourself you need to watch
your network from the attackers eyes" spend some time reading advisories, text
about networks and newsgroups like comp.security.unix, comp.security.announce
and comp.os.linux.security. You'll learn a lot with peoples problems, believe
me.

source: http://linux.box.sk/newsread.php?newsid=441

Elcarion · Aug 27, 2002

I didn't see the most important step: 1) Unplug your network cable BEFORE doing a new OS install

It's actually not unlikely that the system will be hacked while you are loading the OS if it's directly connected to the Internet. You shouldn't plug in the network until you've turned off all unnecessary and insecure daemons. I recommend that you do the following:
1) Install the new OS
2) Disable ALL services that are listening
3) If you MUST run Xwindows then run it with the following command: startx -- -nolisten tcp
4) Apply all vendor security patches or at least those for the services you wish to run
5) Secure and start the services you desire

Remember that Linux is no more secure than an other OS right out of the box...they're all insecure in that state.

Elros · Sep 2, 2002

Great information guys. Really useful. My Mandrake was full of holes I had no idea about.

Not any more though.

Mictlantecuhtli · Sep 6, 2002

One thing I'd do is editing /etc/inittab. There are lines like
1:2345:respawn:/sbin/agetty tty1 9600
2:2345:respawn:/sbin/agetty tty1 9600
total of six, usually. That's how many consoles there are. When only one person is using the computer and remote access (via telnet for example) isn't needed, the number could be reduced. I had three consoles when I had not installed XFree86 yet, now that I have, I only use one.
You can either delete the unnecessary lines or (safer method) comment out with '#'.
To apply changes, type telinit q. It tells init to reread inittab without changing the runlevel.

Goalie · May 4, 2003

This is GREAT info guys. I've been looking for a good newbie-ized source of this information that tells you HOW and WHY instead of just "Go secure your box. Shut down services. Etc." This will be GREAT info for me to check, even if my box is no longer on a network. Good practices lead to good results after all, right?

One thing I didn't see mentioned: While you recommend a firewall, it certainly can't hurt to configure hosts.deny/hosts.allow (whatever your appropriate file(s) are) to deny anything except connections you know should come in (as strictly as possible). As well as httpd.conf for apache, since it doesn't obey those rules. This applies to Red Hat at least, I think for many other distros as well. I know doing that saved my backend when I didn't have a firewall available for use. Edit: I assume this is what you meant by IpChain rules.. sorry for being dense... I'd never heard it in those terms..

Again, though, thanks for a bunch of great info guys!!! Any extra suggestions are certainly welcome.

XtR-X · Aug 6, 2003

Kind of new at doing commands at Linux, but how exactly do you disable the things running?

# netstat -a

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:ftp *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 *:telnet *:* LISTEN
tcp 0 0 *:smtp *:* LISTEN
tcp 0 0 *:finger *:* LISTEN
tcp 0 0 *:www-http *:* LISTEN
tcp 0 0 *op3 *:* LISTEN
tcp 0 0 *:shell *:* LISTEN
raw 0 0 *:icmp *:* 7
raw 0 0 *:tcp *:* 7

#

Well for what I'm checking I can tell that this is a newbie linux version,
probably RedHat or Mandrake. Why do I say that? Because those distros come with
plenty of active daemons, this way if the user need it don't need to try to
configure it. Unfortunately the default configurations aren't what we can call
secure so let's get working.

Finger and shell daemons should be shuted ASAP. Why?

Phantasm66 · Aug 7, 2003

Hmm.... best thing for you, if you are running Red Hat or Mandrake, is log in as root, and then run

ntsysv

this will let you control what services are loaded at startup.

Make sure that you know WHAT you are turning off before you do it.

XtR-X · Aug 7, 2003

Ok, gotcha.

Mictlantecuhtli · Feb 18, 2004

http://www.linuxsecurity.com/docs/LDP/Security-Quickstart-HOWTO/index.html

I recommend reading it all the way through

kaymastah · Jan 15, 2006

Thanx for posting this thread Phantasm. It's a pretty nice guide; even though it's a little old (ipchains has been replaced by iptables some time ago...) it gives quite a few good pointers.

This stresses a very basic seecurity rule - run the bare minimum. kill all the services that you don't need.

Someone also posted a suggestion to disable connections to X server, after "startx" command. A lot of new users to linux, are not familiar with X, and besides they use login managers, so they never actually run "startx". They might need to modify:
/etc/X11/xorg.conf

or xf86config depending on which way they're set up for X.

fgaliegue · Feb 11, 2006

kaymastah said:

Someone also posted a suggestion to disable connections to X server, after "startx" command.

This has been the default for quite some time AFAIK. None of the distros I've tried for at least 4 years left the X server authentication process open (they were at my school though, and that was "fun", kind of).

To check this out, just run the xhost command with no arguments. It should reply this:

fg@rtfm ~ $ xhost
access control enabled, only authorized clients can connect

If you see this message you're safe: no one can connect to your X server unless you type xhost +some_host.

2Sher2 · Jul 11, 2008

great tips thanks

TechSpot

Linux Security Tips

Phantasm66 Newcomer, in training

Phantasm66 Newcomer, in training

Phantasm66 Newcomer, in training

Elcarion TechSpot Paladin

Elros Newcomer, in training

Mictlantecuhtli TS Special Forces

Goalie Newcomer, in training

XtR-X Newcomer, in training

Phantasm66 Newcomer, in training

XtR-X Newcomer, in training

Mictlantecuhtli TS Special Forces

kaymastah Newcomer, in training

fgaliegue Newcomer, in training

2Sher2 Newcomer, in training