LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 12-19-2003, 05:19 PM   #1
danielw
Member
 
Registered: Jul 2003
Location: Australia
Distribution: CRUX
Posts: 35

Rep: Reputation: 15
stealthing port 113


Hello,

Just wondering if port 113 can be successfully 'stealthed' or hidden so that it does not appear as 'closed' when port scanned. Currently I have these firewall rules, which allow access to port 113 freely.

iptables --new-chain block
iptables --append block --match state --state ESTABLISHED,RELATED --jump ACCEPT
iptables --append block --match state --state NEW --in-interface ! ppp0 --jump ACCEPT
iptables --append block --match state --state NEW --protocol tcp --destination-port 113 --in-interface ppp0 --jump ACCEPT
iptables --append block --jump DROP

iptables --append INPUT --jump block
iptables --append FORWARD --jump block


Now if I get rid of the rule pertaining to port 113, things like IRC and mail and other stuff don't work correctly. So how do I make it so only legit traffic can pass through port 113 whilst blocking everything else? Any practical examples?


Also, can someone tell me a safe if this NAT / MASQ rule is safe?

iptables --table nat --append POSTROUTING --source 192.168.0.0/24 \
--destination ! 192.168.0.0/24 --out-interface ppp0 --jump MASQUERADE

I heard somewhere that anyone could spoof their ip address and be forwarded successfully, has anyone got any practical examples of how I can secure this?


thankyou for your time.
 
Old 12-19-2003, 06:25 PM   #2
gundelgauk
Member
 
Registered: Jul 2003
Distribution: Gentoo
Posts: 168

Rep: Reputation: 30
Greetings!


Personally I find it strange that blocking packets to port 113 would deny access to "irc, mail and other stuff". Maybe you could try allowing outbound connections to this port but deny incoming connections with state NEW to this port. That way you could theoretically allow necessary connections on this port (outbound and related/established inbound).


About your NAT rule... I personally consider it quite safe. But if you are worried about spoofed IPs (and I do get some of them) you could add anti-spoof rules. Those would look like kind of like this:

Code:
iptables -I INPUT 1 -i ppp0 -s 192.168.0.0/24 -j SPOOF_RULE
iptables -I INPUT 1 -i eth0 -s ! 192.168.0.0/24 -j SPOOF_RULE
# (note: add a rule called 'SPOOF_RULE' and have it deny and log with a special prefix so that you notice the blocked spoof attempts like this:)
iptables -N SPOOF_RULE
iptables -A SPOOF_RULE -j LOG --log-level warning --log-prefix "INBOUND SPOOF BLOCKED: "
iptables -A SPOOF_RULE -j DROP
I see that you have knowledge about iptables so I leave it to you to adjust those rules to your LAN setup; regarding interfaces and so on. The idea is to block connections from certain interfaces that originate from IP adresses that can not be valid.

An example is this: I get incoming connections like this:
Quote:
INBOUND SPOOF BLOCKED: IN=ppp0 OUT=eth0 SRC=192.168
.0.139 DST=192.168.0.18 LEN=40 TOS=0x00 PREC=0x00 TTL=50 ID=60461 PROTO=TCP SPT
=2938 DPT=4665 WINDOW=0 RES=0x00 ACK URGP=0
This _could_ mean that someone tried to gain access to my LAN by spoofing his IP adress and making his packets appear like they originated from my LAN.


Pls bear in mind that this is all theoretical. I have rules quite like this but did not confirm the ones I posted as I altered them a bit. There certainly are ppl that have more experience with this than me so feel free to accept other advice.

And to all the others: Pls feel free to correct me if I'm wrong. I'm also learning all the time.
 
Old 12-20-2003, 01:00 AM   #3
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Rep: Reputation: 69
IRC and several other services do an IDENT query to each IP that connects to their network, in a weak attempt to identify users logging on (I think this is historical and no longer needed for any good reason). In any case, if the lookup times-out it will have a serious impact on the usability of such services. If the IDENT time-out is longer than the IRC time-out, then you'll get dropped before the IDENT finally quits trying.

The simple way to get around this is to REJECT rather than DROP 113/tcp. Nearly all good firewall scripts have 113/tcp set to reject. What this does is--instead of dropping packets silently--to immediately send an RST packet back to the server that queried you. This tells the remote server that you're not going to respond to IDENT queries, so the remote server knows that you're not going to give it info and it just lets you log on any way (thus the reason why having the IDENT check is stupid, since it's ignored if it gets refused).
 
Old 12-20-2003, 09:32 PM   #4
danielw
Member
 
Registered: Jul 2003
Location: Australia
Distribution: CRUX
Posts: 35

Original Poster
Rep: Reputation: 15
Hello once again,


Thankyou for your time gundelgauk and chort, it's been very informative
Only one minor question to ask, setting port 113 to reject still upsets alot of lame IRC servers. Good thing freenode is never that bad.

I tried this rule at first...

Quote:
iptables --append INPUT --match state --state NEW --protocol tcp --destination-port 113 --in-interface ppp0 --jump REJECT
IRC server didn't like it at all, so then I read the man a bit more (quite a good man page considering what it covers and this is what i came up with....

Quote:
iptables --append INPUT --match state --state NEW --protocol tcp --destination-port 113 --in-interface ppp0 --jump REJECT --reject-with icmp-host-prohibited
And yep, that seemed to do the trick. Must be the right response the ident query was looking for (noting that the default response with REJECT is "port-unreachable")

If you see any problems with my logic, don't be afraid to criticise.

Last edited by danielw; 12-20-2003 at 09:34 PM.
 
Old 12-21-2003, 03:53 AM   #5
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Rep: Reputation: 69
Man, that is really picky if an IRC daemon will only give you a pass if you return a certain ICMP type and code... Like I said, I have no idea why that legacy IDENT check is still performed: It's worthless.

Yell at the IRCOPs to remove to turn off that option.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Port 113 floppywhopper Linux - Security 7 02-07-2008 06:51 PM
port 113 jthepro Linux - Networking 2 05-24-2004 12:52 PM
Stealthing IDENT port 113 vasudevadas Linux - Security 2 01-07-2004 03:21 AM
Stealthing port 113 B McHack Linux - Distributions 1 11-16-2003 05:14 PM
port 113 pangfai Linux - Security 7 06-06-2002 05:53 AM


All times are GMT -5. The time now is 01:43 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration