I apologize if I have the wrong forum here. I’m running openSUSE 13.2 (Harlequin) (x86_64) 64-bit and I’m worried that maybe someone has gotten into my system. Here’s the output from iptables -L
The first line worries me. I don’t know a lot about iptables but isn’t that allowing any connection from anywhere into my system? Doesn’t it essentially nullify the rest of my firewall because it’s the first rule in the list? Any help would be greatly appreciated. Thank you.
No, or at least, not necessarily. -L doesn’t give you all the information that you need. Probably -S is closer to what you want, and probably there is something else in that line, like a source of ‘lo’, and, if that is the case, it is a whole lot less worrying.
Thank you for clarifying guys. It had me worried but not so much anymore. This is the output from iptables -S:
-P INPUT DROP-P FORWARD DROP
-P OUTPUT ACCEPT
-N forward_ext
-N input_ext
-N reject_func
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT
-A INPUT -j input_ext
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-IN-ILL-TARGET " --log-tcp-options --log-ip-options
-A INPUT -j DROP
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "SFW2-FWD-ILL-ROUTING " --log-tcp-options --log-ip-options
-A OUTPUT -o lo -j ACCEPT
-A input_ext -m pkttype --pkt-type broadcast -j DROP
-A input_ext -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A input_ext -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A input_ext -p tcp -m tcp --dport 51413 -m conntrack --ctstate NEW -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-ACC " --log-tcp-options --log-ip-options
-A input_ext -p tcp -m tcp --dport 51413 -j ACCEPT
-A input_ext -p udp -m udp --dport 51413 -m conntrack --ctstate NEW -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-ACC " --log-tcp-options --log-ip-options
-A input_ext -p udp -m udp --dport 51413 -j ACCEPT
-A input_ext -m pkttype --pkt-type multicast -j DROP
-A input_ext -m pkttype --pkt-type broadcast -j DROP
-A input_ext -p tcp -m limit --limit 3/min -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A input_ext -p icmp -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A input_ext -p udp -m limit --limit 3/min -m conntrack --ctstate NEW -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A input_ext -j DROP
-A reject_func -p tcp -j REJECT --reject-with tcp-reset
-A reject_func -p udp -j REJECT --reject-with icmp-port-unreachable
-A reject_func -j REJECT --reject-with icmp-proto-unreachable
I don’t really understand what the different is. According to iptables --help, the -L lists the rules in a chain or all chains whereas the -S prints the rules in a chain or all chains. I read that part of the man page and got a bit confused. I tried googling it to no avail.
Just to make sure I fully understand this, from the iptables -S output, the default for incoming packets is to drop them, I don’t really understand the forward part. Is that for if my NIC somehow gets a packet that it is supposed to be forwarding to another computer or something? the default for outgoing is to accept the packets and allow them to go out through the firewall…the -N means create a new chain. We create three new chains and then we add rules to two of the new chains and we add a few rules to the INPUT chain. With the first part of the iptables saying to drop the incoming, that’s only if a rule isn’t matched down below, right? Like that’s the default behavior? One of those if none of these rules match a packet, then drop it?
I wanted to know if there was a way to tell if my firewall is setup to make my ports appear stealthed or not. Thanks for the help. I really appreciate you taking the time out of your schedule to answer my questions! Thank you!!!
This is the results I got from the link you sent, I replaced my IP address with xx.xx.xx.xx and I selected all the ports: Starting job… [2015-05-16 22:13:30] Stay on this page for results!
Starting Nmap 6.00 ( http://nmap.org ) at 2015-05-17 01:13 EEST
NSE: Loaded 17 scripts for scanning.
Initiating Ping Scan at 01:13
Scanning xx.xx.xx.xx [4 ports]
Completed Ping Scan at 01:13, 1.33s elapsed (1 total hosts)
**Nmap scan report for xx.xx.xx.xx [host down]
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 1.85 seconds
Raw packets sent: 8 (304B) | Rcvd: 3 (156B)
In that case either your ISP already filters things or you have a hardware firewall (such as your DSL/Cable/Fibre device) that does it for you in addition to your software one.
Just to have a look at your input chain, for a second (simplifying, to try to make things clearer, and I’ve numbered the rules, just for ease of reference):
1) -P INPUT DROP-P FORWARD DROP
2) -A INPUT -i lo -j ACCEPT
3) -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
4) -A INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT
5) -A INPUT -j input_ext
6) -A INPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-IN-ILL-TARGET " --log-tcp-options --log-ip-options
7) -A INPUT -j DROP
sets up a policy for this chain: only inbuilt chains have policies, and a policy is what happens to a packet if it has got to the end of the chain, without being shunted off somewhere else for processing. An interesting side note is that this does the same thing as rule 7), and you don’t actually need both.
‘accepts’ packets, but it only applies to packets from the ‘loopback’ interface; this does not apply to external packets that get thrown at your box
and 4) apply to packets from ‘established’ and ‘related’ connections; so these connections have already been checked and allowed and the packets are either directly from something already allowed or an offshoot of something already allowed.
sends packets off to a custom chain called input_ext
does some logging; it is rate limited, so you don’t get the case that a lot of ‘bad’ packets crashing the box, because packets come too fast for the logging system to cope. I’m not sure, given the previous rule, that packets ever get here.
duplicates the effect of the chain policy, so seems superfluous. There is a case that ‘policies’ that cause all packets to be dropped are a bit dangerous in situation where you’ve got a remote box that you rely on, eg, ssh for admin, and for which you manually fiddle around with the rules (because you can lock yourself out), but that doesn’t really apply in this particular case. (This is, in a sense, the opposite of the uncomprehending advice that you find sprayed around the internet that only a policy of ‘drop’ is safe; people who say this haven’t actually understood, but have repeated advice that they have seen elsewhere.)
In any case, for all things iptables, the definitive work is available at frozentux.
Thanks! I haven’t really messed around with the tables at all. They just came that way. Thanks for the link. I have some stuff I need to get done today but I will definitely be reading it! For number four, doesn’t that say let it through if it’s related to something that’s already allowed through, but only if it’s an ICMP packet?
We do have a router with a built-in firewall. It’s nothing special or anything. Just a wireless N router. Perhaps that’s stealthing the ports? We have cable but the cable modem doesn’t have a firewall, unless Time Warner changed something from a few years back.
I removed the ping option and tried again. It showed the ports as filtered. It showed my host as being up. Is there a way to stealth my machine using iptables? If there is, I wonder why that isn’t the default option. I have yet to read that article on iptables. Perhaps when I finish my work and I get to reading it, it’ll show me how to stealth my ports. Thanks.
Spork Schivago donned his tin foil hat and penned:
> I removed the ping option and tried again. It showed the ports as
> filtered. It showed my host as being up. Is there a way to stealth my
> machine using iptables? If there is, I wonder why that isn’t the
> default option. I have yet to read that article on iptables. Perhaps
> when I finish my work and I get to reading it, it’ll show me how to
> stealth my ports. Thanks.
>
>
There could be one problem with that.
I.E. you stealth your machine so much that it cannot be seen and hence
unreachable from outside unless by IP not address, that can easily be done
but then “You” will have to be there to allow each and everything access
while the machine is on the interlubes.
Now if this is an internal LAN then just set the firewall as such: not to
accept anything from external.
If this is a home workstation or game PC then do not stealth too much
because you will lock out of all those nice things that Steam etc. offer.
Trust me I know, I am at the moment staying at a company address where I
have sort of set up a corporate fire wall in conjunction with provider, I am
lucky to be able to get on this site, everything is blocked so no Minecraft
or anything for me well not while I am connected here
HTH
–
Mark
Nullus in verba
Caveat emptor
Nil illigitimi carborundum
well not while I am connected here 