Linux - NewbieThis 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!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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
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
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.
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.
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 ?
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
(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.
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.