[mmgRay]

Yup yup, thanks for all your help!

[Myatu]

It should take effect immediately after editing it.

[mmgRay]

Thanks, after that just a simple service network restart right?

[Myatu]

No, no - don't empty it You should have at least one entry in there. To use the DNS server from OVH, you can change the /etc/resolv.conf file to read as following (just this single line):

nameserver 213.186.33.99

[mmgRay]

This might be because you have specified the localhost/127.0.0.1 in /etc/resolv.conf or elsewhere for DNS lookups; if you are not running your own DNS server, then you should consider changing that as it could add unnecessary delays and slow down several applications (SSH being one of them).

This seems to be the case, how can I disable this? just empty the conf?

[Myatu]

Correct, through the "lo" (localhost / loopback interface) a process (on your server) attempted to do a DNS lookup (UDP port 53) on 127.0.0.1. This might be because you have specified the localhost/127.0.0.1 in /etc/resolv.conf or elsewhere for DNS lookups; if you are not running your own DNS server, then you should consider changing that as it could add unnecessary delays and slow down several applications (SSH being one of them).

As for the entries you've added, they should indeed work. However, you must keep in mind that the order of things is important. So if those two lines were to appear after a DROP statement, then this rule would never be applied (and a possible reason why you still see this message). In that case, simply move the rules up. (You can verify this by typing iptables -L from the shell, which will display everything in the order it'll be processed).

[mmgRay]

Hello,

thanks for the explanation, I however, cannot find syslog i've ran a find command but no dice.


EDIT: was in messages, I only saw this error;

Feb 10 19:23:38 r24036 kernel: iptables-input-drop:IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=73 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=48954 DPT=53 LEN=53

So judging by what you explained port 53 is blocked, right? I added;

-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT

but its still giving me that error..

[Myatu]

The messages will be logged in the /var/log/syslog file. You can use tail /var/log/syslog to see the output of just the last few lines. An example of what they look like:

Feb  9 10:36:55 host kernel: iptables-input-drop:IN=eth0 OUT= PHYSIN=eth0 MAC=00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=123.11.22.33 DST=91.22.33.44 LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=39014 DF PROTO=TCP SPT=36670 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0

The first part is "Feb 9 10:36:55 host kernel: iptables-input-drop:" and is simply a timestamp of when this event occurred and who logged in (in this case, we know it was iptables thanks to our handy "iptables-input-drop:" portion we've added.

"IN=eth0" gives you an indication through which network interface the packet came, in this case "eth0". If you were to use bridging or bonding, this might be something like "br0" or "bond0"; "PHYSIN=eth0" will let you know the true physical network interface from which the packet came (regardless of the bridge / bond / etc).

"OUT=" is blank in this case, since the packet wasn't forwarded (ie., NAT, etc). But this indicates where the packet is supposed to go to.

"MAC=00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx " is a combination of the MAC addresses of the physical network devices, which you'd only have to look at in more complex networks really.

"SRC=123.11.22.33 DST=91.22.33.44" lets you what IP address the packet came from and where it was headed. In this case, it came from 123.11.22.33 and arrived at your network interface (eth0) at the IP 91.22.33.44. If you had more IPs per network interface, then the "DST=" portion would reflect that.

"LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=39014 DF" This is specific to the packet itself and for advanced debugging (which I could get into some other time).

"PROTO=TCP" lets you know what kind of protocol was used. For example, TCP or UDP and in the case of pings/traceroutes ICMP.

"SPT=36670 DPT=80" The source port where the packet originated (36670) and where it was destined (port 80). This goes hand-in-hand with the "SRC=" and "DST=" fields. So from this example, you know that 123.11.22.33 was trying to reach a web server running at 91.22.33.44.

The last portion, "WINDOW=5840 RES=0x00 SYN URGP=0" is also more often used for advanced debugging.

With this, you know exactly when and what the IPtables filter has dropped, where it came from and where it was headed. Again, in the example here, I know someone tried to access a web server that I blocked access to for outsiders.

Hope that helps a bit

[mmgRay]

Thanks for your reply Myatu & Yonatan. I have added this line but I'm not really sure what to look for in the logs, can someone help me on my way?

[Myatu]

Hmm... Just a few things...

The last entry in the OUTPUT chain ("-A OUTPUT -j ACCEPT") is superfluous (everything is accepted, not dropped as your comment suggested).

I don't see 127.0.0.1/32 on the INPUT chain (only OUTPUT chain) making the OUTPUT entry useless (since it gets denied on the INPUT side anyway). You're better off using something like "-A INPUT -i lo -j ACCEPT" and the same for OUTPUT.

There's no need for checking UDP port 22 on the SSH chain, since it's not used. So you can simplify that (complexity makes it harder to debug things for you).

But from what I can tell, a traceroute should work as expected - you're not blocking outgoing ICMP (due to that last "-A OUTPUT -j ACCEPT") and responses should come back through the "-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT" rule.

But, to help you debug issues with the firewall, what you can do on the INPUT chain, just before "-A INPUT -j DROP" you add this:

-A INPUT -j LOG --log-prefix "iptables-input-drop:" --log-level 6

(You can also do this on the OUTPUT chain if you wish - just give it a different log-prefix). Then keep an eye on your syslog with something like "tail -f /var/log/syslog" to see what IPtables drops. If it's dropping ICMP messages, then I'll need to look closer at your IPtables chains...

Also, I know I'm saying this often, but tcpdump ("man tcpdump") is a really helpful tool in debugging issues like this. Something like "tcpdump -nSi eth0 icmp" would give you an overview of what's happening with ICMP messages from and to your system...

[mmgRay]

Well it isn't just the traceroute issue, the site is also much slower for some people when iptables is enabled. When I stop it the site is lightning fast, so there much be a problem with the config.

[yonatan]

Nothing is wrong with a traceroute that does not complete.

30 hops is the default max hops for a trace in most cases.

if a host on the trace does not answer your request, usually it means the router has some better stuff to do than answering your icmp packet ...

if the trace never completes , so the last hop that DID reply or the one after it usually is to blame for dropping your icmp requests, but it never indicates a problem.

and there is nothing to do with the firewall configuration you pasted here, and the traceroute.

anyhow, I do recommend configuring iptables in - stateful inspection mode.

[mmgRay]

Hello,

I have found that my IPtables config has caused some speed issues. The tracert almost always times out after 30 hops, so a full one is never completed. When temporairly stopping iptables the tracert works just fine with just 6 hops. What causes this issue? Full iptables below;

*filter


-N SSHCHAIN
-N ALLOWEDIPS


# For testing
-A INPUT -s 94.23.63.114 -j ACCEPT
-A INPUT -s **censored** -j ACCEPT


# ping
# -A INPUT -p icmp -m icmp -d 94.23.200.210 -j ACCEPT
-A INPUT -i eth0 -p icmp --source proxy.ovh.net -j ACCEPT
-A INPUT -i eth0 -p icmp --source proxy.p19.ovh.net -j ACCEPT
-A INPUT -i eth0 -p icmp --source proxy.rbx.ovh.net -j ACCEPT
-A INPUT -i eth0 -p icmp --source ping.ovh.net -j ACCEPT
-A INPUT -i eth0 -p icmp --source 94.23.200.250 -j ACCEPT


# accept established connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


# blocks syn flood
# -A INPUT -p tcp --syn -m limit --limit 10/second -j ACCEPT


-A INPUT -p tcp -m tcp --dport 22 -j SSHCHAIN
-A INPUT -p udp -m udp --dport 22 -j SSHCHAIN

-A SSHCHAIN -s cache.ovh.net -j ACCEPT
-A SSHCHAIN -d **censored** -j ALLOWEDIPS
-A SSHCHAIN -j DROP


# httpd
-A INPUT -p tcp -m tcp --dport 80 -d 94.23.200.210 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -d 94.23.200.210 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 7080 -**censored** -j ALLOWEDIPS
-A INPUT -p tcp -m tcp --dport 443 -d **censored** -j ALLOWEDIPS


# email
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT


# sa-mp
-A INPUT -p tcp -m tcp --dport 7777:7778 -d 94.23.200.210 -j ACCEPT
-A INPUT -p udp -m udp --dport 7777:7778 -d 94.23.200.210 -j ACCEPT

# vco
-A INPUT -p tcp -m tcp --dport 4800 -d 94.23.200.210 -j ACCEPT
-A INPUT -p udp -m udp --dport 4800 -d 94.23.200.210 -j ACCEPT 

# COD4
-A INPUT -p tcp -m tcp --dport 28960 -d 94.23.200.210 -j ACCEPT
-A INPUT -p udp -m udp --dport 28960 -d 94.23.200.210 -j ACCEPT

# COD2
-A INPUT -p tcp -m tcp --dport 28961 -d 94.23.200.210 -j ACCEPT
-A INPUT -p udp -m udp --dport 28961 -d 94.23.200.210 -j ACCEPT

# vent
-A INPUT -p tcp -m tcp --dport 3784 -d 94.23.200.210 -j ACCEPT
-A INPUT -p udp -m udp --dport 3784 -d 94.23.200.210 -j ACCEPT


-A ALLOWEDIPS -s **censored** -j ACCEPT

-A ALLOWEDIPS -j DROP


# drop all else
-A INPUT -j DROP


# dont allow new output connections, unless to ourselves
-A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT


-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


# Apps might need these sometimes
-A OUTPUT -p udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp --dport 53 -j ACCEPT
-A OUTPUT -p tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp --dport 21 -j ACCEPT


# email
-A OUTPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT


-A OUTPUT -j ACCEPT


# dont allow forwarding
-A FORWARD -j DROP


COMMIT


*nat


COMMIT