yurisk.info

awk weekly – Checkpoint Anti Spam statistics or viva la Open Relays

Yuri — Mon, 08 Mar 2010 20:56:38 +0000

Goooood day everyone again,
today I have had another fight with the spam cartel that my client fell victim of. Once upon a time there was not so powerful UTM providing internet to not so crowded office in not so security-aware Central Europe.
All would be good and well if not this problem – they could not send emails outside as the IP of the firewall entered every imaginable blacklist on the Earth. Hmm, but the firewall has AntiSpam subscription service up and running.
LAN is blocked on port 25 outbound except the Exchange. Antivirus is everywhere so low chance of spam coming from LAN. In SmartView Tracker lots of SMTP rule logs in red – spam entering Exchange is blocked .

So what the …? tcpdump with -w option for 5 minutes was all I needed to see that Exchange was open relay and kindly offered to relay spam from everyone to everywhere.
To really measure the impact of the event I had to have some statistics and Checkpoint didn’t help me much with that , eventhough this UTM has also SmartView Monitor license it is not suited for the task. So I exported fw.log on the UTM into text human-awk-readable format , that took some 40 mins on 300 Mb log file and produced text file of 475 Mb, and then did whatever I wanted with the data using awk.
Now get some action:
Script 1 – Find all mails rejected in direction from LAN (interface Internal, remember it is UTM) to the Internet (interface External) , then gather statistics of how many mails came from what ip [less relevant here as all mails come from Exchnage, but in environment where hosts send mails directly outside it is] and show us :

# awk -F\; ‘/Internal to External/ && /reject/ {print $2}’ ./fw.log.txt | awk ‘ {match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/,IP); IPS[IP[0]]++ } END { for (spammer_ips in IPS) print spammer_ips ” ” IPS[spammer_ips]}’ | sort -n -k2,2

192.168.14.12  402804

Yahooooo! In the timeframe of 28 hours there were blocked 402804 mails as spam coming from Exchange!
Not bad at all – all this without any malware installed on the client side [my educated by Wireshark guess here as I dont have access to the Exchange],just amazing!

Now let’s have a look at overal number of mails that was accepted and sent outside to the Internet :
Script 2 – Find all mails accepted in direction from LAN (interface Internal) to the Internet (interface External) , then gather statistics of how many mails came from what ip and show us :

# awk -F\; ‘/Internal to External/ && /accept/ {print $2}’ ./fw.log.txt | awk ‘ {match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/,IP); IPS[IP[0]]++ } END { for (spammer_ips in IPS) print spammer_ips ” ” IPS[spammer_ips]}’ | sort -n -k2,2
192.168.14.12 257940

Wow! in addition to 402804 mails blocked by Checkpoint firewall as spam 257940 mails were sent out as clean, given that this is a very small office hardly sending 300 mails a day we get ratio of 39% spam passing through the Checkpoint Antispam , pity . Antispam blocking rate of 61% ? In 21st century ? Wake up !

Just for statistics I also calculated how many spam emails were blocked from outside inbound:
Script 3 – gather how many mails from outside coming in were rejected by Checkpoint as spam.

# awk -F\; ‘/External to Internal/ && /reject/ {print $2}’ ./fw.log.txt | wc

#    5593   11186  112648

So only 5593 incoming spam emails and almost half a million outgoing ones – that’s what I call effectiveness.
Script 4 – gather statistics on blocked emails and IPs it came from:

# awk -F\; ‘/External to Internal/ && /reject/ {print $2}’ ./fw.log.txt | awk ‘ {match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/,IP); IPS[IP[0]]++ } END { for (spam_ips in IPS) print spam_ips ” ” IPS[spam_ips]}’ | sort -n -k2,2

And here are some results:

93.81.26.2  75
91.121.114.1  81
220.168.57.1  87
58.9.205.2  129
122.102.101.1  149
58.137.99.7  160
189.35.231.6  189
60.248.174.6  631

PS I know Checkpoint folks visit here , so if you think I get some data wrong – don’t be shy to correct me,all fixes are gladly welcome.

Abra – the new toy from the Checkpoint

Yuri — Wed, 03 Mar 2010 20:39:20 +0000

Checkpoint announced availability (for inquiries yet) of their new project Abra – secured virtualized desktop solution. I myself haven’t seen nor tried this so can only judge from different sources. In essence we talk here about USB stick of approx. 5 Gb or 8 Gb that includes virtual image of the applications you need to do the work and optionally to connect securely to your workplace (to the Checkpoint gateway of course).
The testing (I know of) was done on their own employees that were given those Abra-sticks to work from home.
The way it works is pretty simple – you have encrypted (so they say) virtual desktop environment on stick ,
which you connect to any PC and upon entering user/pass can work using pre-installed and pre-configured
software on it . The sticks that Checkpoint gave to their workers contained Windows XP with set of usual software – browser, Microsoft Office etc. , also VPN client .
In short nothing new on the market except encryption – do a search on Virtual desktop infrastructure and you’ll get the idea. What interesting here is how they are planning to integrate this new buzz-project with all the rest of their line. Because otherwise it isn’t even worth trying to market it (put on USB VMware Player with windows XP and you get the same but without encryption).
The webpage from the CP is here:
Check Point Abra | Check Point Software
To see what people think about that you may go here:
CPUG.ORG discussion on Abra
If you have Partner level access to the Checkpoint site you may hear the Webcast presenting the Abra for the first time:
webcast archives
NOTE: see the comments for a more correct (than mine) view of this new product

Cisco IPS sensor – initial setup

Yuri — Sun, 28 Feb 2010 16:05:30 +0000

Hello everyone. As I proceed in my studies towards the CCIE Security lab I’m starting a new category on the site – Cisco IPS. I will be posting all the things I learn about this gear, even the basics as I noted that on the Internet Cisco IPS sensors
are not much talked about and while not sure why this is so, I’ll try to fill the gap.

Initial Configuration.
By default , out of the box the sensor has the following defaults:

Management IP: 10.1.9.201/24
Default gateway: 10.1.9.1 Allowed access: from the network 10.1.9.201/24
Telnet access: disabled
HTTPS: port 443

As most likely your network has different network address the first thing to do is change management IP, default gateway and allowed management access network(s)/IP. You do so by connecting with console to it .
You can configure these basic network settings in 2 ways: enter all the configuration commands on CLI (if you know them) or run interactive menu-type setup by issuing on the CLI: #setup . I’ll show both ways but let’s start with the setup menu.
A short remark – IPS sensor is the one of not so many devices in the Cisco family that configuring/managing/communicating with it using its GUI interface is the recommended and preferred way . It is much more intuitive, simple, produces the very same configuration at the device as done in CLI. The only time you may need to do stuff with CLI is initial setup and debug.

Configuring minimal required settings through setup menu:

Connect to the device by terminal
enter default user/password: cisco/cisco (or see the documentation coming with the device);
run:
sensor# setup

- First you are presented with the whole configuration currently set, just hit Space key until it reaches the end and asks whether you want to enter the setup dialog , print yes and Enter:

Continue with configuration dialog?[yes]:
Enter host name[sensor]: IPS4235  Here I set hostname to IPS4235
Enter IP interface[10.1.9.201/24,10.1.9.1]: 10.0.0.33/24,10.0.0.254   Pay attention to the syntax of specifying the management IP its subnet mask and default gateway
Enter telnet-server status[disabled]: enable     I say yes here but you are advised to say no on production devices
Enter web-server port[443]:         Default https listening port
Modify current access list?[no]: yes
Current access list entries:
  No entries
Permit: 10.0.0.100/32                 I allow management access to the device form this specific station 
Permit:                       Hit Enter to move to the next menu item
Modify system clock settings?[no]: no
Modify summer time settings?[no]: no
Modify system timezone?[no]: no
Modify interface/virtual sensor configuration?[no]: no
Modify default threat prevention settings?[no]:
------cut here------------
exit exit

Upon finishing all the menu items in the dialog you are presented with the configuration you just entered :

The following configuration was entered.
service host
network-settings
host-ip 10.0.0.33/24,10.0.0.254
host-name IPS4235
telnet-option enabled
access-list 10.0.0.100/32
ftp-timeout 300
no login-banner-text
exit
time-zone-settings
exit
summertime-option disabled
ntp-option disabled
exit
service web-server port 443

At the end of the output you are given the following choices:

[0] Go to the command prompt without saving this config.
[1] Return back to the setup without saving this config.
[2] Save this configuration and exit setup.
 Enter your selection[2]:   2

Then device asks to reboot in order for the changes to take effect – confirm that.
After reboot you may enter the sensor using supported browser by the management IP: https://10.0.0.33
Also make sure the station you are connecting from has Java virtual machine installed as the GUI is entirely based on it.

awk weekly – how to see Checkpoint logs on command line

Yuri — Fri, 26 Feb 2010 20:12:57 +0000

Hey Everyone, I decided to start a weekly column of awk scripting where I will bring interesting (I am being subjective I know) short scripts that made my life easier in dealing with actual problems in the wild or just look cool.

Until recently I had never had any need to work with Checkpoint log files without SmartView Tracker , namely on the command line. But there is always first time . Client complained on some dropped mail traffic and to even say if there is any problem or not I had to look at relevant logs, not a big deal except that I had only ssh access to the firewall . Checkpoint provided for such cases fw log command line log extracting utility that reads the binary log file ( fw.log by default) you feed in and outputs it in human-readable format. That’s good, but its filtering possibilities are quite bad . You can see all available options with fw log –h , but selection is limited to source, start/end time,action (drop/reject/etc) . Not that much to say the least . No port/direction filtering . And specifically it was a very busy firewall – some 80 mbytes of traffic passing through at any given moment and log is the default action on any rule. So using fw log filters would help me not.
Here is how I solved this with the help of awk – I exported to text format all logs using

# fw log -n> fw_log.txt &

Note –n option to fw log here – it prevents resolving IP/ports to names , shortens processing time by ~70%
Then I just used all-powerful awk to search the text file to show the client what was the reason (Exchange in LAN was sending heaps of spam that Anti-Spam stopped at its best but nevertheless some spam leaked and caused RBL blocking of the external firewall IP) :

[Expert@Orlean] # awk ‘/Anti Spam/ && /Internal to External/’ fw_log.txt | awk -F: ‘ {print $5 $6}’

192.168.143.12; dst 65.55.37.88; proto
192.168.143.12; dst 65.55.92.136; proto
192.168.143.12; dst 65.55.92.136; proto
192.168.143.12; dst 203.216.247.184; proto

Here:
External, Internal – UTM interface names and direction of the Anti-Spam scanning
NOTE: exporting logs from binary to text takes a bit of time, depends on situation. Enabling name resolving sky-rocketed the processing time to 15 minutes , but on the other hand gave some additional insight :

Exchange; dst col0-mc2-f.col0.hotmail.com; proto
Exchange; dst mx1.hotmail.com; proto
Exchange; dst mx1.hotmail.com; proto
Exchange; dst mta19.mail.vip.tnz.yahoo.co.jp; proto
Exchange; dst bay0-mc2-f.bay0.hotmail.com; proto
Exchange; dst mx3.hotmail.com; proto

Difference between ebgp-multihop and ttl-security.

Yuri — Fri, 26 Feb 2010 18:39:12 +0000

Once upon a time reading some CCIE paper at work I asked myself a question : “Why would someone bother to invent ttl-security and even write RFC http://tools.ietf.org/html/rfc5082 on it when multi-hop EBGP feature provides the same end result ?” .
The results of my busy/doing-nothing activity I present here.
First some background. For some (unknown to me) reasons BGP peering was envisioned as TCP connection between directly connected routers, by default. To proceed with this design (worth checking BGP RFCs if it was actually an obligation) vendors (Cisco,Juniper and even Fortinet) implemented all BGP protocol communication using TTL=1 in TCP packets being exchanged. As the logical consequence of this if a router was placed more than 1 hop away from its peer BGP session could not be established. To provide for such set ups when peers are many hops away the ebgp-multihop term was coined – on configuration level you can specify that BGP peer is that hops far away .
What happens in fact is that when you specify such multi-hop BGP peer the router starts sending BGP packets with TTL being equal to the number of hops you set . That means if I set peer to be 3 hops away and some attacker tries to spoof legit peer’s IP but is 4 hops away – such attack won’t succeed cause my router will receive spoofed BGP packets ok but will send replies with TTL of 3 which will expire just 1 hop away from the attacker.
Questionable , but security . So why ttl security?
This feature indeed enforces that BGP peer is no more than given hops away . And here comes the difference – it enforces it inbound . It works this way – after you enable ttl security on the BGP peer session and specify how many hops away this peer is allowed to be, your router
checks incoming TCP packets from this peer and does this simple calculation : configured value <= 255 – hops-away-to-peer , if it holds true your router goes on with establishing BGP session , if not – session is shut down. Regarding outgoing TTL values – may be it is Cisco-only thing, may be not , but the moment you enable ttl security for some BGP peer on Cisco the router itself starts sending BGP-related packets to this peer with initial ttl being equal to 255. I guess it is logical that if you enforce on your side ttl security the peering side will want to do the same.

When ttl rule is broken we see in the debug session:
Dec 27 19:08:04.103: %BGP-4-INCORRECT_TTL: Discarded message with TTL 1 from 124.2.11.15
And neighbor status is:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
124.2.11.15 4 13462 33 63 0 0 0 00:04:31 Idle

#sh ip bgp neighbors 124.2.11.15
BGP neighbor is 124.2.11.15, remote AS 13462, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Closing

VPN client stops working in visitor mode after major update

Yuri — Thu, 25 Feb 2010 10:10:35 +0000

Yesterday I got asked to check the VPN client issue . After upgrade from NGX R65 to R70 VPN client doesn’t connect when Visitor mode is enabled . The moment you disable Visitor mode the same client to the same firewall works just fine. This happens
often so I bring it here . Actually I see it as the “it is a feature not a bug’ case -
after major upgrades to the firewall, the Management WebGUI (the one you use after fresh install to run the wizard) listening port will be reset to its default value of 443. This in turn prevents any other daemon/service listening on this port , so Visitor mode (I guess also SSL Extender) will not work.
To fix it you just change listening port for WebGUI. Now lets get to SSH:
To see the problem:

#lsof -i -n | grep https

cp_http_s 1864 nobody 11u IPv4 14977 TCP *:https (LISTEN)

To fix the problem:

#[Expert@fw]# webui disable

Shutting down cp_http_server_wd: [ OK ]

[Expert@fw]# webui enable 4445

Running cp_http_server_wd: [ OK ]

Now WebGUI wil be listening on port 4445 , and vpnd as should will be listening on 443:

[Expert@fw]# lsof -i -n | awk ‘/https/ || /4445/’

vpnd 3564 root 26u IPv4 29060053 TCP *:https (LISTEN)
cp_http_s 10300 nobody 5u IPv4 29100889 TCP *:4445 (LISTEN)

fw monitor add-on

Yuri — Sat, 13 Feb 2010 17:12:00 +0000

There is something I didn’t include in the previous post fw monitor command reference about fw monitor as I think it is rather optional and you can do well without it . I talk about tables in defining filter expressions. INSPECT – proprietary scripting language by the Checkpoint on which filtering expressions are based allows creating tables.
I won’t delve into INSPECT syntax (for today) but will list the following examples you can easily modify to suit your needs.

Legend:
{} – delimit the table
<,> – specify range of values inside (e.g. <22,25> means from 22 up to 25 inclusive)
ifid – interface identifier

#fw monitor -e “bad_ports = static {22,25,443}; accept dport in bad_ports;” packets with destination port being equal to 22,25 or 443
#fw monitor -e ” bad_ports = static {<22,25>} ; accept dport in bad_ports;” packets with destination ports being equal to 22,23,24 or 25
# fw monitor -e ” bad_ports = static {<22,25>,<80,443>} ; accept dport in bad_ports;” packets with destination ports being in ranges 22-25 or 80-443
#fw monitor -e “bad_nets = static {<194.1.0.0,194.1.255.255>} ;accept src in bad_nets;” packets originated in range of networks 194.1.0.0 – 194.1.255.255
#fw ctl iflist Here I see what are the index values of each interface card
0 : Internal
1 : External
#fw monitor -e “bad_nets = static {<194.1.0.0,194.1.255.255>} ;accept src in bad_nets and ifid=0;” packets originated in range of networks 194.1.0.0 – 194.1.255.255 and captured on interface eth3 only

Fortigate firewall demo free access. Also FortiManager and FortiAnalyzer

Yuri — Wed, 03 Feb 2010 18:37:25 +0000

As someone said best things in life are free.
Here are links to the demo Forigate firewall, ForiAnalyzer and FortiManager open to access from anywhere . So that you can
familiarize yourself with the Management GUI look and feel.
NOTE: Access is read-only.
NOTE 2: No , it is not me being so generous, it’s Fortinet caring for us.
Fortigate 300 :
user:demo
password: fortigate
fortigate.com
ForiAnalyzer 800:
user:demo
password: fortianalyzer
fortianalyzer.com
FortiManager 400:
user:demo
password: fortimanager
fortimanager.com

Mail alert on ssh login or any other rule hit in Checkpoint

Yuri — Mon, 01 Feb 2010 10:56:36 +0000

I once SSH login alert presented the way to send mail alert after successful login by ssh to any Linux-based machine , including Checkpoint firewalls. Now, thanks to folks at cpug.org that draw my attention to it, I will show how to get mail Alert on ANY rule in the security rulebase of the firewall, and also simplified script using Checkpoint version Of the sendmail.
First , rules alerts – on any rule in the Security Rulebase you can set in its Track column to Mail . Now all hits
On such rule will be sending mail alerts tp specified recipient(s) through the specified mail server (Checkpoint doesn’t have a mail server of its own) . So, if you create rule that allows access by SSH you can set in Track Mail and each time this rule is used to access the firewall mail will be sent. Now how to configure mail server settings, you do it in
Policy -> Global Properties -> Log and Alert -> Alert Commands , check ” Send mail alert to SmartviewView Monitor” and “Run mail alert script” . In the “Run mail alert script” field set to the string of form:

internal_sendmail -s [subject of the mail] -t [ip of mail server to receive mail goes here] -f [from_who_field_in_mail] [to_whom_send_this_mail]
e.g. internal_sendmail -s SSH_login_alert -t 63.161.169.140 -f yurisk@yurisk.info president@whitehouse.gov

The mail you get on such alert looks like:

6Jan2010  7:29:55 accept fw-tokyo  >External mail rule: 2; rule_uid: {85A905A7-951E-4100-A23A-E280FAAA1D29}; SmartDefense profile: Default_Protection; service_id: ssh; src: my-management-host; dst: fw-tokyo  ; proto: tcp; product: VPN-1 & FireWall-1; service: ssh; s_port: 47145;

Capture packets at IOS Cisco router or finally we have a sniffer

Yuri — Mon, 01 Feb 2010 07:33:06 +0000

Finally it is here – built-in sniffer on the Cisco IOS platform ! Starting IOS 12.4(20) release Cisco introduces brand new feature
called Embedded Packet Capture (EPC) that allows us to capture raw packets on the Cisco router and then later analyze it offline.
It can capture any traffic passing through the router, destined to it, or originated from it . The captured packets are stored in DRAM
of the router from where you can upload the capture file using HTTP/SCP/HTTPS/TFTP/FTP anywhere and then dissect it. The capture
is stored using PCAP format , so any protocol dissector will understand this file, including the favorite one WIreshark/Ethereal.
Now some limitations:
– CEF has to be enabled on the router;
– The capture is stored in the DRAM , so you’d better have enough of it;
– While no maximum capture buffer or packet size is stated I guess it depends on the platform (see tests below);
– IOS has to be 12.4(20) or higher.
Let’s now look at steps to configure the capture on the router and then look at the results.
Configuration involves 5 steps:

Create named capture buffer in router memory (including filters what to capture and what not to). Multiple buffers simultaneously are supported;
Create named capture point , again, multiple capture points active at the same time are possible. Using multiple capture buffers and capture points gives us full flexibility in the process – I can say capture packets at the same time inbound on incoming interface and
store it to the memory buffer A while the same traffic going outbound on outgoing interface capture to another buffer B and have this
way capture of the same traffic at 2 distinct points on the router. Your imagination is the limit here.
Associate capture buffers with capture points;
Start/stop capture;
Export captured packets as PCAP file elsewhere or see it in raw format on the router itself (in case binary is your first language).

Now I will walk through configuring,all this is being done on Cisco 2821 (250 Mb of DRAM). IOS is being Cisco IOS Software, 2800 Software (C2800NM-IPBASEK9-M), Version 12.4(24)T1, RELEASE SOFTWARE (fc3)
1) Create named capture buffer in memory. Packets are stored there, as this is DRAM storage if router does restart all capture data will be lost. You also specify filter for which packets are to be captured , if none given it will capture ALL packets at the
capture point. Not surprisingly for filtering you use access-lists, standard or extended, named or numbered.

In my testing I am trying to capture all SMTP traffic passing through the interface Giga0/1. Accordingly the ACL for it will be:

Eldorado(config)#ip access-list extended MAIL_TEST
Eldorado (config-ext-nacl)# permit tcp any any eq smtp

Now I create capture buffer in the memory:

Eldorado #monitor capture buffer MAIL filter access-list MAIL_TEST

NOTE: Fo the particular platform (cisco 2821) the limits and defaults for the buffer are these:

Eldorado#monitor capture buffer MAIL size ?
<1-512> Buffer size in Kbytes : 512K or less (default is 256K)

NOTE 2: In Cisco.com documentation this and other commands related to capture have options that trying to use them gave error.
For example Command reference gives option to configure length of the packet to be captured (instead of default 68 bytes) :

Eldorado #monitor capture buffer MAIL length
^
% Invalid input detected at ‘^’ marker.

2) Creating capture point (i.e. where to capture packets on the router):

Eldorado# monitor capture point ip cef GIGA GigabitEthernet0/1 both

Here I specify interface GigabitEthernet0/1 as point of capture and also set that traffic is to be captured in both directions (or you can use in/out instead)

3) Associate capture buffer with capture point (it does not start capture yet):

Eldorado#monitor capture point associate GIGA MAIL

4) Start capturing packets:

Eldorado#monitor capture point start GIGA

4.1)Stop capture (optional) , you can export capture in the next step without stopping it:

Eldorado# monitor capture point stop GIGA

5) Export captured packets as file to external server , here I use SCP as protocol:

Eldorado#monitor capture buffer MAIL export scp://rumba@216.163.142.1:/capture.cap

Writing capture.cap
Password:
Sink: C0644 309346 capture.cap
!!
Eldorado#

- Now you can see the capture file with Wireshark .
There is it to it.

Verifying.
– To see parameters of the capture:

Eldorado#show monitor capture buffer all parameters

 Capture buffer size (linear buffer)
Buffer Size : 262144 bytes, Max Element Size : 68 bytes, Packets : 0
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Configuration:
monitor capture buffer siz
Capture buffer MAIL (circular buffer)
Buffer Size : 512000 bytes, Max Element Size : 1024 bytes, Packets : 363
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Name : GIGA, Status : Inactive
Configuration:
monitor capture buffer MAIL size 500 max-size 1024 circular
monitor capture point associate GIGA MAIL
monitor capture buffer MAIL filter access-list MAIL_TEST
Eldorado#

- Seeing contents of the captured packets on the router :

# show monitor capture buffer MAIL dump

08:18:59.995 UTC Jan 25 2010 : IPv4 LES CEF    : Gi0/1 None

45514C50:                            002414F7              .$.w
45514C60: 2723001F 9E4cd37F 03e4cda dd379aaa  'A...F&...E..0W.
45514C70: dd379aaa dd379aaa  dd379aaa dd379aaa @.-.Eב#X.3,,.M%
45514C80: 03e4cda 03e4cda 03e4cda  03e4cda  ../..&....s@yh
45514C90: 00000204 23ee3444 000000             .....d.....

08:19:00.699 UTC Jan 25 2010 : IPv4 LES CEF    : Gi0/1 None

45514C50:                            002414F7              .$.w
45514C60: 03e4cda 03e4cda 03e4cda 03e4cda 'A...F&...E..KYj
45514C70: 03e4cda 03e4cda 03e4cda 03e4cda @.-.#4$f.%%
45514C80: 03e4cda 03e4cda 03e4cda 03e4cda../..'|S^^^0])
45514C90: 03e4cda 03e4cda 03e4cda 03e4cda..EHLO smtp02.bi
45514CA0: 03e4cda 03e4cda 03e4cda 03e4cda s.eu.blackberry.
45514CB0: 636F6D0D 0A00                        com...