Archive for the ‘networking’ Category
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
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
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.
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
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 [18.104.22.168] 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 22.214.171.124 7 20 ms 16 ms 24 ms 126.96.36.199 8 232 ms 237 ms 230 ms so-4-0-0.edge2.LosAngeles1.Level3.net [188.8.131.52] 9 233 ms 232 ms 230 ms ae-2-54.bbr2.LosAngeles1.Level3.net [184.108.40.206] 10 237 ms 229 ms 232 ms ae-0-0.bbr1.SanJose1.Level3.net [220.127.116.11] 11 316 ms 230 ms 426 ms ae-13-69.car3.SanJose1.Level3.net [18.104.22.168] 12 386 ms 402 ms 400 ms 22.214.171.124 13 283 ms 294 ms 287 ms so-0-0-0.pat2.dcp.yahoo.com [126.96.36.199] 14 292 ms 295 ms 289 ms ge-3-1-0-p171.msr2.re1.yahoo.com [188.8.131.52] 15 288 ms 291 ms 293 ms gi1-22.bas-a1.re3.yahoo.com [184.108.40.206] 16 285 ms 286 ms 286 ms f1.www.vip.re3.yahoo.com [220.127.116.11]
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