LinuxQuestions.org - stealthing port 113

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - stealthing port 113 (https://www.linuxquestions.org/questions/linux-security-4/stealthing-port-113-a-127379/)

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.

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. ;)

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).

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.

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.