HappyDude
join:2008-02-18
Brooklyn, NY
| Help: Configuring Router IPTables to stealth all ports ...
Hiya guys!!
Now, I'm running into problems configuring IPTables correctly. I'm using the Westell Versalink 7500 modem/switch. I have the hardware firewall on and I am trying to get it to stealth all the ports.
Unfortunately, almost 4 of the 5 port scans I do, FTP ports always seem open. Is there anyway I can correct this?
Also, I wish to allow packets from port 6112 in order to play Starcraft on B.Net.
Here are my current rules. (Here's the post: »Help! Tweaking Westell Versalink 327W Firewall for Starcraft where you can find links to see where I got my information from and the overall layout of the rules.)
|
|
mikenolan7
Premium
join:2005-06-07
Torrance, CA
 ·Sprint Mobile Broa..
| In this section, you are not "stealth". Using a TCP reset does not simply drop incoming traffic, it replies with a reset packet, which indicates that your network exists. It is the proper response per the RFC's, but it is not stealth.
# Drop them all
SetDropRules() {
# Reset tcp connection attempts on all other ports
# This is the standard TCP behaviour for a closed port. Reading
# suggests there is no value in stealthing ports and since some are
# open on this host it doesn't seem to matter. Therefore, let's be a
# good TCP citizen
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
If you want to remain stealthed, replace
-j REJECT --reject-with tcp-reset
with
-j DROP
But then, you won't be a good TCP citizen.  |
|
HappyDude
join:2008-02-18
Brooklyn, NY
| reply to HappyDude
Thanks for the reply, mikenolan.
I applied your edits, but I still end up with the FTP ports closed and not stealthed.
Is there any other reason that could make the GRC/ Hackerwatch port scanners do that?
Thanks for your help. I really appreciate it.
P.S.-
As it turns out, the configuration is compatible with Starcraft already. It was just the B.net servers acting up that made me not able to connect. |
|
Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA | reply to HappyDude
would do it ;) |
|
HappyDude
join:2008-02-18
Brooklyn, NY | Steve, I don't quite get what that line is supposed to do.
Would you tell me where to insert the code and why I would need it?
Thanks very much !! |
|
Cudni
La Merma - Vigilado
Premium,MVM
join:2003-12-20
Someshire
| said by HappyDude  :Would you tell me where to insert the code and why I would need it? ifdown command brings the interface down. Steve said it jokingly because he does not believe, at all, in any merit of being stealth
Cudni
--
"Mercifully, he hit him with the soft end of the pistol."
Help yourself so God can help you.
Microsoft MVP, 2006 - 2008 |
|
mikenolan7
Premium
join:2005-06-07
Torrance, CA
·Sprint Mobile Broa..
1 edit | reply to HappyDude
I have to say I agree with Steve. If you use an ISP, and who doesn't, there is very little value in stealth. The people that write automated software that runs remote attacks know the IP addresses that the ISP's use, and just try their attacks against addresses one after another. You are far more likely to have a problem from surfing to the wrong site, downloading bad software, or opening the wrong email. Stealth protects you from none of these things, and results in increased traffic on the internet, since you don't send the proper reply when someone mistakenly tries to access your network (why you won't be a good TCP citizen). That said, it's your choice. Try reading up more on iptables instead of just following the instructions from one link. A good place to learn is:
»www.netfilter.org/
Taking a closer look at your ruleset:
There is a problem in your first subroutine (I'm probably aging myself by using that term),
SetDefaultPolicy() {
# Drop everything
iptables -A INPUT -i eth0 -p tcp --syn -j DROP
iptables -A INPUT -i eth0 -p tcp --dport 0 -j DROP
iptables -A INPUT -i eth0 -p tcp --dport 1 -j DROP
iptables -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -F INPUT
"iptables -F" is the command to flush all rules from all tables, so you just flushed (erased) the first three rules you added in the first three lines. "iptables -F INPUT" flushes all the rules from the INPUT table, so you just flushed the INPUT table again, even though it was already empty.
The next section of SetDefaultPolicy:
iptables -N inbound
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i eth0 -j inbound
iptables -A INPUT -i lo -j ACCEPT
iptables -A inbound -m state --state ESTABLISHED -j ACCEPT
iptables -A inbound -m state --state RELATED -j ACCEPT
creates the table "inbound" and forwards all packets from your internal interface (eth0) to it, accepting everything that is ESTABLISHED and RELATED (from a connection that has already had accepted traffic). It also allows all INPUT on lo, your loopback interface.
The next three subroutines block IRC traffic, and reject packets from a host and a network, that you evidently don't like: 10.220.231.236, and 10.220.232.0/24. I hope those aren't the addresses that you are running your scans from! If you really want to be F-119 kind of stealth, change the -j REJECT ... to -j DROP on those also.
Your SetForwardingRules look okay, and allow all outgoing connections to be established. This should allow you to play any game you like in which you are not running a server.
In SetLoopbackRules
iptables -A INPUT -i lo -j ACCEPT
appears to be redundant, since you already created that rule in SetDefaultPolicy. I don't see where SetLoopbackRules is used other than in (start), but I may be missing something.
This could go on for quite a while. Your ruleset appears to be quite complex, and I believe without digging a lot deeper, that there is more redundancy. I don't see right off the bat what is preventing your FTP ports from being stealthed. It is also possible that your router needs FTP access to download firmware updates, and adds those rules in before anything that you have control of. I would suggest resetting your router to the default rules. Then replace "-j REJECT ..." with "-j DROP" everywhere. I'd really suggest learning iptables and not blindly following what others tell you to do. After all, I could be a bad guy that gives you a bunch of bad commands so I can break into your network.  
(Hint: watch out for Steve, he's very clever  ) Of course, I am joking - he's clever but trustworthy.
Edit: You did run (restart) after changing the rules, right? If you are really set on finding help to debug the rules run
iptables --list
and post the results. That makes it easier. |
|
Greg_Z
Premium
join:2001-08-08
Springfield, IL | Even better, pulling that neat cable between the modem & Router will do wonders in Stealthing your connnection also. |
|
HappyDude
join:2008-02-18
Brooklyn, NY
| reply to mikenolan7
mike, thanks for the response.
These rules are just things that I put together from various sources. I don't truly understand IPTables and how the syntax works. I barely have time to even read the netfilter tutorial.
If its too much to ask, can you help me amend those rules? It seems that you understand IPTables enough to give me recommendations, and it would really help me if you can tell me exactly what to change and how to do it (what lines take place of what).
Thanks very much. I really appreciate it, guys !! |
|
Greg_Z
Premium
join:2001-08-08
Springfield, IL | Well, if you do not understand ipTables, then you may want to head over to »www.iptables.org/ |
|
mikenolan7
Premium
join:2005-06-07
Torrance, CA
·Sprint Mobile Broa..
| reply to HappyDude
What you are asking for would take me several hours, and when it's done you won't have learned anything. This forum is here to provide help, but mostly help in educating yourself, which is the only way to secure your network without hiring professional help. I am a hobbyist, not a professional, I could make a mistake. There are security professionals on this forum that I learn a lot from. If I provide free services, I am undercutting their business. As I said in an earlier post, I could be a bad guy. I prefer to write my rulesets with a more linear flow (not so many subroutines), which is easier to troubleshoot for me. There are many reasons why people are not answering your question the way you are asking.
I will give you an even easier hint to get started. Go to this link from the netfilter site:
»www.yolinux.com/TUTORIALS/LinuxT···way.html
Follow the instructions in Example 2. It will get you up and running. Then continue your education and add to the simple ruleset as you learn more. If that doesn't work for you, return here and I will provide more help on troubleshooting that ruleset. |
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs: 
| reply to HappyDude
And here's my much shorter primer on the topic: »dmiessler.com/study/netfilter/
But here's the short version:
These are the last two rules in my firewall. The DROP target tells netfilter/iptables to discard packets without sending any notification back to the client, i.e. DROP = STEALTH.
When you see a "REJECT" in your rules you are telling the other person that you're not accepting their packets, i.e. you're not being very stealthy.
With that said, I'll agree with Steve. He said it best when he said one's obsession with stealth is inversely proportional to their knowledge of TCP/IP. This isn't mean to to be elitist or rude; it's actually true.
The more you learn about networking and security the more you'll learn that concepts like stealth are largely unimportant in the real world.
Anyway, hope this helps.
--
dmiessler.com -- grep understanding knowledge |
|
HappyDude
join:2008-02-18
Brooklyn, NY
| reply to HappyDude
Alright, I understand.
I'll report back with the amended rules to see what you guys think of it. Thanks a lot.
I'll take a look at www.netfilter.org/ , »www.yolinux.com/TUTORIALS/LinuxT···way.html , »dmiessler.com/study/iptables/ for more info. I'll see what I can put together. |
|
Ravenheart
join:2006-02-10
Berkeley, CA
1 edit | HappyDude, I know another odd thing you should check is that the IP GRC shows is your actual IP (as shown for your router WAN port) and not some kind of proxy. |
|
HappyDude
join:2008-02-18
Brooklyn, NY
3 edits | I was playing around with my rules, and apparently, I DO NOT get stealth in scans even by leaving these rules:
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
as the only rules in the text.
How is this possible? Also, with enough testing, I was only able to get stealth by testing immediately after refreshing my rules and hitting test again.
Can anyone give a little help as to correct why this is happening? Or is this something wrong with my router, and I shouldn't worry about it since the firewall text is correct?
EDIT- I realize, maybe its a flaw in the router. The Westell 7500 is Verizon's newest model, and might it have flaws in its design? Can anyone confirm it?
EDIT 2- Also, the FTP port is the only port that seems erratic. After refreshing the rules and hitting test 2 times, the port is stealthed. Afterwards, the port reports closed.
EDIT 3- I tried the scan with just the Windows Firewall on (which supposed to stealth ports), and the GRC test reported that it responded to pings and the FTP port is still closed. That means the firewall is on, but is it just something wrong with the FTP port? |
|
mikenolan7
Premium
join:2005-06-07
Torrance, CA
·Sprint Mobile Broa..
| If you can get to a command window, when your test is reporting ftp closed run:
iptables --list
That will return a list of the actual rules that are running on your firewall. I am not familiar with your hardware, but I suspect that it uses ftp to download updates. It might automatically add a rule to your firewall to allow ftp. A closed port cannot be attacked, you should really only be concerned with an open port. I monitor attempted connections on the outside of my firewall. I almost never see attempts to port 23, which would indicate bot attacks on the ftp service.
Does your firewall have a setting that allows remote updates?
Also try running netstat -a. That should tell you if you are actually running an ftp server on your firewall.
I hope that is just a test ruleset, it should not allow any traffic to be forwarded through your firewall (from/to your desktop machines). |
|
HappyDude
join:2008-02-18
Brooklyn, NY
3 edits | reply to HappyDude
UPDATE:
Looking back to the original basis of my rules, it turns out that the redundancies found was my fault; I edited the rules in the default policy after reading various sources and what their default policies were.
It just turns out that their default may not be my default.
Here is my original source for my rules:
»www.novell.com/coolsolutions/fea···139.html
Unfortunately, I still cannot find out why the scans report the FTP ports closed instead of stealth. Well, can you guys find anything wrong with it?
EDIT- Updated my rules. Still unable to stealth FTP ports :( .
GRC (of other few scanners) reports ports 20 & 21 closed and not stealth. Individual port scan from GRC of 500 reports closed (while service port scanning of first 1056 ports reports stealthed). Huh? Can anyone help? |
|
Greg_Z
Premium
join:2001-08-08
Springfield, IL | When a port IS in Stealth, the Firewall will state that it is closed. Think of Stealth like Harry Potter's Inviso Cloak. You know that he is under it, but you do not know where he is. |
|
EGeezer
Summertime -
Premium
join:2002-08-04
Country!
 ·Callcentric
 ·RoadRunner Cable
·AT&T CallVantage
1 edit | said by Greg_Z :When a port IS in Stealth, the Firewall will state that it is closed. Think of Stealth like Harry Potter's Inviso Cloak. You know that he is under it, but you do not know where he is. I'd compare it to a f@rt in an elevator. Common sense and experience tells you it's there, but nobody will answer when you ask who did it..
I just love analogies!
--
If dogs travel in space at the speed of light, do they reach their destination in dog-light years? |
|
Greg_Z
Premium
join:2001-08-08
Springfield, IL | I forgot about that one, but then again. |
|
