Postfix+PortSentry

Postfix, QMail, Sendmail, Dovecot, Cyrus, Courier, Anti-Spam
Sponge
Posts: 34
Joined: 2011-01-10 16:55

Postfix+PortSentry

Post by Sponge » 2011-01-10 17:08

Hallo und guten Tag,

ich habe eine kleine Herausforderung, seit neustem habe ich auf meinem Server PortSentry installiert un es funktioniert auch super.

Nach einer gewissen Zeit jedoch gibt Postfix seinen Geist auf und schickt keine Mails mehr raus.

Wenn ich Beispielsweise mir eine Mail schicken will:
Jan 9 19:16:10 ip-174-142-75-57 postfix/smtp[15157]: 22EC185A089: to=<meinemail@gmx.de>, relay=none, delay=0.04, delays=0.03/0.01/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=gmx.de type=MX: Host not found, try again)


Nachdem ich PortSentry deaktiviert habe seit einen kompletten reboot läuft alles also schätze ich mal es ist eine Einstellungssache ich PortSentry?

Code: Select all

# PortSentry Configuration
#
# $Id: portsentry.conf.Debian,v 1.6 2001/07/19 21:02:20 agx Exp $
#
# Original portsentry.conf by Craig H. Rowland <crowland@psionic.com>
# modified for Debian by Guido Guenther <agx@debian.org>
#
# IMPORTANT NOTE: You CAN NOT put spaces between your port arguments.
#
# The default ports will catch a large number of common probes
#
# All entries must be in quotes.


#######################
# Port Configurations #
#######################
#
#
# Some example port configs for classic and basic Stealth modes
#
# I like to always keep some ports at the "low" end of the spectrum.
# This will detect a sequential port sweep really quickly and usually
# these ports are not in use (i.e. tcpmux port 1)
#
# ** X-Windows Users **: If you are running X on your box, you need to be sure
# you are not binding PortSentry to port 6000 (or port 2000 for OpenWindows users).
# Doing so will prevent the X-client from starting properly.
#
# These port bindings are *ignored* for Advanced Stealth Scan Detection Mode.
#

# Un-comment these if you are really anal:
#TCP_PORTS="1,7,9,11,15,70,79,80,109,110,111,119,138,139,143,512,513,514,515,540,635,1080,1524,2000,2001,4000,4001,5742,6000,6001,6667,12345,12346,20034,27665,30303,32771,32772,32773,32774,31337,40421,40425,49724,54320"
#UDP_PORTS="1,7,9,66,67,68,69,111,137,138,161,162,474,513,517,518,635,640,641,666,700,2049,31335,27444,34555,32770,32771,32772,32773,32774,31337,54321"
#
# Use these if you just want to be aware:
#TCP_PORTS="1,11,15,79,111,119,143,540,635,1080,1524,2000,5742,6667,12345,12346,20034,27665,31337,32771,32772,32773,32774,40421,49724,54320"
#UDP_PORTS="1,7,9,69,161,162,513,635,640,641,700,37444,34555,31335,32770,32771,32772,32773,32774,31337,54321"
#
# Use these for just bare-bones
TCP_PORTS="1,11,15,110,21,22,111,143,540,443,3306,1501,1500,10000,635,1080,1524,2000,12345,12346,20034,32771,32772,32773,32774,49724,54320"
UDP_PORTS="1,7,9,69,161,162,513,640,700,32770,32771,32772,32773,32774,31337,54321"

###########################################
# Advanced Stealth Scan Detection Options #
###########################################
#
# This is the number of ports you want PortSentry to monitor in Advanced mode.
# Any port *below* this number will be monitored. Right now it watches
# everything below 1024.
#
# On many Linux systems you cannot bind above port 61000. This is because
# these ports are used as part of IP masquerading. I don't recommend you
# bind over this number of ports. Realistically: I DON'T RECOMMEND YOU MONITOR
# OVER 1024 PORTS AS YOUR FALSE ALARM RATE WILL ALMOST CERTAINLY RISE. You've been
# warned! Don't write me if you have have a problem because I'll only tell
# you to RTFM and don't run above the first 1024 ports.
#
#
ADVANCED_PORTS_TCP="1024"
ADVANCED_PORTS_UDP="1024"
#
# This field tells PortSentry what ports (besides listening daemons) to
# ignore. This is helpful for services like ident that services such
# as FTP, SMTP, and wrappers look for but you may not run (and probably
# *shouldn't* IMHO).
#
# By specifying ports here PortSentry will simply not respond to
# incoming requests, in effect PortSentry treats them as if they are
# actual bound daemons. The default ports are ones reported as
# problematic false alarms and should probably be left alone for
# all but the most isolated systems/networks.
#
# Default TCP ident and NetBIOS service
ADVANCED_EXCLUDE_TCP="113,139,25"
# Default UDP route (RIP), NetBIOS, bootp broadcasts.
ADVANCED_EXCLUDE_UDP="520,138,137,67"


######################
# Configuration Files#
######################
#
# Hosts to ignore
IGNORE_FILE="/etc/portsentry/portsentry.ignore"
# Hosts that have been denied (running history)
HISTORY_FILE="/var/lib/portsentry/portsentry.history"
# Hosts that have been denied this session only (temporary until next restart)
BLOCKED_FILE="/var/lib/portsentry/portsentry.blocked"

##############################
# Misc. Configuration Options#
##############################
#
# DNS Name resolution - Setting this to "1" will turn on DNS lookups
# for attacking hosts. Setting it to "0" (or any other value) will shut
# it off.
RESOLVE_HOST = "1"

###################
# Response Options#
###################
# Options to dispose of attacker. Each is an action that will
# be run if an attack is detected. If you don't want a particular
# option then comment it out and it will be skipped.
#
# The variable $TARGET$ will be substituted with the target attacking
# host when an attack is detected. The variable $PORT$ will be substituted
# with the port that was scanned.
#
##################
# Ignore Options #
##################
# These options allow you to enable automatic response
# options for UDP/TCP. This is useful if you just want
# warnings for connections, but don't want to react for 
# a particular protocol (i.e. you want to block TCP, but
# not UDP). To prevent a possible Denial of service attack
# against UDP and stealth scan detection for TCP, you may
# want to disable blocking, but leave the warning enabled.
# I personally would wait for this to become a problem before
# doing though as most attackers really aren't doing this.
# The third option allows you to run just the external command
# in case of a scan to have a pager script or such execute
# but not drop the route. This may be useful for some admins
# who want to block TCP, but only want pager/e-mail warnings
# on UDP, etc.
#
#
# 0 = Do not block UDP/TCP scans.
# 1 = Block UDP/TCP scans.
# 2 = Run external command only (KILL_RUN_CMD)

BLOCK_UDP="1"
BLOCK_TCP="1"

###################
# Dropping Routes:#
###################
# This command is used to drop the route or add the host into
# a local filter table.
#
# The gateway (333.444.555.666) should ideally be a dead host on
# the *local* subnet. On some hosts you can also point this at
# localhost (127.0.0.1) and get the same effect. NOTE THAT
# 333.444.555.66 WILL *NOT* WORK. YOU NEED TO CHANGE IT!!
#
# ALL KILL ROUTE OPTIONS ARE COMMENTED OUT INITIALLY. Make sure you
# uncomment the correct line for your OS. If you OS is not listed
# here and you have a route drop command that works then please
# mail it to me so I can include it. ONLY ONE KILL_ROUTE OPTION
# CAN BE USED AT A TIME SO DON'T UNCOMMENT MULTIPLE LINES.
#
# NOTE: The route commands are the least optimal way of blocking
# and do not provide complete protection against UDP attacks and
# will still generate alarms for both UDP and stealth scans. I
# always recommend you use a packet filter because they are made
# for this purpose.
#

# Generic
#KILL_ROUTE="/sbin/route add $TARGET$ 333.444.555.666"

# Generic Linux
#KILL_ROUTE="/sbin/route add -host $TARGET$ gw 333.444.555.666"

# Newer versions of Linux support the reject flag now. This
# is cleaner than the above option.
KILL_ROUTE="/sbin/route add -host $TARGET$ reject"

# Generic BSD (BSDI, OpenBSD, NetBSD, FreeBSD)
#KILL_ROUTE="/sbin/route add $TARGET$ 333.444.555.666"

# Generic Sun
#KILL_ROUTE="/usr/sbin/route add $TARGET$ 333.444.555.666 1"

# NEXTSTEP
#KILL_ROUTE="/usr/etc/route add $TARGET$ 127.0.0.1 1"

# FreeBSD
#KILL_ROUTE="route add -net $TARGET$ -netmask 255.255.255.255 127.0.0.1 -blackhole"

# Digital UNIX 4.0D (OSF/1 / Compaq Tru64 UNIX)
#KILL_ROUTE="/sbin/route add -host -blackhole $TARGET$ 127.0.0.1"

# Generic HP-UX
#KILL_ROUTE="/usr/sbin/route add net $TARGET$ netmask 255.255.255.0 127.0.0.1"

##
# Using a packet filter is the PREFERRED. The below lines
# work well on many OS's. Remember, you can only uncomment *one*
# KILL_ROUTE option.
##

# ipfwadm support for Linux
#KILL_ROUTE="/sbin/ipfwadm -I -i deny -S $TARGET$ -o"
#
# ipfwadm support for Linux (no logging of denied packets)
#KILL_ROUTE="/sbin/ipfwadm -I -i deny -S $TARGET$"
#
# ipchain support for Linux
#KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l"
#
# ipchain support for Linux (no logging of denied packets)
KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY"
#
# iptables support for Linux
KILL_ROUTE="/sbin/iptables -I INPUT -s $TARGET$ -j DROP"
#
# iptables support for Linux with limit and LOG support. Logs only
# a limited number of packets to avoid a denial of service attack.
# KILL_ROUTE="/sbin/iptables -I INPUT -s $TARGET$ -j DROP && /sbin/iptables -I INPUT -s $TARGET$ -m limit --limit 3/minute --limit-burst 5 -j LOG --log-level DEBUG --log-prefix 'Portsentry: dropping: '"
#
# For those of you running FreeBSD (and compatible) you can
# use their built in firewalling as well.
#
#KILL_ROUTE="/sbin/ipfw add 1 deny all from $TARGET$:255.255.255.255 to any"
#
#
# For those running ipfilt (OpenBSD, etc.)
# NOTE THAT YOU NEED TO CHANGE external_interface TO A VALID INTERFACE!!
#
#KILL_ROUTE="/bin/echo 'block in log on external_interface from $TARGET$/32 to any' | /sbin/ipf -f -"


###############
# TCP Wrappers#
###############
# This text will be dropped into the hosts.deny file for wrappers
# to use. There are two formats for TCP wrappers:
#
# Format One: Old Style - The default when extended host processing
# options are not enabled.
#
#KILL_HOSTS_DENY="ALL: $TARGET$"

# Format Two: New Style - The format used when extended option
# processing is enabled. You can drop in extended processing
# options, but be sure you escape all '%' symbols with a backslash
# to prevent problems writing out (i.e. \%c \%h )
#
KILL_HOSTS_DENY="ALL: $TARGET$ : DENY"

###################
# External Command#
###################
# This is a command that is run when a host connects, it can be whatever
# you want it to be (pager, etc.). This command is executed before the
# route is dropped or after depending on the KILL_RUN_CMD_FIRST option below
#
#
# I NEVER RECOMMEND YOU PUT IN RETALIATORY ACTIONS AGAINST THE HOST SCANNING
# YOU!
#
# TCP/IP is an *unauthenticated protocol* and people can make scans appear out
# of thin air. The only time it is reasonably safe (and I *never* think it is
# reasonable) to run reverse probe scripts is when using the "classic" -tcp mode.
# This mode requires a full connect and is very hard to spoof.
#
# The KILL_RUN_CMD_FIRST value should be set to "1" to force the command
# to run *before* the blocking occurs and should be set to "0" to make the
# command run *after* the blocking has occurred.
#
#KILL_RUN_CMD_FIRST = "0"
#
#
#KILL_RUN_CMD="/some/path/here/script $TARGET$ $PORT$ $MODE$"
# for examples see /usr/share/doc/portsentry/examples/


#####################
# Scan trigger value#
#####################
# Enter in the number of port connects you will allow before an
# alarm is given. The default is 0 which will react immediately.
# A value of 1 or 2 will reduce false alarms. Anything higher is
# probably not necessary. This value must always be specified, but
# generally can be left at 0.
#
# NOTE: If you are using the advanced detection option you need to
# be careful that you don't make a hair trigger situation. Because
# Advanced mode will react for *any* host connecting to a non-used
# port below your specified range, you have the opportunity to
# really break things. (i.e someone innocently tries to connect to
# you via SSL [TCP port 443] and you immediately block them). Some
# of you may even want this though. Just be careful.
#
SCAN_TRIGGER="0"

######################
# Port Banner Section#
######################
#
# Enter text in here you want displayed to a person tripping the PortSentry.
# I *don't* recommend taunting the person as this will aggravate them.
# Leave this commented out to disable the feature
#
# Stealth scan detection modes don't use this feature
#
#PORT_BANNER="** UNAUTHORIZED ACCESS PROHIBITED *** YOUR CONNECTION ATTEMPT HAS BEEN LOGGED. GO AWAY."

# EOF


Das ganze läuft im stcp und sudp Modus.

Ich hoffe ihr könnt mir helfen? :?

User avatar
rudelgurke
Systemtester
Systemtester
Posts: 400
Joined: 2008-03-12 05:36

Re: Postfix+PortSentry

Post by rudelgurke » 2011-01-10 18:18

Erstmal willkommen :)

Tja - netter SelfDoS kann man nur sagen. Nach der Meldung klemmt es beim DNS und wenn es da klemmt sperrt die Kiste die eigenen DNS Server.
Die in die Whitelist nehmen oder ganz auf Portsentry verzichten - bzw. nur im Logging Modus betreiben.

Warum Hosts sperren die ohnehin Ports scannen auf denen entweder etwas lauscht und lauschen soll oder eben nicht lauscht ? Ergebnis ist für den jeweiligen Angreifer das Gleiche.
Und Scans auf diverse Ports von Remote Verwaltungstools (Plesk etc.) oder Orcacle DB Admin, MySQL usw. usw. sind - leider - recht normal. Solange dasss ohnehin nicht läuft braucht man auch den Port nicht dichtmachen.

Snort oder Bro ist vielleicht die bessere Wahl um derartige Angriffe zu loggen ohne gleich das komplette System dicht zu machen.

Achso - bitte die Kommentare entfernen - macht die Dinge etwas übersichtlicher. Danke :)
Last edited by rudelgurke on 2011-01-10 18:19, edited 1 time in total.

Sponge
Posts: 34
Joined: 2011-01-10 16:55

Re: Postfix+PortSentry

Post by Sponge » 2011-01-10 18:55

Hallo und Danke für das Wilkommen,

ok das mit den Kommentaren leuchtet ein und wird beachtet. =)
Hmm wegen der Whitelist, da hängts bei mir gerade...
Meinst du bei PortSentry die eintragen oder wo? Weil der legt ja automatisch 2 Files an und in dem einen "portsentry.ignore" hat er meine + weitere mit anderer Endung hinzugefügt.

Ich bin da leider nicht so der Profi :-/ Daher muss ich nochmal Fragen..

User avatar
Joe User
Project Manager
Project Manager
Posts: 11583
Joined: 2003-02-27 01:00
Location: Hamburg

Re: Postfix+PortSentry

Post by Joe User » 2011-01-10 19:58

Ich mache es mal kurz und direkt: PortSentry ist uralt, wird nicht mehr supportet, erzeugt mehr Probleme als es Nutzen bringt und ist letztendlich unnütz, da ein Port auf dem kein Dienst lauscht auch nicht geschützt werden muss. Desweiteren sind heutige Portscanner und vergleichbare Tools schlau genug um PortSentry und Co auszutricksen.

Verzichte lieber auf den Mist und konfiguriere Deine Dienste vernünftig, das ist erheblich effektiver und letztendlich auch sicherer.
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

Sponge
Posts: 34
Joined: 2011-01-10 16:55

Re: Postfix+PortSentry

Post by Sponge » 2011-01-10 20:05

Hmm naja, also da sind schon ein paar Ports welche ich gerne schützen würde via PortSentry zbs MySql den Apache usw. Ich empfinde PS als sehr effektiv :-/ wie trickst man es denn aus? Also egal was ich mache, er bannt meine IP und Ports wirft er halt garkeine aus. Von daher erfüllt es für mich einen Zweck, mal abgesehen von der Mailsache. Ich habe in der Whitelist von PS mal zwei Ip´s hinzugefügt welche vom Anbieter sind und bisher immer geblockt wurden, des weiteren hab ich beim Dyndns den Mailsupport aktiviert und eingetragen. In der Hoffung das eine dieser Maßnahmen dazu führt das die Mails auch nach der "gewissen" Zeit immernoch rausgehen.

Falls ich eine Maßnahme vergessen hab oder deinen 1. Tipp falsch interpretiert habe würde es mich freuen wenn du dich dazu nochmal äusserst, auch wenn ich aus deinem Text herauslese das du kein großer PortSentry Fan bist. :)

Danke

User avatar
rudelgurke
Systemtester
Systemtester
Posts: 400
Joined: 2008-03-12 05:36

Re: Postfix+PortSentry

Post by rudelgurke » 2011-01-10 20:23

MySQL schützt man am besten wenn es erst garnicht am externen Interface lauscht.
Braucht man dass für Replica oder ähnliches, SSH Tunnel, VPN - gibt genügend Auswahl.
Und für den Indianer gibt es mod_security.
Davon abgesehen dass es gegen Bots die 1-2 Ports scannen, dann übernimmt der nächste Bot, es wohl relativ wenig bringt.
Ist so ähnlich wie Fail2ban und SSH - ordentlich eingerichtet braucht man kein Fail2ban da SSH von Haus aus interaktive Loginversuche als root ablehnt.
Und eine Uralt Version von "schlechtes Script xyz" im Webroot kann Portsentry oder die Firewall nicht schützen, es sei denn man macht Port 80 zu. Ist man zwar geschützt, aber der Kunde wundert sich warum sein Webmail nicht mehr funktioniert.
Zu der Whitelist - die Einträge aus der resolv.conf übernehmen und damit die DNS Server.
Der Fehler von Postfix deutet darauf hin dass Postfix die DNS Namen nicht auflösen kann, sollte also Portsentry sein welches hier die DNS Server (vom Anbieter) blockt.

Zum Austricksen - nmap z. Bsp. bietet da diverse Optionen. Anstatt ein "closed" kommt halt ein "filtered" als Antwort. Ergebnis ist das Gleiche - der potentielle Angreifer weiß was er will.
Last edited by rudelgurke on 2011-01-10 20:27, edited 1 time in total.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11583
Joined: 2003-02-27 01:00
Location: Hamburg

Re: Postfix+PortSentry

Post by Joe User » 2011-01-10 20:27

Ja, ich halte von PortSentry, DenyHosts, fail2ban und Co absolut gar nichts. Eine vernünftige Konfiguration ist nahezu immer gleich effektiv oder gar effektiver als diese dubiosen Tools. Mir ist bisher noch kein Szenario begegnet, wo der Einsatz dieser Tools sinnvoll wäre.

MySQL bindest Du einfach an 127.0.0.1 und schon brauchst Du hierfür kein PortSentry mehr. Beim Apache willst Du ja das die Websites abgerufen werden können, also willst Du hier kein PortSentry, gleiches gilt für Postfix und Deinen IMAP/POP3-Server, sowie für SSH. Alle anderen Ports sind bei einem Standard-LAMP sowieso geschlossen und müssten somit auch nicht von PortSentry "geschützt" werden. Etwas das nicht vorhanden ist muss nicht geschützt werden...

Wovor willst Du Dein System mit PortSentry überhaupt schützen?
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

Sponge
Posts: 34
Joined: 2011-01-10 16:55

Re: Postfix+PortSentry

Post by Sponge » 2011-01-10 21:11

Ah na super, genau das hatte ich gemacht mit den Ip´s aus der resolv.conf =). Das waren nämlich genau die IP´s welche andauernd gebannt wurden .... ich hab da mal nachgeguckt wo die so alle herkommen und dann is mir das aufgefallen. Naja viele Wege führen nach Rom, ich hoffe das es jetzt funktionierend bleibt.

Zu den anderen angesprochen Sachen, diesen mod_security werde ich mir mal näher angucken.

Wovor ich das schützen will?
Naja gegen die ganzen Scriptkiddys und möchtegern Hacker... Zudem soll nicht unbedingt jeder sehen was an Diensten darauf läuft, um einfach angriffsmöglichkeiten vorweg zu nehmen.
Wegen nmap, ich hab das bei mir jetzt so das er rein garnichts anzeigt an Ports, also kein closed, filterd oder ähnliches .. einfach nix ^^

Des weiteren werd ich mich mal bisschen im Security Forum belesen weil da steht ja auch ne Menge hab ich gesehen.

Und da einem hier auch geholfen wird bleib ich hier xD

Ich Danke euch, sollte nochmal was zu dem Thema sein werd ichs posten.

Grüße
Last edited by Sponge on 2011-01-10 21:11, edited 1 time in total.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11583
Joined: 2003-02-27 01:00
Location: Hamburg

Re: Postfix+PortSentry

Post by Joe User » 2011-01-10 21:58

Bezüglich nmap: nix = filtered = nützliche information

Das ein Webserver läuft ist logisch, da Webseiten angezeigt werden können.
Das ein Mailserver läuft ist logisch, da Mails angenommen werden können.
Das ein IMAPd/POP3d läuft ist logisch, da Mails abgeholt werden können.
Damit sind die laufenden Dienste bereits bekannt.

Das bekommt jedes Script-Kiddie und jeder Möchtegern-Hacker ganz ohne Portscan raus, Telnet reicht. Wovor wolltest Du die Kiste nochmal schützen?

Das ist ein Server der die Dienste öffentlich anbieten soll und kein Desktop der keine öffentlichen Dienste anbieten darf. Nahezu Alles was Du über Desktop-Security weisst, kannst Du bezüglich Servern schlicht vergessen.
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

Sponge
Posts: 34
Joined: 2011-01-10 16:55

Re: Postfix+PortSentry

Post by Sponge » 2011-01-10 23:22

Das ein Webserver läuft ist logisch, da Webseiten angezeigt werden können.

-Muss nicht, je nach Verwendungszweck-

Das ein Mailserver läuft ist logisch, da Mails angenommen werden können.

-Wenn dann verschickt er nur, annehmen tut er nicht-

Wovor wolltest Du die Kiste nochmal schützen?

-Im besten Fall vor allen-

Das ist ein Server der die Dienste öffentlich anbieten soll...

-Nein!-

Ja ich muss mich da noch ein bisschen belesen zu, Desktop Security? Antivierenprogramm und Windoof Firewall... reicht xD

Sponge
Posts: 34
Joined: 2011-01-10 16:55

Re: Postfix+PortSentry

Post by Sponge » 2011-01-10 23:35

Und da werde ich mich auch genaustens umschauen =)

Danke nochmal, Grüße