Tag Info

Hot answers tagged

39

I personally think you're doing alright. As long as your underlying login method is secure, add as many obscurity layers as you want. I have worked with some clients that wanted the exact thing you're trying to achieve. I've always used one of these two methods: Cross-Site login form: A local .html file that has a login form submitting to the ...


23

As Thomas pointed out, this attack is designed to exploit poor content handling in log utilities. There are many "log to HTML" engines that simply extract the text of the logs and place them blindly into a HTML template. When the user requests the HTML page from the server, the <?php tags are parsed by the PHP engine and the code is executed. Since many ...


22

Grab the Center for Internet Security (CIS) guide for securing Apache (it describes in detail how to enhance the security): Edit: Updated link CIS Apache HTTP Server 2.2.x Benchmark If you have a license to Nessus, then you can run an automated check by grabbing their audit template:


22

It's all about what you're trying to achieve and/or mitigate with the use of SSL. Random people on the Internet cannot assess your company's situation. So you need to keep this in your mind: it all depends on the risk, the probability of the risk, and how far you would go to mitigate that risk. @apsillers brings a good point about your job application ...


17

The fact that your website might have job application forms is a sufficient reason to have SSL. In particular, users expect to enter some personal information into your website, but they don't know precisely what information. Letting an eavesdropper read the contents of a job application is bad, but it gets worse. Even if your application form doesn't have ...


14

There are a couple of things you can do to prevent DOS/DDOS. First I would recommend using an autoban firewall. I've been using Fail2Ban for some time now. Most of my problems with DDOS/DOS attacks to SSH,FTP,BIND and etc were solved. What fail2ban actually does is it's scanning a log file and when a regex pattern matches X times it bans the person. With a ...


14

Your method is functionally equivalent to requiring authentication with two passwords, the Referer being one of them. A more common variant is to use a secret URL, i.e. to make the "special string" part of the path to the private site. Including the secret string in the URL may include some extra details to think about (e.g. users can bookmark it, meaning ...


14

I would go as far as considering using git for deployment very good practice. The two problems you listed has very little to do with using git for deployment itself. Substitute .git/ for the config file containing database passwords and you have the same problem. If I have read access to your web root, I have read access to whatever is contained in it. ...


13

Directly, no. This is a matter of security through obscurity. Removing the server headers do not remove the vulnerabilities and functions associated with it. In the context of risk (risk = probability x consequence), it might decrease the possibility to be targeted by some automated tools who rely on fingerprinting your services. The consequences would ...


13

Apache and MySQL can be configured so that they only listen to requests from your own computer. For most test systems this is fine and it greatly reduces the risk because the services are not reachable from the Internet. Before you start XAMPP for the first time find and edit these files: For Apache edit the files xampp\apache\conf\httpd.conf and ...


13

SSL provides several benefits not just data privacy. By presented a properly signed SSL certificate there are some assurances that the server your clients connect to actually is yours (let's assume CAs aren't being negligent). SSL provides data integrity. For every string of text, whitepaper, image, patch, whatever, the user can have some assurance that the ...


12

Revealing that information is a security risk, in the context of a security assesment of your website. (I'm talking about checkbox style assesments here) Nothing more than that - it just makes fingerprinting the webserver more difficult, but by no means impossible - not even hard. It will not hinder any attacker specifically targeting the website not even a ...


12

One way to mitigate BEAST is to do nothing. It so happens that though the vulnerability used in BEAST is still there, exploiting it is rather difficult. It requires the ability to do cross-domain requests, with a high level of control on the data which is sent in the request; in particular, it needs "binary" data. Duong and Rizzo did not find a way to map ...


12

Yes, strict transport security provides a real benefit. HSTS tells the browser to only communicate with the server via HTTPS. The first time the browser sees the HSTS header from the server, it remembers it. When the user visits the site again, the browser enforces that all communication is done via HTTPS. This will work as long as the attacker doesn't ...


12

Simplest way I can think of is using cURL (which is scriptable). curl -v -X TRACE http://www.yourserver.com Running it against an Apache server with TraceEnable Off correctly returns HTTP/1.1 405 Method Not Allowed (just tested on an Apache 2.2.22) This also works on HTTPS sites, provided that cURL has the correct information supplied to the SSL layer. ...


11

Yes you can, apache log gives you information about people who visited your website including bots and spiders. patterns you can check: someone made multiple requests in less than second or accepted time frame. accessed secure or login page multiple times in a one minute window. accessed non existent pages using different query parameters or path. apache ...


11

To get started, you're probably going to want to focus on two things: Securing your web server Security your website That's really two different specialties, and I don't think I'm going to be able to dig up a single document describing both... the ardent security nerd would also point out that this assumes you're working in a secure network with decent ...


11

Probably someone trying to create an account on your forum and proceed to spam it. I read about it here: http://www.projecthoneypot.org/ip_95.168.162.43 When you URL decode the string two times and google the string you find a lot of spam on different forums. URL Decoded one time: èñïîëüçîâàí íèêíåéì "immultusa"; çàðåãèñòðèðîâàëèñü (âêëþ÷åí ðåæèì ...


11

You cannot really hide the domain name, because if someone connects to the port 443 of your server and begins initiating a SSL connection, your server will respond by sending his certificate... which contains the server name. Actually, the client may send the intended client name as part of a Server Name Indication, which is a rather recent extension which ...


10

This is really a pretty stinking huge question. Based on your chosen tags it looks like you're asking for guidance on a LAMP stack, so we'll focus on that. There are already a number of related hardening questions posted, so for some additional insights check out these questions: MySQL Server Hardening Hardening Linux Server What are the best practices for ...


10

HTTP TRACE method basically replies the request, together with all the headers in response. Cookie header will also be included in response. Session cookies should have httpOnly flag for preventing Session Hijacking attacks. This flag blocks access to the cookie value from Javascript. Basically this ensures that even if attacker will exploit a XSS flaw in a ...


10

What does this nonsense all mean? What can I do about TLS 1.0 javascript injection vulnerability on my server? What should I change to? Should I ignore the BEAST SSL exploit and continue to prefer AES? An in-depth look at different cipher selections and their impact: What ciphers should I use in my web server after I configure my SSL certificate? The ...


9

Restrict the daemon with MAC No matter how you cut it, wrapping Apache in a mandatory access control layer like AppArmor or SELinux is a good first step. That will allow you to restrict the daemon's allowable operations even if otherwise has permissions to do so. That will prevent Apache from ever modifying your files. Use version control with automatic ...


9

A system upgrade is required but here a quick fix. In /etc/apache2/sites-enabled/000-default I comment out: ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ...


8

Use SSH key based logins Secure MySQL Disable phpMyAdmin, webmin, etc Close all ports/process's that are not needed Use a file integrity checker Use mod_security Set the proper permissions/groups This is a good guide: http://serverfault.com/questions/212269/tips-for-securing-a-lamp-server Basic guide for hardening http://www.wpsecure.net/server-guide/ ...


8

You're absolutely right, keeping the user running the webserver process, in your case apache isolated from writing to the webroot is a good idea. It is one of the basic hardening guides for a reason. If the user can write to the files or directories, then it makes it easier for a malicious user to modify the filesystem. One thing you aren't taking into ...


8

Fail2ban does exactly what you ask. It monitors your log files looking for certain patterns and then executes whatever action you specify. You can block an IP for a length of time. It does require some skill in regex, but it comes packaged with regex testers.


8

It is partial security as you mentioned, but this blacklisting approach will get you nowhere. For one, these snippets supposedly protect you from various attack vectors: base64_encode looks for (most likely) PHP Remote Code Execution payload script rule tries protect from XSS the others are weird and possibly related to RCE or old PHP vulnerabilities ...


8

OpenSSL has a mitigation for BEAST which has been enabled by default since 0.9.6d, so as long as your OpenSSL version is this version or later and you haven't set SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS there is no need to restrict ciphers or disable TLS 1.0.



Only top voted, non community-wiki answers of a minimum length are eligible