Spam and iptables : COMPLETTE SOLUTION

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I DLIKE TO THATKS ALL MAILLIST USERS WHO 
REPLAY TO MY HELP AND GAVE ME USEFUL SOLUTION, 
SPECIALY FOR PAUL FOR GOOD IDEA.


Here is complette solution to stop spam attack, basend o my case:

Configuration follows:
Firewall uses NAT (iptables), have two eth, public and internal IPs (192.168.0.2).
Sendmail box have internal IP (192.168.0.3).

To prevent being open rely, you have remove from /etc/mail/access line where is IP of your
firewall. Only allowed is local IP RELAYs, example

192.168.0.0/24	RELAY		#here is for your local clients
192.168.0.2		REJECT		#here is for external clients (0.2 is firewall)

Now you have to modify iptables rules to forward packets from world to internal sendmail box!

----------------------------------------------
# OUTSIDE SMTP
CLIENT_IP="! 192.168.0.0/24"; GATEWAY_IP="public_ip_addr" ; GATEWAY_PORT="25" ;
SMTP_IP="192.168.0.3" ; SMTP_PORT="25"
iptables -t nat -I PREROUTING -p tcp -s $CLIENT_IP -d $GATEWAY_IP --destination-port $GATEWAY_PORT
-j DNAT \
        --to-destination $SMTP_IP:$SMTP_PORT

--------------------------------------------------------
(DONT USE SNAT BECAUSE YOU WILL NOT ABLE SEE REAL IP, BUT IF YOU USE SNAT YOU CAN SKIP DNS
CONFIGURATION)

After this external packets are forwarded to sendmail box (192.168.0.3), now you have to edit
/etc/named.conf and add zones:

________________________________________________________--
view internal_net {
        match-clients { insiders; localhost; };
        recursion       yes;

        zone "." IN {
                type hint;
                file "int-named.ca";
        };

        zone "my.zone.com"{
                type master;
                file "int-my.zone.com";
                notify no;
        };

        zone "0.0.127.in-addr.arpa" IN {
                type master;
                file "int-127.0.0";
                notify no;
        };

        zone "0.168.192.IN-ADDR.ARPA"{
                type master;
                file "int-192.168.0";
                notify no;
        };
};

________________________________________________
...to run an internal DNS server which knows the real (internal) IP address of your public web
site, and forward all other requests to an external DNS server. This means that the logging on
your web server will show the internal IP addresses correctly.
(http://www.iptables.org/documentation/HOWTO//NAT-HOWTO-10.html)

Now, external and internal users are able to connect to 192.168.0.3:25.

Next, sit down and wath who spams you.

$tail -f /var/mail/maillog | grep "reject=550" >spamers

After while you have real IP of evil users.

Now, you have to modify iptables Rules to that:

---------------------------------
$IPTABLES -I FORWARD -s IP_OF_EVIL_SPAMER -j DROP
----------------------------------------

You have to remeber that packet are forwarded, INPUT is not used!

Now You have selected, and DROPed all spamers, its time to enable remote users to recevie/send
their mail, use POP-before-SMTP (www.sendmail.org) or Dynami Relay Authorization,
(http://mail.cc.umanitoba.ca/drac/index.html).

Thats all.





--- Paul Bryan <pa_bryan@yahoo.co.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > NO! I cant do it base to fundamental rules of TCP/IP protocol. I will
> > explain it. Let have external box 'A', firewall 'B', and sendmail box 'C'.
> > Now if A send IP packet to B is have src=A dst=B, now B receive this packet
> > and change it to src=B dst=C. IF (as you want to) B would not change this
> > and leave it as src=A dst=C, then packet will arrive to C, but never will
> > be send back to A, because sequnce number of TCPIP protocol is different in
> > B and C, and simply A will reject packets form C, due to
> > Man-In-Middle-Attack rules. So in this configuration must be like is.
> > Secont, will not be received because of C is private IP, and for third, B
> > will not pass throuw packets from C to A. Read the SNAT and DNAT rules of
> > IPTABLES again. :)
> 
> Hmmm... I believe Gauntlet can do this. Where I work, I don't have any 
> control over the main firewall, but I look after the web servers. We 
> requested that connections to the web server's shouldn't have the src address 
> re-written to the firewall's. This was for information gathering reasons. No 
> problem - it's been running okay for a while now.
> 
> Actually, the more I think about it, at home this is exactly how things work 
> on my network. I have port 80 on my firewall forwarded to my web server. The 
> web server sees the client address and not the address of the firewall. This 
> is using iptables. The rule is:
> 
> iptables -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to 
> xxx.xxx.xxx.xxx:80
> 
> netstat on the web server reports the client address and not the firewall's 
> address. You may want to check things to see if and why you get different 
> results.
> 
> As far as I can tell, this is because the firewall box forwards the packets 
> on transperantly so any sequence numbers are maintained.
> 
> > There is another way. It is highly tricky. Make on firewall rules that
> > alter TCPIP flag of that packet which is allowed to go to sendmail. Now
> > sendmail box will have iptables rule located in PREROUTE and simpy DROP all
> > packets without flag altered.
> 
> That sounds very bad! I'm not sure you'd actually be able to get that 
> working. If you do, I'd like to see what you've done.
> 
> - -- 
> Paul Bryan
> pa_bryan@yahoo.co.uk
> 
> PGP Key
> http://www.keyserver.net:11371/pks/lookup?op=get&search=0xB1D405DA
> 
> Ah, this is obviously some strange usage of the word safe that I wasn't 
> previously aware of.
>   Arthur Dent, "Hitch Hikers Guide to the Galaxy"
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE+O7J43qGyTLHUBdoRAtKzAJ4mXUgb6D2jvoCVmH8UyqJugPgt1gCgv2sP
> JS7cHG5komJMCQqS/Sx/490=
> =mSGr
> -----END PGP SIGNATURE-----

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
------------------------------------------------------------------------
     To unsubscribe email security-discuss-request@linuxsecurity.com
         with "unsubscribe" in the subject of the message.


[Index of Archives]     [Fedora Announce]     [Linux Crypto]     [Kernel]     [Netfilter]     [Bugtraq]     [USB]     [Fedora Security]

  Powered by Linux