?
Solved

IP Tables port blocking

Posted on 2009-07-01
15
Medium Priority
?
377 Views
Last Modified: 2013-11-16
I am trying to block all connections to the MySQL port 3306 on our server besides connections from one IP address.  I managed to black all the traffic using the rule below through webmin on our server

Reject If protocol is TCP and destination port is 3306

I've also added the rule

Accept If protocol is TCP and source is 88.208.221.101 and destination port is 3306

However no matter which rule is first in the list it will not allow the specified server to connect.
0
Comment
Question by:albyh
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 7
  • 6
  • 2
15 Comments
 
LVL 16

Expert Comment

by:Blaz
ID: 24752976
The rules should work if the rule "... and source is 88.208.221.101 ..." is first in the list. Did you restart iptables after changing rule order?

Otherwise you could try with a single rule:
Reject If protocol is TCP and source is not 88.208.221.101 and destination port is 3306
0
 

Author Comment

by:albyh
ID: 24753186
Yes i restarted the IP tables and it made no difference.

I've just tried setting up the rule

Reject If protocol is TCP and source is not 88.208.221.101 and destination port is 3306

but unfortunately that doesnt work either
0
 
LVL 16

Expert Comment

by:Blaz
ID: 24753237
Could you post all your current rules?

Either from webmin interface (a copy/paste or screenshot) or better in terminal issue command:
/sbin/iptables -L -nvx
0
Put Machine Learning to Work--Protect Your Clients

Machine learning means Smarter Cybersecurity™ Solutions.
As technology continues to advance, managing and analyzing massive data sets just can’t be accomplished by humans alone. It requires huge amounts of memory and storage, as well as the high-speed power of the cloud.

 

Author Comment

by:albyh
ID: 24753280
Chain INPUT (policy ACCEPT 121 packets, 11462 bytes)
    pkts      bytes target     prot opt in     out     source               destination        
     121    11462 PORTSEN    all  --  *      *       0.0.0.0/0            0.0.0.0/0          
       0        0 ACCEPT     tcp  --  *      *       88.208.221.101       0.0.0.0/0           tcp dpt:3306
       0        0 REJECT     tcp  --  *      *      !88.208.221.101       0.0.0.0/0           tcp dpt:3306 reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination        

Chain OUTPUT (policy ACCEPT 153 packets, 138487 bytes)
    pkts      bytes target     prot opt in     out     source               destination        

Chain PORTSEN (1 references)
    pkts      bytes target     prot opt in     out     source               destination        
       0        0 DROP       all  --  *      *       59.56.111.79         0.0.0.0/0          
       0        0 LOG        all  --  *      *       59.56.111.79         0.0.0.0/0           LOG flags 0 level 4 prefix `portsentry attack alert'
       0        0 DROP       all  --  *      *       205.209.161.228      0.0.0.0/0          
       0        0 LOG        all  --  *      *       205.209.161.228      0.0.0.0/0           LOG flags 0 level 4 prefix `portsentry attack alert'
0
 
LVL 16

Expert Comment

by:Blaz
ID: 24753411
By the look of the counters it seems that all the packets were accepted by the firewall

121    11462 PORTSEN    all  --  *      *       0.0.0.0/0            0.0.0.0/0          

121 packets (and 11462 bytes) were received by INPUT chain for processing.

Chain INPUT (policy ACCEPT 121 packets, 11462 bytes)

121 packets (11462 bytes) were ACCEPTED by the INPUT chain rules.

However if you did try to initiate a connection to port 3306 (after last change of rules) it is very strange that rules:
0        0 ACCEPT     tcp  --  *      *       88.208.221.101       0.0.0.0/0           tcp dpt:3306
0        0 REJECT     tcp  --  *      *      !88.208.221.101       0.0.0.0/0           tcp dpt:3306 reject-with icmp-port-unreachable

have counts of 0 - no packet matched those rules.

Try to initiate a mySQL connection and see if these counters grow.
0
 

Author Comment

by:albyh
ID: 24754419
Chain INPUT (policy ACCEPT 1022 packets, 97820 bytes)
    pkts      bytes target     prot opt in     out     source               destination        
    1025    98000 PORTSEN    all  --  *      *       0.0.0.0/0            0.0.0.0/0          
       0        0 ACCEPT     tcp  --  *      *       88.208.221.101       0.0.0.0/0           tcp dpt:3306
       3      180 REJECT     tcp  --  *      *      !88.208.221.101       0.0.0.0/0           tcp dpt:3306 reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination        

Chain OUTPUT (policy ACCEPT 1300 packets, 1391507 bytes)
    pkts      bytes target     prot opt in     out     source               destination        

Chain PORTSEN (1 references)
    pkts      bytes target     prot opt in     out     source               destination        
       0        0 DROP       all  --  *      *       59.56.111.79         0.0.0.0/0          
       0        0 LOG        all  --  *      *       59.56.111.79         0.0.0.0/0           LOG flags 0 level 4 prefix `portsentry attack alert'
       0        0 DROP       all  --  *      *       205.209.161.228      0.0.0.0/0          
       0        0 LOG        all  --  *      *       205.209.161.228      0.0.0.0/0           LOG flags 0 level 4 prefix `portsentry attack alert'
0
 
LVL 16

Expert Comment

by:Blaz
ID: 24754492
OK. Now the counters are nonzero:
0        0 ACCEPT     tcp  --  *      *       88.208.221.101       0.0.0.0/0           tcp dpt:3306
3      180 REJECT     tcp  --  *      *      !88.208.221.101       0.0.0.0/0           tcp dpt:3306 reject-with icmp-port-unreachable

3 packets were recived for port 3306 and were rejected since they did not come from IP 88.208.221.101.

Did you try from this IP (which should work) or did you test from some other IP? Is the IP written correctly?
0
 

Author Comment

by:albyh
ID: 24754526
They were requests from a script on that server (88.208.221.101), the IP is definately correct.
0
 
LVL 16

Expert Comment

by:Blaz
ID: 24754621
Perhaps there is some kind of NAT between the servers?

Try to LOG the packets to see what IP the request comes from:
Run chain LOG If protocol is TCP and destination port is 3306

Put this rule on top of other rules. Then (after trying the connection from 88.208.221.101) check log /var/log/messages for iptables entries. Post the relevant entries here - the entries are in the form:
Jul  1 6:14:13 servername kernel: IN=eth0 OUT= MAC= SRC=88.208.221.101 DST=88.208.221.154 LEN=233 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=50234 DPT=3306 LEN=213

0
 

Author Comment

by:albyh
ID: 24754759
I've checked the log /var/log/messages its logged the IP table changes but how do I get it to log the port request?
0
 
LVL 79

Expert Comment

by:arnold
ID: 24755433
Did you configure mysql to accept connection from the remote host as well.
You can run strace on the mysql process to see if it sees a connection request.

If I am not mistaken, the 3 packets were rejected.
Try using the source as 88.208.221.101/32 in the accept rule.
0
 

Author Comment

by:albyh
ID: 24755497
Yeah if the rules are set to accept then the mysql requests comes through no problem.

I've just tried adding the /32 but unfortunately that hasnt worked either :-(
0
 
LVL 79

Assisted Solution

by:arnold
arnold earned 400 total points
ID: 24755808
Could you once again post the output of iptables -L
If you have a local web server, access it from the system with Ip 88.208.221.101 and see what IP is reflected in the web server's log for the access.
Look at the netstat -rn on the 88.208.221.101 system.  It might have two network interfaces and instead of taking the 88.208.221.x path it is taking the other path altering the source IP.
0
 
LVL 16

Accepted Solution

by:
Blaz earned 600 total points
ID: 24757545
> I've checked the log /var/log/messages
> its logged the IP table changes but how
> do I get it to log the port request?

If you add the rule:
Run chain LOG If protocol is TCP and destination port is 3306

You should get a packet log in messages file - for every attempt of connection. The log entry should be like:
Jul  1 6:14:13 servername kernel: IN=eth0 OUT= MAC= SRC=88.208.221.101 DST=88.208.221.154 LEN=233 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=50234 DPT=3306 LEN=213

Post the lines from the log here. And please post again iptables rules for us to see if the logging rule is there:
iptables -L -nvx
and:
iptables -t nat -L -nvx

PS: Maybe there is a more oficial syntax for logging packets in webmin, but I found suggestions that the posted rule should work.
0
 

Author Closing Comment

by:albyh
ID: 31598711
The problem was sorted by a server engineer.

Thanks for your help guys
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Wikipedia defines 'Script Kiddies' in this informal way: "In hacker culture, a script kiddie, occasionally script bunny, skiddie, script kitty, script-running juvenile (SRJ), or similar, is a derogatory term used to describe those who use scripts or…
BIND is the most widely used Name Server. A Name Server is the one that translates a site name to it's IP address. There is a new bug in BIND (https://kb.isc.org/article/AA-01272), affecting all versions of BIND 9 from BIND 9.1.0 (inclusive) thro…
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
In this brief tutorial Pawel from AdRem Software explains how you can quickly find out which services are running on your network, or what are the IP addresses of servers responsible for each service. Software used is freeware NetCrunch Tools (https…
Suggested Courses
Course of the Month12 days, 19 hours left to enroll

777 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question