Linux Firewalls - Michael Rash [49]
For example, here is a portion of a phishing email I received from the spoofed email address support@citibank.com with the subject Citibank Online Security Message:
When signing on to Citibank Online, you or somebody else have made several login
attempts and reached your daily attempt limit. As an additional security measure your
access
to Online Banking has been limited. This Web security measure does not affect your
access to phone banking or ATM banking. Please verify your information href="http://196.41.X.X/sys/" onMouseMove="window.status= 'https://www.citibank.com/us/cards/ index.jsp';return true;" onMouseout="window.status=''">here
sign on
again. You will be able to attempt signing on to Citibank Online within twenty-four
hours after you verify your information. (You do not have to change your Password at
this time.)
The innocuous wording feigns a cordial and helpful attitude ("several login attempts," and "You do not have to change your password . . ."), and the web link is carefully crafted. The link contains a bit of embedded JavaScript that instructs a web browser to display a legitimate link to the Citibank website if the user puts the mouse pointer over the link text here in the email message.[30] However, the real destination of the link is to the URL http://196.41.X.X/sys, which is a webserver controlled by the attacker. This webserver displays a web page that looks identical to the legitimate page on the authentic Citibank website.
Fortunately, iptables can detect this particular phishing email when it is viewed over a web session with the following rule:
[iptablesfw]# iptables -I FORWARD 1 -p tcp --dport 25 -m state --state ESTABLISHED -m
string --string ❶"http://196.41.X.X/sys/" --algo bm -m string --hex-string ❷
"window.status=|27|https://www.citibank.com" -j LOG --log-prefix "CITIBANK PHISH "
At ❶ and ❷ the rule performs a multistring match against the strings "http://196.41.x.x/sys/" and "window.status='https://www.citibank.com" within established TCP connections to the SMTP port. The first string in the signature requires a match against the particular malicious webserver setup by the attacker, and so this rule does not generically describe all possible phishing attacks against Citibank. The second string is also important, because it looks for the Citibank website used as the argument to the window.status JavaScript window object property. While the real Citibank website might also use this construct for legitimate purposes, the combination of the two strings together in an email message is highly suspicious and has a low chance of triggering a false positive either within Snort or iptables (regardless of the order of the patterns).
You can maximize the effectiveness of new signatures for new attacks by striking a balance between effective detection and reducing the false positive rate. One of the best ways of doing this is to look for patterns that are not likely to be seen in legitimate network communications. If another phishing attack becomes popular against a new target, then good candidates for patterns to include within a signature are the IP address associated with the malicious webserver (although this is always subject to change by the attacker) and any common language or code features (such as the window.status string in the Citibank phishing example).
Backdoors and Keystroke Logging
A backdoor is an executable that contains functionality exposed to an attacker but not to a legitimate user. For example, the Sdbot trojan[31] opens a backdoor by using a custom IRC client to connect to an IRC channel where an attacker is waiting to issue commands, but the backdoor is coded such that the attacker must provide a valid password before any action is taken. This adds a level of authentication to backdoor