blocked IP addresses coming through on netwatch

[Ragu_1]

I have this Debian GNU/Linux `woody' server running the kernel Linux 2.4.22 resting on a 2 MBPs intranet backbone. I have NATed all internal IPs in the range 168.168.168.0/24 to go out on a single externally resolvable IP. My firewall rule blocks all port services other than ssh. There is squid and an ntp server running behind the firewall. The NTP service is via UDP. The issue is, an internal host 168.168.168.100 is talking to a remote external host; even after I specifically blocked this IP in /etc/hosts.deny. What is up ? I have scanned thoroughly for rootkits and none.

[Stuart Browne]

If an internal host is talking directly to an external host, it would mean it's getting past your NAT.

Give us some details on the topography if you could (lan cards, basic router layout) and a look at your firewall rules (iptables -nvL & iptables -nvL -t nat).

The /etc/hosts.{allow,deny} files are only for services connecting to the host, not beyond it.

[Ragu_1]

The topology is a basic one like this [Internet Switch]---|eth0|------|eth1|---[Intranet Switch] I am attaching the outputs of the firewall rules as suggested by Stuart. How is the 168.168.168.100 guy jumping the wall ?

[Stuart Browne]

*blink*

wow..

Ok.

'netwatch' I take it uses libpcap to grab traffic (like 'tcpdump'), yes?

If so, you'll see all requests *PRIOR* to being MASQUERADE'd, as well as the after MASQ, so you should be seeing two.

If it's UDP 123, I'd assume it's being accepted by global ACCEPT on the INETOUT chain, and by :

112 8512 UDPACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123

on the INETIN chain (for the record, the LOG rule will never get hit in UDPACCEPT, as the 'ACCEPT' above it will just bypass it).

This make sense thus far? (sorry, have answered a dozen phone calls, converted half a dozen databases, and have beaten my head against the desk countless times in the time it's taken to write this little bit :P ).

[Steven E. Protter]

It seems that your iptables firewall structure is solid. Yet something is getting through that should not.

I can see from the configuration that you seem to be running a dmz and and external firewall on the same server.

Thats a design issue. The external firewall should be on on machine, the internal boundry another piece of hardware.

I would suggest at this point to activate iptables logging feature(It will go to /var/log/messages). That will gather you data on whats going on.

I may be wrong on the dmz issue, having misinterpreted your data. I would consider simplifying the setup if possible. I'm wondering what you are using squid for and what benefits it provides. Also, if all ports except secure shell are blocked, why is NTP working?

I'm missing something. I find your issue intellectually stimulating and wish to work on it further.

SEP

[Jerome Henry]

Your rule list is quite long and complex.

As far as I understand it, you set up an histeresis restraining packets quantity to 2/s, but you still accept packets in this limit.
If 192.168.0.100 is trying to connect to sth outside, depending on its configuration, it'll address you (input from eth1), or may address directly outside, forcing forward rule.
INPUT is read as ACCEPT from eth1. Packets go out, isn't it ?
On their way back, packets are accepted for several standard ports, and if they are related, which is the case if 0.100 initiate connection. Am I wrong ?
Forward is read as targeted to inetout, which can be read as accept, isn't it ?
Same comment as Input on their way back.
In this case, I see 0.100 initiating and maintaining connection without any problem, and same scenario for many other machines in internal part.
So will NTP work from the inside. Am I too tired and missing the main issue ?

As said, deny is for localhost, not for firewall rule. Steven suggests a good idea on setting up precise logs to see what connects from 0.100. A rootkit can be easily hidden from any chkrootkit tool. What did you use to check ?

hth

J

[Ragu_1]

None of my network segments is on a DMZ. Jerome Henry has done a good analysis and has tracked some vital issues. I am working on his leads alone now because they look definitive, SEP is quite off-track. I could solve a vital issue with Stuart's initial suggestion, partly. NTP uses higher ports to sync with a remote NTP server even if TCP/UDP 123 are blocked. Jerome would definitely get my 10 points if his clues turn out true. The GNU teaches us to get better and better.....

[Steven E. Protter]

Good Luck finding and answer.

Since there is a s suspcion of a rootkit, ie some kind of hack, I think it would be prudent to turn on iptables logging.

I totally agree with Jerome. Your rules list is too complex, and has obviously been breached.

Stuart is the best around here, and his suggestion will probably work out.

As an experienced administrator, I'll say you are doing what should be a simple job in a complex way. You are using too many rules, too many products based on the information provided in the original post.

Your presentation and subsequent information is incomplete. I use iptables to provide NAT access to my private office network. I'm not using squid and am uploading my iptables file(slightly edited) as a reference. I've purposely altered the external IP addresses for my network.

My firewall is working just fine.

I don't want any points for this. Good Luck.

SEP

[Stuart Browne]

wow.. mine at home is looking simpler and simpler!

The one here at work though wouldn't make sense unless I also threw in all the routing rules :P Go mangle table and 'ip rule's :)

(The joys of having 3-5 external network connections!)

But yes, am a big fan of '--state ESTABLISHED,RELATED'. You can cover so may things with that one rule.

Forward chain for instance is as simple as:

Chain FORWARD (policy DROP 543K packets, 48M bytes)
pkts bytes target prot opt in out source destination
4940K 2623M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
220K 20M ACCEPT all -- eth0 eth1 192.168.200.0/24 0.0.0.0/0 state NEW
543K 48M LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FORWARD:'


Anyway.. Fun..

[Ragu_1]

SEP, tnx a lot for the script. Yes, a simple solution is always an elegant solution. I am very sorry if my problem was not conveyed clearly.