This is mostly for own use, but: If you've ever had a server which netstat showed was listening on one or more ports you weren't expecting, you can use this command to find out which process is listening there:

fuser -vn tcp 4444

Which in this case happens to be owned by JBoss, and not some linux version of a windows worm:)

For more info on fuser, check out the man page, or the simple help below:

Usage: fuser [ -a | -s | -c ] [ -n SPACE ] [ -SIGNAL ] [ -kimuv ] NAME...
[ - ] [ -n SPACE ] [ -SIGNAL ] [ -kimuv ] NAME...
fuser -l
fuser -V
Show which processes use the named files, sockets, or filesystems.
-a display unused files too
-c mounted FS
-f silently ignored (for POSIX compatibility)
-i ask before killing (ignored without -k)
-k kill processes accessing the named file
-l list available signal names
-m show all processes using the named filesystems
-n SPACE search in this name space (file, udp, or tcp)
-s silent operation
-SIGNAL send this signal instead of SIGKILL
-u display user IDs
-v verbose output
-V display version information
-4 search IPv4 sockets only
-6 search IPv6 sockets only
- reset options
udp/tcp names: [local_port][,[rmt_host][,[rmt_port]]]

Adding a CAPTCHA to a form using Seam is easy now that Seam is bundling jCaptcha.

The Seam documentaiton is good, and can be found in section 13.9 here:

http://docs.jboss.com/seam/2.0.0.CR2/reference/en/html/security.html#d0e7755

If you used seam-gen to create your project, you will need to make a few changes.

First, you need to modify your project's ant build script to deploy the captcha jar into your ear (or possibly .war). In the target "ear" of the build.xml file, you will find a list of many jar files being copied from your project's lib directory into the ear. Simply add the captcha jar to that list, like this:

<include name="lib/jcaptcha-all-1.0-RC6.jar"></include>

Now that the jar is deploying, you need to reference it in the application.xml file found under your project's resources/META-INF directory. Add this entry:

<module>
<ejb>lib/jcaptcha-all-1.0-RC6.jar</ejb>
</module>

If you used seam-gen you will find that the Seam Resource Servlet is already defined in your web.xml so the step defined in the documentation in section 13.9.1 is not necessary.

(more...)

I run Debian on my server, and I often find that my server is being attacked by other computers. Brute force SSH attacks, viruses scanning for the ability to spread, things like that. I'll go into the SSH brute force defenses in a later post, but for now I'll cover how to easily block an IP address.

First, I'll assume you are already using iptables. If you need help setting that up, use Google, Debian comes with it out of the box.

I have a small script called "block" which looks like this:
#!/bin/bash
sudo iptables -I INPUT -s $1 -j DROP
sudo bash -c "iptables-save > /etc/network/iptables.save"

Whenever I find a "bad" IP in my logs or notifications, I just run:

block bad.ip.add.18

Substituting the bad ip for that nonesense above. This adds it to the list of IP address which iptables will simply drop any incoming packets from, and saves the in memory iptables configuration, so that it is preserved through reboots.

Then in your /etc/network/interfaces file, just add this at the bottom:

post-up iptables-restore /etc/network/iptables.save

World-facing websites always have to be written carefully in order to prevent malicious attacks. There are tons of additional vulnerabilities and attack vectors which need to be addressed as well, but in this post I'm going to talk about the two most common: Cross Site Scripting (XSS) and SQL Injection.

If you already know what these are, feel free to skip down a bit to the section where I talk about where ATG Dynamo helps and where there are still some gaps.

Cross Site Scripting is essentially when someone malicious gets your website to source in their content, from their site usually (hence the "cross site"), to what you serve to your users. This can take many forms including embedding a malicious page inside an existing frame in your website, sourcing in javascript which runs on your user's computer as if it had come from your site, embedding an inappropriate image in a page, or using tricks (or javascript) to redirect the user from your site to a competitor or even a site that LOOKS like yours, but isn't.

It is an attack against your users, not your servers.

(more...)

There are many reasons that you may wish to put a third-party javascript reference on your website. Serving ads, making use of tracking and analytics tools such as Google Analytics, and many other features may want to use a remotely referenced third-party javascript. The big issue here is trust. By putting a remotely referenced javascript on your pages you are essentially handing some control of your visitors’ browsers’ over to this third-party. Maliciously crafted javascript can be used to install software, steal form submission data, rewrite elements of pages, send users to fake phishing sites instead of the real site, crash browsers, popup ads or inappropriate content, and much more. The range of possible attacks using javascript is a long discussion in and of itself, and I won’t go into it here. (Google around or ask me if you want more information on this area of things.)

Read about it after the fold....

(more...)