SPAM: It's evil, everywhere and constant. Oh Joy!
Thankfully, you can help avoid it reaching your client by using the power of Postfix to run your mail. Sendmail, Qmail and others provide mail, sure, but limiting false positives, avoiding server overloads, and establishing a good defense is just plain better with Postfix.
Whether you like gray listing, want to configure black lists, or want a step-by-step on setting up secure mail - this is a great, quick overview. |
|
(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 |
|
|
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. |
|
|
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. |
|
|
TCP_SYNCookies
|
22 August 2006
|
|
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
|
|
|
|
<< Start < Prev 1 2 3 Next > End >>
|
| Results 10 - 18 of 32 |
