|
Need a quick security fix? Whether its sudo or lilo, tcp or icmp, you'll find short and straight-to-the point guidance in our listing of Security Tips.
|
|
|
Posted by Ryan Berens
|
(Just in case you forgot)
The dictionary defines "proxy" as "the authority or power to act on behalf of another". This pretty well describes software proxies as well. It is an intermediary in the connection path. As an example, if we were using a web proxy like "squid" (http://www.squid-cache.org/), every time we browse to a web site, we would actually be connecting to our locally running squid server. Squid in turn, would relay our request to the ultimate, real destination. And then squid would relay the web pages back to us. It is a go-between. Like "firewalls", a "proxy" can refer to either a specific application, or a dedicated server which runs a proxy application.
Proxies can perform various duties, not all of which have much to do with security. But the fact that they are an intermediary, makes them a good place to enforce access control policies, limit direct connections through a firewall, and control how the network behind the proxy looks to the Internet. So this makes them strong candidates to be part of an overall firewall strategy. And, in fact, are sometimes used instead of packet filtering firewalls. Proxy based firewalls probably make more sense where many users are behind the same firewall. And it probably is not high on the list of components necessary for home based systems.
Configuring and administering proxies can be complex, and is beyond the scope of this document. The Firewall and Proxy Server HOWTO has examples of setting up proxy firewalls here -
http://tldp.org/HOWTO/Firewall-HOWTO.html
Squid usage is discussed at
http://squid-docs.sourceforge.net/latest/html/book1.htm |
|
|
Posted by Aditya K Sood
|
|
This article solely relates to the the insecurities that remain in the XML schema defined for any web server that relates to peculiar web servicing application. This is actually based on the AJAX framework as the xml specification act as an interface to server objects. The interface which is being provided by the xml schema directly configures the server on the fly which is dependent on the specific service providing servlet. The wrong schema in the web.xml or the index.xml provide leads to the origin of the web attack base that really disrupts the functioning of the server which further results in leveraging information. I am going to discuss the schema designing and relative effects if it is not configured properly. |
|
|
Posted by Eric Lubow
|
|
When possible use secure connection methods as opposed to insecure methods. Unless you are required to use telnet, substitute ssh (Secure SHell) in for rsh or telnet. Instead of POP3 or IMAP use SPOP3 or SIMAP (IMAPS). Both SIMAP and SPOP3 are just versions of IMAP and POP3 running over an SSL (Secure Socket Layer) tunnel. |
|
|
Posted by Eric Lubow
|
A SYN-flood attack has the ability to bring the network aspect of your linux box to a snail-like crawl. TCP_SYNCookies protection attempts to stop this from taking a heavy toll on the machine. To enable tcp_syncookies protection, use the following command:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
|
|
|
Posted by Eric Lubow
|
To turn on spoof protection, run a simple bash script:
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i done;
Be careful to remember that it drops packets more or less 'invisibly'. |
|
|
Posted by Eric Lubow
|
To find out the .Xauthority magic cookie looks like and to send it (authorization information) to the remote host, use the following command:
xauth extract - $DISPLAY | ssh storm xauth merge -
Now the user who ran this command on the original host can now run xcilents on storm. xauth needs to be present on both hosts. |
|
|
Posted by Eric Lubow
|
Instead of using "xhost +" to open up access to the X server, be more specific. Use the server name that you are allowing control to:
xhost +storm:0.0
Once you are done using it, remember to disallow access to the X server from that host:
xhost -storm:0.0
|
|
|
Posted by Eric Lubow
|
Turn off PasswordAuthentication and PermitEmptyPasswords in the SSH configuaration file /etc/ssh/sshd_config. This will ensure that users cannot set empty passwords or login without SSH keys.
PermitEmptyPasswords no
PasswordAuthentication no
|
|
|
Posted by Eric Lubow
|
Use sudo to execute commands as root as a replacement for su. In the /etc/sudoers file, add the following lines by using the visudo command:
Cmnd_Alias LPCMDS = /usr/sbin/lpc, /usr/bin/lprm
eric ALL=LPCMDS
Now the user 'eric' can sudo and use the lpc and lprm commands without having any other root level access. |
|
|
Posted by Eric Lubow
|
Users who have sudoer (sudo) accounts setup can have the account setup to change to root without a password. To check this, as root use the following command:
grep NOPASSWD /etc/sudoers
If there is an entry in the sudoers file, it will look like this:
eric ALL=NOPASSWD:ALL
To get rid of this, type visudo and remove the line in that file.
|
|
|
<< Start < Prev 1 2 3 Next > End >>
|
| Results 11 - 20 of 32 |
