[Firewall] Vulnerabilities.

[maartenvdv737]

Ik heb laatst een firewall geinstalleerd, en bij security space een check laten doen.

Toen kreeg ik de onderstaande resultaten en die wil ik nu het liefst verhelpen.

code:

10802 OpenSSH < 3.0.1
ssh (22/tcp)

You are running a version of OpenSSH which is older than 3.0.1.

Versions older than 3.0.1 are vulnerable to a flaw in which
an attacker may authenticate, provided that Kerberos V support
has been enabled (which is not the case by default). 
It is also vulnerable a an excessive memory clearing bug, 
believed to be unexploitable.

*** You may ignore this warning if this host is not using
*** Kerberos V

Solution : Upgrade to OpenSSH 3.0.1
Risk factor : Low (if you are not using Kerberos) or High (if kerberos is enabled)

Mijn systeem heeft geen kerberos, dus geen probleem hier.

code:

10267 SSH Server type and version
ssh (22/tcp)
Remote SSH version : ssh-1.99-openssh_2.9p2
This detects the SSH Server's type and version by connecting to the server
and processing the buffer received.
This information gives potential attackers additional information about the
system they are attacking. Versions and Types should be omitted
where possible.

Solution: Change the login banner to something generic (like: 'welcome.')

Risk factor : Low

Wie weet waar de config file staat om de login banner aan te passen? openssh is tijdens de installatie van mandrake 8.1 als rpm geinstalleerd.
Ik heb al gezocht op sshd_config / config

code:

10201 Relative IP Identification number change
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

Lijkt me een beetje overbodig dit, aangezien ik bij @home zit, en dus aan een static IP vastzit. Of begrijp ik het verkeerd?

code:

10114 icmp timestamp request
general/icmp

The remote host answers to an ICMP timestamp
request. This allows an attacker to know the
date which is set on your machine. 

This may help him to defeat all your 
time based authentifications protocols.

Solution : filter out the icmp timestamp
requests (13), and the outgoing icmp 
timestamp replies (14).

Risk factor : Low
CVE : CAN-1999-0524

Ik heb op google gezocht naar het filteren van ICMP. Kan er niets over vinden. In mijn firewall staat hetvolgende:

${IPTABLES} -t filter -A LDROP -p icmp -m limit --limit ${LOG_FLOOD} -j LOG --log-level info --log-prefix "ICMP Dropped "
${IPTABLES} -t filter -A LREJECT -p icmp -m limit --limit ${LOG_FLOOD} -j LOG --log-level info --log-prefix "ICMP Dropped "
${IPTABLES} -t filter -A TREJECT -p udp -j REJECT --reject-with icmp-port-unreachable
${IPTABLES} -t filter -A TREJECT -p icmp -j DROP
${IPTABLES} -t filter -A LTREJECT -p icmp -m limit --limit ${LOG_FLOOD} -j LOG --log-level info --log-prefix "ICMP Dropped "
${IPTABLES} -t filter -A LTREJECT -p udp -j REJECT --reject-with icmp-port-unreachable
${IPTABLES} -t filter -A LTREJECT -p icmp -j DROP
${IPTABLES} -t filter -A INETIN -p icmp --icmp-type echo-request -m limit --limit ${PING_FLOOD} -j ACCEPT
${IPTABLES} -t filter -A INETIN -p icmp --icmp-type echo-request -j ${DROP}
${IPTABLES} -t filter -A INETIN -p icmp --icmp-type ! echo-request -j ACCEPT

Wat moet ik hier nou nog veranderen om die laatste vulnerability te fixen?

code:

10287 Traceroute
general/udp
For your information, here is the traceroute to:

dan een hele lijst met IP's

Makes a traceroute to the remote host.

Kan ik een traceroute naar mijn server uitschakelen?


Alvast bedankt!

[blaataaps]

Dat icmp timestamp gedoe is volgens mij niet echt een vulnerability.
Een traceroute naar je server kan je niet uitschakelen, tenzij je de routers onderweg naar je server in beheer hebt (en dan nog is er niet echt een reden waarom je dat zou doen imo)

[Brahiewahiewa]

Je ken toch gewoon op je firewall uitgaand ICMP verkeer blocken? D'r zijn wel meer redenen om dat te doen.

[maartenvdv737]

Ik heb deze firewall niet zelf geschreven, wat zou ik moeten veranderen om de ICMP te dichten?

Accept --> DENY/DROP/REJECT ?

En welke?

[blaataaps]

Welke redenen dan?
ICMP is niet voor niks uitgevonden en heeft een functie hoor. Sommige ICMP kun je wel droppen ja, maar alle ICMP blocken is ranzig.

[serkoon]

Traceroutes zijn best wel te blocken, door packets met een ttl van 0(?) inkomend tegen te houden. Maar dan ben je wel bezig met dingen te breken, dus misschien niet zo'n goed id.

Verander die versionstring van OpenSSH niet! Veel clients hebben allerlei ingebouwde workarounds voor de buggy implementaties per versie en snappen er niks meer van als die commentstring niet klopt. Misschien dat je met een leeg of onzinnig commentstring (dus bijv. SSH-2.0-BlaatSSH-1.4.3) nog net weg kunt komen, maar iirc konden clients daar ook niet echt goed tegen.

Verder zou ik alle ICMP behalve echo request, dest. unreachable en TTL exceeded inkomend blocken.

[blaataaps]

traceroutes langs jouw bak zijn wel tegen te gaan ja, maar je kan volgens mij niet voorkomen dat er een traceroute naar jouw gedaan word. (je kan bakken die down zijn ook gewoon tracerouten bijvoorbeeld).

[maartenvdv737]

Dan mag ik er dus vanuit gaan dat mijn server zo goed als dicht zit?

[igmar]

Op maandag 28 januari 2002 11:01 schreef maartenvdv het volgende:
Ik heb laatst een firewall geinstalleerd, en bij security space een check laten doen.

Toen kreeg ik de onderstaande resultaten en die wil ik nu het liefst verhelpen.

code:

10802 OpenSSH < 3.0.1
ssh (22/tcp)

You are running a version of OpenSSH which is older than 3.0.1.

Versions older than 3.0.1 are vulnerable to a flaw in which
an attacker may authenticate, provided that Kerberos V support
has been enabled (which is not the case by default). 
It is also vulnerable a an excessive memory clearing bug, 
believed to be unexploitable.

*** You may ignore this warning if this host is not using
*** Kerberos V

Solution : Upgrade to OpenSSH 3.0.1
Risk factor : Low (if you are not using Kerberos) or High (if kerberos is enabled)

Mijn systeem heeft geen kerberos, dus geen probleem hier.

Wel een probleem aangezien < 3.0.1 met SSH1 te rooten is. Oplossing is upgrade of SSH1 uitzetten (CRC32 exploit)

10267 SSH Server type and version
ssh (22/tcp)
Remote SSH version : ssh-1.99-openssh_2.9p2
This detects the SSH Server's type and version by connecting to the server
and processing the buffer received.
This information gives potential attackers additional information about the
system they are attacking. Versions and Types should be omitted
where possible.

Solution: Change the login banner to something generic (like: 'welcome.')

Risk factor : Low [/code]
Wie weet waar de config file staat om de login banner aan te passen? openssh is tijdens de installatie van mandrake 8.1 als rpm geinstalleerd.
Ik heb al gezocht op sshd_config / config

/etc/issue.net

code:

10201 Relative IP Identification number change
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

Lijkt me een beetje overbodig dit, aangezien ik bij @home zit, en dus aan een static IP vastzit. Of begrijp ik het verkeerd?

Ja. Het is in theorie mogelijk een sessie te hijacken als je de sequencenummers kan gokken. In de praktijk zal dat wel mevallen.[quote]
10114 icmp timestamp request
general/icmp

The remote host answers to an ICMP timestamp
request. This allows an attacker to know the
date which is set on your machine.

This may help him to defeat all your
time based authentifications protocols.

Solution : filter out the icmp timestamp
requests (13), and the outgoing icmp
timestamp replies (14).

Risk factor : Low
CVE : CAN-1999-0524[/code]
Ik heb op google gezocht naar het filteren van ICMP. Kan er niets over vinden. In mijn firewall staat hetvolgende:

${IPTABLES} -t filter -A LDROP -p icmp -m limit --limit ${LOG_FLOOD} -j LOG --log-level info --log-prefix "ICMP Dropped "
${IPTABLES} -t filter -A LREJECT -p icmp -m limit --limit ${LOG_FLOOD} -j LOG --log-level info --log-prefix "ICMP Dropped "
${IPTABLES} -t filter -A TREJECT -p udp -j REJECT --reject-with icmp-port-unreachable
${IPTABLES} -t filter -A TREJECT -p icmp -j DROP
${IPTABLES} -t filter -A LTREJECT -p icmp -m limit --limit ${LOG_FLOOD} -j LOG --log-level info --log-prefix "ICMP Dropped "
${IPTABLES} -t filter -A LTREJECT -p udp -j REJECT --reject-with icmp-port-unreachable
${IPTABLES} -t filter -A LTREJECT -p icmp -j DROP
${IPTABLES} -t filter -A INETIN -p icmp --icmp-type echo-request -m limit --limit ${PING_FLOOD} -j ACCEPT
${IPTABLES} -t filter -A INETIN -p icmp --icmp-type echo-request -j ${DROP}
${IPTABLES} -t filter -A INETIN -p icmp --icmp-type ! echo-request -j ACCEPT

Wat moet ik hier nou nog veranderen om die laatste vulnerability te fixen?
[quote]

-t filter -A INETIN -p icmp --icmp-type 13 -j DROP
en ook 14

code:

10287 Traceroute
general/udp
For your information, here is the traceroute to:

dan een hele lijst met IP's

Makes a traceroute to the remote host.

Kan ik een traceroute naar mijn server uitschakelen?

Niet. Ze kunnen altijd tot de laatste hop komen aangezien deze info gewoon van de tussenliggende systemen komt. traceroute uitschakelen voor de laatste hop is wel te doen, maar heeft geen toegevoegde waarde. (aangezien het toch de laatste hop is)

[maartenvdv737]

Waar kan ik ssh1 uitschakelen dan?

Zoals ik al zei, kan ik geen config bestand van sshd vinden.

[Verwijderd]

/etc/ssh/sshd_config ??

[Verwijderd]

Op maandag 28 januari 2002 11:46 schreef blaataaps het volgende:
Welke redenen dan?
ICMP is niet voor niks uitgevonden en heeft een functie hoor. Sommige ICMP kun je wel droppen ja, maar alle ICMP blocken is ranzig.

Gewoon een limit erop zetten bv:

code:

-m limit --limit 1/second

voor je ICMP ECHO rule. Dan kunnen ze je al niet meer gaan ping flooden e.d.

Ivm die non-randomized IP ID's installeer je best de grsecurity kernel patch (http://www.grsecurity.net). Die heeft een hele boel leuke opties zoals:
- randomized pid's (volgen de process id's elkaar niet op, handig om te voorkomen dat mensen gaan gokken op welk pid een daemon draait)
- randomized ip id's (anti-os-detection via portscans en dus die attack zoals jij al copy/paste)
- fork-bomb protection (local DoS die al je resources in beslag neemt)
- restricted /proc (dan kan een user alleen zijn eigen processes zien en dus niet welke daemons er allemaal runnen)
- root access verbieden via bepaalde interfaces (dus bv. alleen via de console en niet via een ssh of seriele sessie)
- ACL (Access Control Lists), redelijk complex systeem waarmee je ver gevorderde controle over de hardware access van je systeem kunt krijgen zodat zelfs root niets kan veranderen nadat er een 'switch' omgezet is geworden.
- etc...

Grsecurity bevat code die vroeger in de openwall patch zat (die zullen sommigen wel kennen) maar is nu dus opgenomen in de GR patch en is bedoeld voor de 2.4 kernel.

Een must voor elke 2.4 user imo !