LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 03-18-2008, 03:37 AM   #1
bittus
Member
 
Registered: Aug 2006
Posts: 153

Rep: Reputation: 15
Unhappy No outgoing mails (Hacking ???)


Hi,

I have a new prob on my Fedora8 + postfix 2.5.1 + amvisd + spam assassin.

The programs were running fine till today. Suddenly this morning Outlook Express reported
Quote:
Your server has unexpectedly terminated the connection. Possible causes for this include server problems, network problems, or a long period of inactivity. Account: 'xxxx', Server: 'mail.xxxxxxxxxxxx.com', Protocol: SMTP, Port: 25, Secure(SSL): No, Error Number: 0x800CCC0F
.

I checked the server and found :

Quote:
netstat -nap | grep :25

tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 8703/master
tcp 0 0 192.168.1.102:25 83.206.98.234:60702 SYN_RECV -
tcp 0 0 192.168.1.102:25 81.138.229.245:16653 SYN_RECV -
tcp 0 0 192.168.1.102:25 207.59.125.114:29091 SYN_RECV -
tcp 0 0 192.168.1.102:25 210.255.80.245:56388 SYN_RECV -
tcp 0 0 192.168.1.102:25 207.22.46.245:55428 SYN_RECV -
tcp 0 0 192.168.1.102:25 74.246.42.68:33994 SYN_RECV -
tcp 0 0 192.168.1.102:25 12.166.75.2:16819 SYN_RECV -
tcp 0 0 192.168.1.102:25 66.112.145.130:39063 SYN_RECV -
tcp 0 0 192.168.1.102:25 193.251.22.23:1687 SYN_RECV -
tcp 0 0 192.168.1.102:25 216.36.226.74:39997 SYN_RECV -
tcp 0 0 192.168.1.102:25 213.198.72.51:2133 SYN_RECV -
tcp 0 0 192.168.1.102:25 70.61.216.234:65141 SYN_RECV -
tcp 0 0 192.168.1.102:25 66.242.21.26:48407 SYN_RECV -
tcp 0 0 192.168.1.102:25 81.252.22.70:52485 SYN_RECV -
tcp 0 0 192.168.1.102:25 194.145.224.110:44424 SYN_RECV -
tcp 0 0 192.168.1.102:25 209.46.12.1:10829 SYN_RECV -
tcp 0 0 192.168.1.102:25 209.159.32.210:45610 SYN_RECV -
tcp 0 0 192.168.1.102:25 59.39.71.13:49851 SYN_RECV -
tcp 0 0 192.168.1.102:25 219.131.220.83:4356 SYN_RECV -
tcp 0 0 192.168.1.102:25 217.41.52.8:56667 SYN_RECV -
tcp 0 0 192.168.1.102:25 85.25.86.27:47778 SYN_RECV -
tcp 0 0 192.168.1.102:25 165.166.8.50:50429 SYN_RECV -
tcp 0 0 192.168.1.102:25 136.142.251.58:55860 SYN_RECV -
tcp 0 0 192.168.1.102:25 213.186.56.118:56126 SYN_RECV -
tcp 0 0 192.168.1.102:25 213.161.226.147:45825 SYN_RECV -
tcp 0 0 192.168.1.102:25 66.125.168.202:16886 SYN_RECV -
tcp 0 0 192.168.1.102:25 87.106.23.57:54452 SYN_RECV -
tcp 0 0 192.168.1.102:25 84.53.80.162:20216 SYN_RECV -
tcp 0 0 192.168.1.102:25 69.130.26.186:27249 SYN_RECV -
tcp 0 0 192.168.1.102:25 206.156.254.240:39297 SYN_RECV -
tcp 0 0 192.168.1.102:25 159.18.133.3:2956 SYN_RECV -
tcp 0 0 192.168.1.102:25 139.30.8.201:4384 SYN_RECV -
tcp 0 0 192.168.1.102:25 67.62.117.154:20620 SYN_RECV -
tcp 0 0 192.168.1.102:25 72.249.19.195:47055 SYN_RECV -
tcp 0 0 192.168.1.102:25 67.41.154.59:24119 SYN_RECV -
tcp 0 0 192.168.1.102:25 216.132.149.18:34888 SYN_RECV -
tcp 0 0 192.168.1.102:25 196.25.211.4:49634 SYN_RECV -
tcp 0 0 192.168.1.102:25 218.40.87.225:11776 SYN_RECV -
tcp 0 0 192.168.1.102:25 81.21.78.58:2430 SYN_RECV -
tcp 0 0 192.168.1.102:25 69.7.232.14:40575 SYN_RECV -
tcp 0 0 192.168.1.102:25 12.104.34.243:2389 SYN_RECV -
tcp 0 0 192.168.1.102:25 195.97.254.147:48425 SYN_RECV -
tcp 0 0 192.168.1.102:25 217.34.93.29:31750 SYN_RECV -
tcp 0 0 192.168.1.102:25 81.214.188.178:55466 SYN_RECV -
tcp 0 0 192.168.1.102:25 216.64.51.19:43326 SYN_RECV -
tcp 0 0 192.168.1.102:25 217.167.9.105:4367 SYN_RECV -
tcp 0 0 192.168.1.102:25 67.39.239.37:9145 SYN_RECV -
tcp 0 0 192.168.1.102:25 71.36.89.153:61018 SYN_RECV -
tcp 0 0 192.168.1.102:25 70.226.246.61:51277 SYN_RECV -
tcp 0 0 192.168.1.102:25 80.80.62.51:24626 SYN_RECV -
tcp 0 0 192.168.1.102:25 216.87.82.87:51935 SYN_RECV -
tcp 0 0 192.168.1.102:25 64.179.53.140:41656 SYN_RECV -
tcp 0 0 192.168.1.102:25 200.123.99.2:11863 SYN_RECV -
tcp 0 0 192.168.1.102:25 219.94.154.224:65029 ESTABLISHED 13452/smtpd
tcp 0 0 192.168.1.102:25 69.15.214.14:3462 TIME_WAIT -
tcp 0 0 192.168.1.102:25 64.80.97.220:46001 ESTABLISHED -
tcp 0 0 192.168.1.102:25 66.80.156.193:44794 TIME_WAIT -
tcp 0 44 192.168.1.102:25 69.36.172.241:59643 ESTABLISHED 13468/smtpd
tcp 0 0 192.168.1.102:25 85.189.63.215:40890 TIME_WAIT -
tcp 0 0 192.168.1.102:25 69.95.23.35:41264 TIME_WAIT -
tcp 0 0 192.168.1.102:25 67.52.58.194:53167 ESTABLISHED 12892/smtpd
tcp 0 0 192.168.1.102:25 204.3.153.190:56629 ESTABLISHED 12904/smtpd
tcp 0 0 192.168.1.102:25 64.22.230.200:13464 TIME_WAIT -
tcp 0 0 192.168.1.102:25 81.169.149.52:41302 ESTABLISHED -
.....................................
..................................
...............................

(The list continues like anything, cant paste it completely here)
I found that most of these are not valid systems. Is this a way of hacking?

The outgoing mails might go sometimes, but not always

Can anyone help me resolve this issue?

Thanks in advance
 
Old 03-18-2008, 04:12 AM   #2
jschiwal
LQ Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670
Does the server have SYN COOKIE protection enabled in the kernel?

A SYN attack is where a machine or a group of machines sent a SYN to initiate a connection with a spoofed source address. This is done repeatedly in an attempt to flood your input and use up resources with half open connections.

Also check the firewall logs for this server and your LAN's firewall or NAT router's logs if available.
 
Old 03-18-2008, 09:08 AM   #3
bittus
Member
 
Registered: Aug 2006
Posts: 153

Original Poster
Rep: Reputation: 15
I am not familiar about SYN COOKIE. How can I check it ? If not how can I enable it ?

About firewall, I am running iptables to limit ssh connections to a limited number of IPs.
 
Old 03-18-2008, 09:29 AM   #4
bittus
Member
 
Registered: Aug 2006
Posts: 153

Original Poster
Rep: Reputation: 15
Is there anyway that I can restrict postfix to accept connections only from valid domains ? This is the second time I am affected like this.



I searched for SYN cookies and found it enabled in Kernel.

Last edited by bittus; 03-18-2008 at 09:30 AM.
 
Old 03-18-2008, 07:23 PM   #5
jschiwal
LQ Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670
Syn cookie protection will time out connection attempts quickly once the number of connections reaches a certain amount.

Look in your kernels .config file to see if this option was set when your kernel was compiled. There is also a setting then to enable it.
Code:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
This would probably be done in a start up script.

More info:
http://cr.yp.to/syncookies.html

I'll let someone else deal with the postfix config question. You might want to use "whois" on the web to determine what blocks these IPs are coming from. If there is a large number from China or Russia and you don't do business there, you could block those addresses at the firewall. Then the mail may be stopped before reaching your mail server. For some countries this works well, but for others like Korea it doesn't. Korea and Japan are in the same block, so you would either need to block Japan as well or look at smaller sub-blocks of IP addresses.

This won't stop attacks from US hackers or compromised American computers. But when there is a simple partial solution, that can make life easier for you by eliminating a lot of the "background radiation". For example, if you use ssh to configure the server, using a different port will reduce the number of automated attacks from script kiddies and robots. ( You also want to disable root logins and use a control such as "AllowUsers" to further protect ssh, and use private/public key exchange instead of password logins ) The attacks that remain will be more serious and without so much noise, will stand out better and be more likely to get your attention.

Try to prevent IP protocol based attacks at the firewall level if possible. Let postfix deal with authentication controls and application level attacks.

---

I had skipped over what you said about iptables controlling ssh access. My example above was coincidently about SSH. I don't want to imply that you shouldn't use IP control of SSH at the firewall. You should also lock down the controls in /etc/ssh/sshd_config as well. Another layer in the onion. For example, suppose that a hacker gets access to another host on the LAN. An "AllowUsers" entry will prevent attacks from another user on the LAN.

Last edited by jschiwal; 03-18-2008 at 09:01 PM.
 
Old 03-18-2008, 09:10 PM   #6
bittus
Member
 
Registered: Aug 2006
Posts: 153

Original Poster
Rep: Reputation: 15
Thank you so much for that informative description. I appreciate your response.

Regarding configuration of firewall to block such attacks, I would like to get more info.

How can a firewall be configured to know if the smtp requests are genuine. Here in maillog, I can see requests coming from various ip addresses, trying to send mails to invalid users. As per my knowledge, only postfix can identify if a request if the incoming request is valid or not. That is why I asked how to tune postfix in such way.

Or can I configure firewall in such a way that smtp request from invalid hosts will be denied. Can we have a discussion on this ?
 
Old 03-18-2008, 09:45 PM   #7
jschiwal
LQ Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670
What I was suggesting is to totally deny access to your network from certain blocks of IP addresses. A domestic company that doesn't do business over seas won't be getting email or any traffic from Bangladesh. The port 25 connection attempt will be dropped then before it gets to the email server.

I think your problem is that you are getting a number of port 25 TCP SYN connection attempts. Your server replies with a SYN-ACK but the attacker doesn't send an ACK pack to complete the connection. My suggestion is to filter out all connection attempts from certain blocks of addresses. Most attacks come from US bots, Russia, China & Korea. You can block traffic coming directly from China easily because China is assigned one large block of IP addresses. Japan & Korea are assigned another range of IP addresses.

If 30% of the IP address fall in such a block, you can block all traffic from that block. This won't eliminate the problem completely but might reduce the number of SYN flood sources enough to allow mail to leave the server. Bogus spam traffic originating directly from these countries will be eliminated as well.

One thing to be sure you do is to check your configuration. Don't run an open relay mail server. If you do, you are helping spammers.

I don't have experience with the mail server part of the configuration or setting up a mail application filter or virus scanner.
Often bogus traffic from spam bots will insert a bogus initial source so the headers look like:
(bogus) mail server -> (bot) client -> isp mail server -> .. -> destination mail server -> recipient
instead of
(bot) client -> isp mail server -> .. -> destination isp mail server -> recipient
If the mail gets bounced it is sent back to the bogus mail server instead of the client. Your might be used as the bogus sender and you could be getting the bounce back.
This problem would be eliminated if ISPs would check the headers of the email being sent by their clients and match it against their clients IP address. They know both items. However, I think that you can do the same for e-mail being sent from computers on your own network. That would also alert you to a spam bot on your own network as well.

Last edited by jschiwal; 03-18-2008 at 09:48 PM.
 
Old 03-21-2008, 08:49 AM   #8
bittus
Member
 
Registered: Aug 2006
Posts: 153

Original Poster
Rep: Reputation: 15
Can anyone help me configure postfix, as I am not sure how to block requests before postfix. My main.cf file has these entries

Quote:
mynetworks = 192.168.0.0/24, 192.168.1.0/24, 127.0.0.0/8, ......... ....

smtpd_client_restrictions = permit_mynetworks, reject_unknown_client

smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_hostname

smtpd_recipient_restrictions = permit_mynetworks, reject_invalid_hostname, reject_unauth_pipelining, reject_unknown_client, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, permit_sasl_authenticated, reject_unauth_destination

smtpd_sender_restrictions = permit_mynetworks, reject_invalid_hostname, reject_unauth_pipelining, reject_unknown_client, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, reject_non_fqdn_sender

smtpd_helo_required = yes
disable_vrfy_command = yes
strict_rfc821_envelopes = yes
invalid_hostname_reject_code = 554
non_fqdn_reject_code = 554
relay_domains_reject_code = 554
unknown_client_reject_code = 554
Kindly help me, as my mail server is flooded with smtp requests. The output of netstat -nap | grep :25
Quote:
tcp 0 0 192.168.1.102:25 195.27.70.14:42779 ESTABLISHED -
tcp 0 0 192.168.1.102:25 64.56.103.102:39254 TIME_WAIT -
tcp 0 0 192.168.1.102:25 69.2.243.75:17074 ESTABLISHED -
tcp 0 0 192.168.1.102:25 71.246.61.71:33181 TIME_WAIT -
tcp 0 0 192.168.1.102:25 216.36.226.82:57804 TIME_WAIT -
tcp 0 0 192.168.1.102:25 216.240.12.14:12591 TIME_WAIT -
tcp 0 0 192.168.1.102:25 64.147.113.210:35082 ESTABLISHED -
tcp 0 0 192.168.1.102:25 205.214.225.82:43971 ESTABLISHED 28499/smtpd
tcp 0 0 192.168.1.102:25 193.206.15.70:53487 ESTABLISHED -
tcp 0 0 192.168.1.102:25 210.166.218.17:52721 ESTABLISHED -
tcp 0 44 192.168.1.102:25 82.223.162.192:60051 ESTABLISHED 28488/smtpd
tcp 0 0 192.168.1.102:25 216.194.67.41:50935 ESTABLISHED 28465/smtpd
tcp 0 0 192.168.1.102:25 198.252.182.53:44526 ESTABLISHED 28423/smtpd
tcp 0 44 192.168.1.102:25 128.180.2.160:39536 ESTABLISHED 28504/smtpd
tcp 0 0 192.168.1.102:25 212.67.202.192:58128 ESTABLISHED -
tcp 0 45 192.168.1.102:25 216.241.48.67:33985 LAST_ACK -
tcp 0 0 192.168.1.102:25 128.120.32.31:55860 ESTABLISHED 28382/smtpd
tcp 0 0 192.168.1.102:25 66.80.15.196:48658 TIME_WAIT -
tcp 0 0 192.168.1.102:25 76.241.172.185:36721 ESTABLISHED -
tcp 0 0 192.168.1.102:25 85.91.233.87:1599 ESTABLISHED -
tcp 1 0 192.168.1.102:25 85.176.97.184:4213 CLOSE_WAIT -
tcp 0 0 192.168.1.102:25 66.193.122.40:61000 ESTABLISHED 28430/smtpd
tcp 0 0 192.168.1.102:25 65.54.246.95:10180 ESTABLISHED -
tcp 0 0 192.168.1.102:25 99.135.222.210:14278 TIME_WAIT -
tcp 0 0 192.168.1.102:25 129.170.16.122:40300 ESTABLISHED 28456/smtpd
tcp 0 0 192.168.1.102:25 88.208.204.33:60070 ESTABLISHED -
tcp 0 0 192.168.1.102:25 12.149.175.17:21192 ESTABLISHED 28386/smtpd
tcp 0 0 192.168.1.102:25 64.26.0.101:49861 ESTABLISHED 28414/smtpd
tcp 0 0 192.168.1.102:25 66.193.122.40:36075 ESTABLISHED 28498/smtpd
tcp 0 0 192.168.1.102:25 12.23.28.40:1885 TIME_WAIT -
tcp 0 0 192.168.1.102:25 64.94.142.14:15006 TIME_WAIT -
tcp 0 0 192.168.1.102:25 203.122.239.206:36830 ESTABLISHED 28440/smtpd
tcp 0 0 192.168.1.102:25 162.21.255.77:25471 TIME_WAIT -
tcp 0 0 192.168.1.102:25 217.89.91.220:47779 ESTABLISHED -
tcp 0 0 192.168.1.102:25 70.87.59.98:42378 ESTABLISHED -
tcp 0 0 192.168.1.102:25 195.114.19.104:44004 ESTABLISHED -
tcp 0 0 192.168.1.102:25 208.186.169.145:39514 ESTABLISHED -
tcp 0 0 192.168.1.102:25 150.35.244.245:33243 ESTABLISHED -
tcp 0 0 192.168.1.102:25 67.135.51.115:37999 ESTABLISHED -
tcp 0 0 192.168.1.102:25 211.19.118.171:64838 ESTABLISHED 28403/smtpd
tcp 0 0 192.168.1.102:25 65.54.246.206:34266 ESTABLISHED -
tcp 0 0 192.168.1.102:25 64.139.129.61:2773 ESTABLISHED 28452/smtpd
tcp 0 0 192.168.1.102:25 89.248.104.84:57085 ESTABLISHED -
tcp 0 0 192.168.1.102:25 216.153.206.46:41188 ESTABLISHED -
tcp 1 0 192.168.1.102:25 124.104.157.22:3307 CLOSE_WAIT -
tcp 0 0 192.168.1.102:25 212.159.14.132:58591 ESTABLISHED -
tcp 0 0 192.168.1.102:25 210.188.227.179:2735 ESTABLISHED 28393/smtpd
tcp 0 0 192.168.1.102:25 66.193.122.40:35846 ESTABLISHED -
tcp 0 0 192.168.1.102:25 195.186.18.64:35057 ESTABLISHED -
tcp 0 0 192.168.1.102:25 70.167.192.20:17957 ESTABLISHED 28468/smtpd
tcp 0 0 192.168.1.102:25 66.113.130.254:53486 ESTABLISHED 28513/smtpd
tcp 0 0 192.168.1.102:25 206.166.96.95:49112 ESTABLISHED 28514/smtpd
tcp 0 0 192.168.1.102:25 64.41.120.21:42250 TIME_WAIT -
tcp 0 0 192.168.1.102:25 80.243.163.148:33173 ESTABLISHED -
tcp 0 0 192.168.1.102:25 207.109.252.222:53586 TIME_WAIT -
tcp 0 0 192.168.1.102:25 194.150.236.175:58939 ESTABLISHED -
tcp 0 0 192.168.1.102:25 213.199.20.6:7926 ESTABLISHED -
tcp 0 0 192.168.1.102:25 65.249.134.135:33324 ESTABLISHED -
tcp 0 0 192.168.1.102:25 212.200.12.199:41920 ESTABLISHED -
tcp 0 0 192.168.1.102:25 216.12.129.68:51837 TIME_WAIT -
tcp 0 0 192.168.1.102:25
.........................................
........................................
(The line count of this command varies from 300 to 400)

So you can imagine how much my server is panicking. Pls help me resolve this issue.

Thanks
 
Old 03-21-2008, 09:48 AM   #9
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,331
Blog Entries: 55

Rep: Reputation: 3529Reputation: 3529Reputation: 3529Reputation: 3529Reputation: 3529Reputation: 3529Reputation: 3529Reputation: 3529Reputation: 3529Reputation: 3529Reputation: 3529
First stop / kill your MTA. Then you need to reread post #7 and answer if you need the SMTP to be open to the 'net in the first place:
- If you don't run the MTA for a domain you are authoritative for then you probably don't need it to be accessable from the 'net in the first place and then blocking access through the firewall is the easiest solution.
- If you don't run the MTA for a domain you are authoritative for but your ISP or a third party requires an accessable MTA to deliver e-mail to then only allowing that subnet access through the firewall is still the easiest solution.
- If you run the MTA for a domain you are authoritative for (and you would know if you need to) then at least get to know what the configuration options do, require TLS, use access maps, smtpd_client_connection_*_limit(s), smtpd_*_error_limit(s), reject_rbl_client, reject_rhsbl_sender and use something like the iptables recent module. I don't use Postfix so the docs, http://www.postfix.org/uce.html and http://www.postfix.org/TUNING_README.html should be your first stop IMHO.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
logging outgoing mails in mailserver????? nics Linux - Server 17 01-01-2009 06:19 AM
How to take capy of all outgoing mails in send mail parashar_singh8086 Linux - Server 4 09-26-2007 03:28 AM
backing going up of outgoing mails in our mailserver??? nics Linux - Server 3 04-20-2007 12:48 AM
add header information to outgoing e-mails - postfix paul_mat Linux - Networking 1 05-16-2006 06:39 AM
outgoing mails are defered in mailq nayagam Linux - General 1 11-15-2002 09:51 AM


All times are GMT -5. The time now is 04:33 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration