Ady Wicaksono Daily Activities

Archive for the ‘networking’ Category

Sendmail STARTTLS, how to force email relay to use TLS

with 2 comments

Sendmail STARTTLS Issue
=======================

The idea of this paper is how to force email relay/end SMTP destination to retrieve our
email securely using TSL (Transport Security Layer). If the relay or mail destination 
doesn't support TLS, email will not be delivered to it.

Such scenario is simply given in this diagram:

                      (1)                         (2)                        
[ mail client ] === send email ===> [ MTA1 ] === relay to 
                                                   |
+==================================================V
| (3)                     (4)
+======> [ MTA2 ] === delivery to ===> [ mail server (SMTP destination) ]

I assume:
=========
MTA1: 10.254.80.31
MTA2: 10.254.70.8

Our purpose now is to make MTA1 - MTA2 communication is secured using TLS.

I) What happened if MTA2 doesn't support TLS? Let us try by following this scenario below:

Step 1. (to be done on MTA2)
   - disable STARTTLS 
   - Edit /etc/mail/access append this line:
   
	Connect:10.254.80.31                    RELAY

     After append that line above, please run this command (as root)

	makemap hash /etc/mail/access.db = 128 bits. If not, then MTA1 
     will not relay email to MTA2.
     
     After append that line above, please run this command (as root)

	     makemap hash /etc/mail/access.db < /etc/mail/access

Step 3. (to be done on email client)
Try to send email now using MTA1, now monitor MTA1, wait and check mail queue there:

- Using mailq command you get like this

-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
m675MXpo001370      536 Mon Jul  7 05:22 
                 (Deferred: 403 4.7.0 encryption too weak 0 less than 128)
                                         

Message is deferred, since based on our rule, message send through 10.254.70.8 (MTA2) 
which is our relay must be encrypted, but we didn't configure MTA2 to be TLS enabled. 
Error message:

        403 4.7.0 encryption too weak 0 less than 128
 
there describe that we want encryption but relay mail server doesn't support it.

II) What happened if MTA2 support TLS? Simply enable TLS on MTA2 and see what happened :)
    Email should be delivered normally now  

FAQ:
* How to check if the SMTP support TLS? 
  Try to connect (using telnet) to port 25, say hello and you will see "250-STARTTLS" there.
  E.g:
	# telnet localhost 25
	Trying 127.0.0.1...
	Connected to CM (127.0.0.1).
	Escape character is '^]'.
	220 localhost.localdomain ESMTP Sendmail 8.12.10/8.12.11; 
	EHLO localhost
	250-localhost.localdomain Hello CM [127.0.0.1], pleased to meet you
	250-ENHANCEDSTATUSCODES
	250-PIPELINING
	250-8BITMIME
	250-SIZE
	250-DSN
	250-ETRN
	250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
	250-STARTTLS
	250-DELIVERBY
	250 HELP

* How to enable/disable TLS feature on sendmail?
  See: http://www.sendmail.org/~ca/email/starttls.html#starttlssetup

Link related:
 1. www.sendmail.org
     	     



Advertisements

Written by adywicaksono

July 7, 2008 at 5:53 am

Posted in Linux, networking

Rejecting “ping” to your linux server

with one comment

Sometimes you’re so paranoid so you don’t like
others to “ping” your server. How to do this?
Read the article below to get the answer

I assume our linux IP server is 10.160.154.102
In normal condition we can ping like this:

c:>ping 10.160.154.102

Pinging 10.160.154.102 with 32 bytes of data:

Reply from 10.160.154.102: bytes=32 time<10ms TTL=64
Reply from 10.160.154.102: bytes=32 time<10ms TTL=64
Reply from 10.160.154.102: bytes=32 time<10ms TTL=64
Reply from 10.160.154.102: bytes=32 time<10ms TTL=64

Ping statistics for 10.160.154.102:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

But if we reject this ICMP echo-request using iptables like this

iptables -I INPUT -p icmp --icmp-type echo-request -j REJECT

Now we get destination port unreachable

C:>ping 10.160.154.102

Pinging 10.160.154.102 with 32 bytes of data:

Reply from 10.160.154.102: Destination port unreachable.
Reply from 10.160.154.102: Destination port unreachable.
Reply from 10.160.154.102: Destination port unreachable.
Reply from 10.160.154.102: Destination port unreachable.

Ping statistics for 10.160.154.102:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

Actually our server is not purely drop the ICMP packet, but simply
send ICMP destination-unreachable. If we want to drop it, then you use
this iptables command

iptables -I INPUT -p icmp --icmp-type echo-request -j DROP

Now the ping result will be different:

C:>ping 10.160.154.102

Pinging 10.160.154.102 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.160.154.102:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

So, happy protecting

Written by adywicaksono

November 9, 2007 at 9:38 am

Posted in Linux, networking

Private IP Address

with one comment

Current Internet Protocol widely use is IP version 4. This IPv4 in short term, allocate 32 bit address, so there’re maximum 2^32 = 4.294.967.296 IP addresses in the Internet. Big number but seems will not enough 🙂

IPv6 has bigger address space, 128 bit, so we will have 2^128 = 340.282.366.920.938.463.463.374.607.431.768.211.456 IP addresses in the internet, very big number :D.

However, IPv6 is not widely deployed now, some solution already proposed to minimize the address space limitation problem on IPv4, one of them is IP private. RFC 1918 defines IP private which should not used on public internet:

     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

Normally we will use this address on our home or office and we will able to access internet either using proxy or NAT/IP Masquerade solution.

Written by adywicaksono

November 7, 2007 at 4:25 pm

Posted in networking

TCP SYN Cookie for handling SYN Flooding problem

leave a comment »

Although TCP is widely used by many applications today, there’re still some drawbacks of this protocol. One of them is SYN Flooding problem. Let us first understand how TCP connection established.

1. When a TCP client want to connect to TCP server, TCP client will send initial TCP packet with SYN flag active. This packet contains sequence number (32 bit length), let say this seq. number is X.

2. When TCP Server receive this initial packet, then TCP server will send TCP packet contain SYN + ACK flag active. This packet contain:
1. next sequence number of TCP client’s packet which is = X+1
2. It’s own sequence number, let say this TCP server seq. number is = Y

TCP server will then allocate buffer to save this packet information.

3. TCP Client receive this SYN+ACK packet and then send the ACK packet to TCP server to acknowledge the TCP server’s next seq number which is = Y + 1

And then connection established

The problem is, if TCP client just follow 1st step and never send ACK packet as described at step 3, then TCP server will allocate memory buffer for bogus connection. Especially if TCP client spoof it’s IP address and send huge number of initial TCP SYN connection, then TCP server could crash because out of memory.

Using TCP SYN Cookie, TCP Server use special algorithm which you can read here, so on step 2 above, TCP server will never allocate buffer memory to save it’s own TCP SYN+ACK information. TCP server will be able to extract it’s sequence number if client send ACK that contain’s next sequence number.

SYN Cookie was created by Daniel J. Bernstein, creator of many open source software like QMail, djbdns and publicfile

Written by adywicaksono

November 3, 2007 at 10:59 am

Posted in networking

Traceroute – how it works?

leave a comment »

I was a network and system administrator, one of tools I used is traceroute or tracert (in Windows). See this example traceroute from my desktop:

Tracing route to www.yahoo-ht3.akadns.net [69.147.114.210]
over a maximum of 30 hops:
1     2 ms     1 ms     2 ms  192.168.1.1
2     9 ms    15 ms    12 ms  10.53.128.1
3    13 ms    11 ms    12 ms  172.20.53.65
4    12 ms    11 ms     8 ms  172.26.53.1
5    16 ms    12 ms    13 ms  172.20.8.245
6    12 ms    14 ms    13 ms  203.116.5.125
7    20 ms    16 ms    24 ms  203.118.3.229
8   232 ms   237 ms   230 ms  so-4-0-0.edge2.LosAngeles1.Level3.net [4.71.134.1]
9   233 ms   232 ms   230 ms  ae-2-54.bbr2.LosAngeles1.Level3.net [4.68.102.97]
10   237 ms   229 ms   232 ms  ae-0-0.bbr1.SanJose1.Level3.net [64.159.1.129]
11   316 ms   230 ms   426 ms  ae-13-69.car3.SanJose1.Level3.net [4.68.18.5]
12   386 ms   402 ms   400 ms  4.71.112.14
13   283 ms   294 ms   287 ms  so-0-0-0.pat2.dcp.yahoo.com [216.115.101.150]
14   292 ms   295 ms   289 ms  ge-3-1-0-p171.msr2.re1.yahoo.com [216.115.108.71]
15   288 ms   291 ms   293 ms  gi1-22.bas-a1.re3.yahoo.com [68.142.238.65]
16   285 ms   286 ms   286 ms  f1.www.vip.re3.yahoo.com [69.147.114.210]

Traceroute use TTL (time-to-live) feature of IP (Internet Protocol). TTL is an upper bound of the time that IP datagram packet can exist in an internet system. TTL field will be decrease by one value by every host on the route to its destination. If the TTL field reaches zero before the datagram arrives at its destination, then the datagram is discarded and an ICMP error datagram (11 – Time Exceeded) is sent back to the sender.

So for previous example, traceroute application will firstly set TTL to 1 to access http://www.yahoo.com, but because when pass 192.168.1.1 the value will reduced by one, become zero than, host 192.168.1.1 will send ICMP error datagram. The traceroute application will then know that next hop is 192.168.1.1. Again it’s now set TTL to 2, but after 10.53.128.1 TTL value become 0 but the IP is still not reach it’s final destination so 10.53.128.1 will send ICMP error datagram. Again and again traceroute application will increase TTL value and collect ICMP error datagram from each hop until the TTL value is big enough to reach final destination. The result is shown as traceroute log above.

Another issue, this traceroute application on UNIX platform need to access ICMP protocol which is only accessible by root (or any user with uid = 0). So, application traceroute mostly will run with setuid root active and can become a security hole. Don’t worry, normally current traceroute application is secure enough event with setuid flag root active.

For more information about ICMP please refer to RFC 792

Written by adywicaksono

October 5, 2007 at 4:10 pm

Posted in networking