Hi, To test the effects of tinyproxy I have started on the firewall PC I did a nessus test via www.vulnerabilities.org. I did the test with and without the tinyproxy and the below comment is bothering me. This was not coming out with the tests I did before at the same site with the same Hardware and Software (SuSE linux 7.1 Kernel 2.2.19). The only change is the ISP is assigning the IP's from a different pool used to be 212.156.196.x now it 212.174.48.x /212.174.49.x) and maybe it has something to do from the ISP end ?? or my misconfiguration of something Security Warning found on port general/tcp The remote host uses non-random IP IDs, that is, it is possible to predict the next value of the ip_id field of the ip packets sent by this host. An attacker may use this feature to determine if the remote host sent a packet in reply to another request. This may be used for portscanning and other things. Solution : Contact your vendor for a patch Risk factor : Low -- Togan Muftuoglu
Hi Togan, On 2001.09.08 13:32:57 +0100 Togan Muftuoglu wrote:
Hi,
To test the effects of tinyproxy I have started on the firewall PC I did a nessus test via www.vulnerabilities.org. I did the test with and without the tinyproxy and the below comment is bothering me. This was not coming out with the tests I did before at the same site with the same Hardware and Software (SuSE linux 7.1 Kernel 2.2.19). The only change is the ISP is assigning the IP's from a different pool used to be 212.156.196.x now it 212.174.48.x /212.174.49.x) and maybe it has something to do from the ISP end ?? or my misconfiguration of something
Security Warning found on port general/tcp
The remote host uses non-random IP IDs, that is, it is possible to predict the next value of the ip_id field of the ip packets sent by this host.
An attacker may use this feature to determine if the remote host sent a packet in reply to another request. This may be used for portscanning and other things.
Solution : Contact your vendor for a patch Risk factor : Low
AFAIK, this refers to the packet ID for tcp/ip packets - so that packets can be re-assembled at the receiving end of an IP connction. The implication is that a new connecton ID can be predicted from previous packets, so a dedicated cracker will be able to spot if the sequence changes and know how many packets you have sent - but IMHO if you are being watched that closely, the cracker has probably already sniffed the packets anyway... :-( Don't know how your changes would cause this - unless there is some setting in /proc somewhere that you have inadvertently [not] changed with the change in your IP pool HTH Maf,
-- Togan Muftuoglu
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Maf. King Standby Exhibition Services ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "It is easier to do a job right than to explain why you didn't." - Martin Van Buren ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* maf king; <maf@cybereye.co.uk> on 08 Sep, 2001 wrote: Hi, Maf
changes and know how many packets you have sent - but IMHO if you are being watched that closely, the cracker has probably already sniffed the packets anyway... :-(
Could it be this sniffing being done at the ISP as we are on dynamic IP's via ADSL pppoe and static IP's will be sometime in two weeks time and I want to secure my connections as much as possible. Everytime the connection drops Ipchains script reconfigures the firewall based on the new IP and the rules are the same except three things icmp 5 now denied for input icmp 13:255 denied for input icmp 14 denied for output -- Togan Muftuoglu
Hi Togan, On 2001.09.08 14:15:05 +0100 Togan Muftuoglu wrote:
changes and know how many packets you have sent - but IMHO if you are being watched that closely, the cracker has probably already sniffed the
* maf king; <maf@cybereye.co.uk> on 08 Sep, 2001 wrote: Hi, Maf packets
anyway... :-(
Could it be this sniffing being done at the ISP as we are on dynamic IP's via ADSL pppoe and static IP's will be sometime in two weeks time and I want to secure my connections as much as possible.
I meant sniffing in general. I wasn't saying that anyone *was actually* sniffing you - (all I can say is I am not ;-) ) What I meant was that if someone can count the packets leaving your box, and see the sequence ID changing, then they would probably be in a position to sniff them anyway, so the non-random ID isn't IMHO a big problem. But yes, your ISP would be a good place to sniff all your traffic, if someone wanted to - but there are other places where this can be done, too - any router which sees your packets can sniff them...
Everytime the connection drops Ipchains script reconfigures the firewall based on the new IP and the rules are the same except three things
icmp 5 now denied for input icmp 13:255 denied for input icmp 14 denied for output
I don't know how to randomise the ip_id field you mentioned in the first mail, but AFAIK changing icmp settings on the firewall won't be the problem (or the cure...) HTH Maf.
-- Togan Muftuoglu
--
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Maf. King Standby Exhibition Services ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "It is easier to do a job right than to explain why you didn't." - Martin Van Buren ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
participants (2)
-
maf king -
Togan Muftuoglu