Block IP Addresses in Juniper Firewalls

This article will go over configuring your Juniper hardware firewall to block certain IP addresses from accessing services. This is only for Cloud and Dedicated customers who have write access to their firewall. If you do not have access and wish to have access, please contact your sales representative. This article is meant for advanced users.
To create a new policy in your Juniper SSG Firewall for blocking IP addresses, please follow these steps:
1. Log into the firewall. You will have been given an IP address and access to this IP address by support.
2. Once logged into the firewall, navigate to Policy on the left hand navigation bar. Expand Policy and click Policies Elements. Then expand Addresses and click List.




3. To add a new IP address, choose the source zone (typically Untrust) from the drop down at the top of the screen. Then click New.
4. In the Address Name field, enter in the IP address or host or host you wish to block. This can be in CIDR format. For the comment, we typically recommend putting "Blocked IP" although it's just for tracking purposes. Select the appropriate radio button (IP Address/Netmask or Domain Name) and enter in the information again. Leave the zone as Untrust and click OK.



5. If you are adding multiple IP addresses to a blocked list, then it is recommended to create a group. Go back to Policy > Policy Elements > Addresses > Group > and add a new group. Name the group Blocked IP Addresses or something similar, and move the IP addresses/hosts from the left box to the right box and click OK.



6. Now to add the policy. Navigate to Policy > Policies and choose the source zone (typically Untrust) and the destination zone (typically Trust) from the drop downs at the top of the screen. Then click New.
7. From the Source Address drop down, choose the source IP address or host. If this policy is for multiple sources, click the Multiple button and add the multiple sources from the list. From the Destination Address drop down, choose the destination IP address or host. If this policy is for multiple destinations, click the Multiple button and add the multiple destinations from the list. If you do not see your source or destination IP or host listed, make sure it exists under the zone under Policy > Policy Elements > Addresses > List. If it does not exist, add the IP or host under the appropriate zone.




8. Under the Service drop down, select the service you will be connecting to. If you do not see the service listed, make sure it exists under the zone under Policy > Policy Elements > Services > Predefined. If it does not exist, click Custom and add the service ports (UDP, TCP, ICMP, or other).



9. From the Action drop down, choose Deny. This will deny the policy.
10. If you wish to enable logging for the policy, check the box for Logging and at Session Beginning. Once the policy is to your liking, click OK and the policy has been added at the bottom of the listing for that interface group.



11. The main policy listing will show a red X under the Action column showing that the policy is denying traffic rather than showing a green checkmark for allowing traffic.
Note: Please do not modify the Global Policy section. Often times modifying the policies contained within will prevent our internal servers from communicating with your servers which includes monitoring services. Please check with support if you have questions before modifying these policies.

Best Practices for Policy-Based Email Encryption

• Transport Layer Security (TLS): This is an Internet standard extension to SMTP and is universally supported in mail transfer agencies. It can be used as an authentication method as well as an encryption method.
• S/MIME Gateway Encryption: This allows two organizations to establish encrypted links with each other by exchanging organizational keys (certificates) and having the email servers automatically encrypt and decrypt messages.
• End-to-end Encryption: The most secure means of encryption and can provide non-reputatiblty.
• No-Client-Side-Software-Required: This means that the sender doesn’t have to have a public key in order to encrypt email to a recipient.

Open Source Anti Virus - Clam AV

Clam AV is open source anti virus engine that develop by community. It was very famous for Gateway level of scanning, however today Source Fire had release Clam AV Windows edition which most of the basic features are free, only advance and support need additional charge only.

Here are the info from Clam AV website:

ClamAV is an open source (GPL) antivirus engine designed for detecting Trojans, viruses, malware and other malicious threats. It is the de facto standard for mail gateway scanning. It provides a high performance mutli-threaded scanning daemon, command line utilities for on demand file scanning, and an intelligent tool for automatic signature updates. The core ClamAV library provides numerous file format detection mechanisms, file unpacking support, archive support, and multiple signature languages for detecting threats. The core ClamAV library is utilized in Immunet 3.0, powered by ClamAV, which is a fast, fully featured Desktop AV solution for Windows.

Immunet 3.0, powered by ClamAV is a fast, fully featured Windows desktop Anti-Virus (AV) solution that utilizes the power of advanced cloud based detection techniques and the strength of the time tested ClamAV engine. This unique combination of technologies allows for a highly effective approach to today’s fast moving malware threats.
Features:

• Real-time detection

• Scheduled scanning

• Intelligent Scanning – Fast and configurable smart scans

• Custom Detection – Using the de facto standard ClamAV signature language

• Advanced archive and packer support

• Fast and light system footprint

• Quarantine

Blocking Skype via Squid 3.0

In order to block the Skype by using Squid 3.0, here is guide from squid web site.

# Skype

acl numeric_IPs dstdom_regex ^(([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)|(\[([0-9af]+)?:([0-9af:]+)?:([0-9af]+)?\])):443
acl Skype_UA browser ^skype^

http_access deny numeric_IPS
http_access deny Skype_UA

• Recent releases of Skype have been evading the above restriction by not sending their User-Agent headers and using domain names. The following can be used to catch those installs, but be aware it will likely also catch other agents.

acl validUserAgent browser \S+
http_access deny !validUserAgent

Hardening Sendmail

Connection Controlling
FEATURE(`access_db')dnl
FEATURE(`delay_checks', `friend')dnl
FEATURE(`ratecontrol', `nodelay',`terminate')dnl
FEATURE(`conncontrol', `nodelay',`terminate')dnl
After the already existing line "FEATURE(`access_db')dnl" I added the lines to enable rate and connection-controlling.
The option "nodelay" is important, because I am using the delay-checks-feature, and these checks are not to be delayed.
The "terminate"-option tells sendmail to kill all connections exceeding the later defined limits with a temporary error-message. The properly configured and standard-compliant smtp-client will try again later, spammers usually don't.
The rate-control feature enables control over how often a single host is allowed to connect per a defined window. It was introduce by sendmail version 8.13.0, and uses the access.db for defining the limits for single hosts, groups of hosts or all hosts.
The window-size is defined using the this option:
define(`confCONNECTION_RATE_WINDOW_SIZE',`window')dnl
with a default-value for window of "60s" (60 seconds).
My access.db-entries for the rate-control-feature look like this:
ClientRate:localhost 0
ClientRate:localhost.localdomain 0
ClientRate:127.0.0.1 0
ClientRate: 5
The first three lines tell sendmail to ingore rate-limits for the localhost, and the last line imposes a limit of 5 connections per window for all hosts.
In cases of a DDoS, it might not be sufficient to limit the connections of a single host per minute, because a DDoS comes from multiple hosts at the same time. This is why Sendmail come with another option:
define(`confCONNECTION_RATE_THROTTLE', `5')dnl
This defines the overall number of concurrent connection the server accepts per second, before queuing incoming connection-request regardless of the host. The connections will not be rejected but stalled until the next second. This means that for the above example that when 20 connection-requests arrive, the first five (1-5) are processed in second one, the second five (6-10) in second two, the third five (11-15) in second three, and the final five (16-20) in second four.
The conn-control feature enables control over the number of concurrent connections a single host is allowed to run simultaneously. Like rate-control, this feature was introduced with Sendmail 8.13, and the access.db is used to define settings for single-hosts, host-ranges and "all hosts", too.
My access.db-entries for the conn-control-feature look like this:
ClientConn:localhost 0
ClientConn:localhost.localdomain 0
ClientConn:127.0.0.1 0
ClientConn: 3
The entries are read similar to rate-control. The last line defines a default of 3 concurrent connections, the first three disable the feature for localhost.
Greeting Pause
A common technique of spammers, trojans and viruses is the so-called slamming. The SMTP-Standard requires the client to wait with the HELO/EHLO-Command until the server has sent its greeting line. Slamming is to ignore this, and to start sending immediately.
FEATURE(`greet_pause', `2000')dnl
With the above feature, Sendmail can be configured to delay the sending of this greeting. The value is in milliseconds, so in the example above, the greeting-pause would be two seconds. A client issuing the HELO/EHLO during this pause will cause Sendmail to answer with
554 smtp.nifelhei.info not accepting messages
and the greeting will not be send. Sendmail will log such attempts with a message like
rejecting messages from due to pre-greeting traffic.
and terminate the connection.
You can use the access.db again to define host-specific greeting-pause times, or to exclude certain hosts from the pause. The following example would exclude localhost from the delay. You can use this to whitelist smtp-servers who do slamming but are otherwise "friendly".
GreetPause:localhost 0
GreetPause:localhost.localdomain 0
GreetPause:127.0.0.1 0
Please note:
RFC 2821 specifies 5 minutes as the maximum timeout for the initial connection greeting. Therefore, if you specify a time longer than 300000 milliseconds (i.e. 5 minutes), sendmail will not wait longer than 5 minutes, to maintain RFC compliance.
Recipient-Controlling
After setting up the controlling mechanisms for incoming connections, there is a another level of control that can be applied. Many spammers try to send a single mail with hundreds of recipients. This is also known as "recipient flooding". Sendmail can be configured to limit the number of recipients a message may have, as well throttling down all those clients who try to add more recipient than a certain threshold by pausing a hardcoded full second between each accepted recipient. The options are as follows:
define(`confBAD_RCPT_THROTTLE', `2')dnl
define(`confMAX_RCPTS_PER_MESSAGE', `25')dnl
BAD_RCPT_THROTTLE sets the threshold which invokes the one-second-delay. For the example above this means that with the third RCPT TO: sendmail will pause one full second, before sending the response.
MAX_RCPTS_PER_MESSAGE limits the absolute maximum number of recipients for each message to the value given (25 for the above example). Every RCPT TO: exceeding this number will be rejected with an appropriate message. The standard-compliant server will collect the rejected RCPT TOs and requeue the message for all yet outstanding recipients. (Yes, spammers won't.)
Timeouts
Sendmail, in order to get as many as possible mails through, has very generous timeout-defaults. These values are often measured in days, where today seconds or minutes would suffice. Long timeouts mean long bound resources for probably unsolicited connections. I have defined much shorter values for several timeouts:
define(`confTO_INITIAL', `30s')dnl
define(`confTO_CONNECT', `30s')dnl
define(`confTO_ACONNECT', `1m')dnl
define(`confTO_ICONNECT', `30s')dnl
define(`confTO_HELO', `30s')dnl
define(`confTO_MAIL', `30s')dnl
define(`confTO_RCPT', `30s')dnl
define(`confTO_DATAINIT', `1m')dnl
define(`confTO_DATABLOCK', `1m')dnl
define(`confTO_DATAFINAL', `1m')dnl
define(`confTO_RSET', `30s')dnl
define(`confTO_QUIT', `30s')dnl
define(`confTO_MISC', `30s')dnl
define(`confTO_COMMAND', `30s')dnl
define(`confTO_CONTROL', `30s')dnl
define(`confTO_LHLO', `30s')dnl
define(`confTO_AUTH', `30s')dnl
define(`confTO_STARTTLS', `30s')dnl

M4 approach

/etc/mail/sendmail.mc
MaxDaemonChildren
define(`confMAX_DAEMON_CHILDREN‘,’30‘)dnl
MaxMessageSize
define(`confMAX_MESSAGE_SIZE‘,’10000000‘)dnl
ConnectionRateThrottle
define(`confCONNECTION_RATE_THROTTLE‘,’10‘)dnl
MaxRecipientsPerMessage
define(`confMAX_RCPTS_PER_MESSAGE‘,’1000‘)dnl

TOP TEN TIPS FOR SMALL AND MEDIUM-SIZED BUSINESSES

The following constitute the essentials of defence for your IT security:

- carrying out basic screening checks on all your employees and contractors
- having short, clearly documented security policies and procedures

- carrying out basic security awareness training with your employees

- implementing patches for software vulnerabilities as soon as possible

- knowing who is accessing your systems, and why

- using strong passwords and changing them regularly

- making sure your anti-virus system is updated every few days

- using a content-filtering system to guard against spam and phishing

- using a firewall, especially if you have broadband Internet access

- using an ‘all-in-one’ network defence system with a small network

ISMS -Information Security Management System

The progress of data protection standards implementation in Malaysia is slowly gathering pace and its importance is becoming more and more apparent to organizations around the country.

Now a day, Malaysia Government is encouraging the IT company to apply the ISO/IEC 27001:2005 to protect the company assets and information.

What is an Information Security Management System?

An Information Security Management System (ISMS) is a systematic approach to managing sensitive company information so that it remains secure. It encompasses people, processes and IT systems. BSI published a code of practice for these systems, which has now been adopted internationally as ISO/IEC 27001:2005.