lastb | awk '/ssh/ {printf("%s\t%s\t%s\n", $1, $2, $3);}' | sort -u
aja ssh:notty 95.181.188.200
brr ssh:notty 129.211.185.246
cfz ssh:notty 111.231.62.191
cgf ssh:notty 201.48.192.60
ckq ssh:notty 114.207.139.203
fsp ssh:notty 120.48.12.77
hye ssh:notty 111.231.62.191
jgr ssh:notty 106.52.105.178
job ssh:notty 106.53.114.90
jxf ssh:notty 165.227.52.184
ktg ssh:notty 165.227.52.184
lhsm ssh:notty 118.25.182.118
llw ssh:notty 116.177.20.50
lzc ssh:notty 180.76.249.74
mgh ssh:notty 106.12.73.198
mho ssh:notty 61.32.6.30
mmp ssh:notty 81.71.147.245
mrlh ssh:notty 167.172.133.221
mrph ssh:notty 106.75.214.72
mrtx ssh:notty 165.22.14.228
mzx ssh:notty 203.195.144.114
oab ssh:notty 51.81.34.189
pth ssh:notty 165.22.14.228
qcz ssh:notty 95.181.188.200
qkm ssh:notty 209.141.34.47
qwz ssh:notty 103.232.120.109
qxy ssh:notty 203.195.144.114
root ssh:notty 102.164.108.43
root ssh:notty 103.207.11.6
root ssh:notty 106.13.182.41
root ssh:notty 106.38.158.131
root ssh:notty 106.53.92.254
root ssh:notty 106.55.4.113
root ssh:notty 110.45.155.101
root ssh:notty 111.74.11.82
root ssh:notty 118.70.170.120
root ssh:notty 118.89.241.214
root ssh:notty 119.28.88.198
root ssh:notty 122.152.220.161
root ssh:notty 124.152.118.131
root ssh:notty 125.99.72.27
root ssh:notty 128.199.141.33
root ssh:notty 128.199.99.204
root ssh:notty 14.225.27.88
root ssh:notty 149.129.39.164
root ssh:notty 157.230.122.80
root ssh:notty 159.203.82.179
root ssh:notty 159.89.82.134
root ssh:notty 165.84.180.12
root ssh:notty 167.172.138.176
root ssh:notty 167.99.224.27
root ssh:notty 178.128.248.121
root ssh:notty 188.187.108.131
root ssh:notty 200.159.91.130
root ssh:notty 202.61.135.122
root ssh:notty 203.189.253.170
root ssh:notty 218.89.222.16
root ssh:notty 36.112.172.125
root ssh:notty 43.226.69.103
root ssh:notty 45.55.189.252
root ssh:notty 51.68.44.154
root ssh:notty 58.87.72.225
root ssh:notty 59.111.89.240
root ssh:notty 66.249.155.245
root ssh:notty 91.126.18.130
root ssh:notty 95.181.131.153
smcx ssh:notty 61.32.6.30
stzz ssh:notty 165.232.65.66
xfo ssh:notty 118.24.158.42
xxf ssh:notty 106.53.249.98
xxw ssh:notty 51.81.34.189
yhp ssh:notty 119.45.60.204
zxl ssh:notty 129.211.91.213
zzzy ssh:notty 64.227.96.133
Ez egyetlen nap. Nem szerver. Desktop gép.
- 2654 megtekintés
Hozzászólások
95.181.188.200
country: EU # Country is really world wide
129.211.185.246
country: CN
country: CN
country: ZZ
country: CN
111.231.62.191
country: CN
country: CN
country: CN
country: CN
201.48.192.60
country: BR
country: BR
country: BR
country: BR
114.207.139.203
country: KR
country: KR
country: KR
country: KR
120.48.12.77
country: CN
country: CN
111.231.62.191
country: CN
country: CN
country: CN
country: CN
106.52.105.178
country: CN
country: CN
country: CN
country: CN
106.53.114.90
country: CN
country: CN
country: CN
country: CN
165.227.52.184
165.227.52.184
118.25.182.118
country: CN
country: CN
country: ZZ
country: CN
116.177.20.50
country: CN
country: CN
country: CN
180.76.249.74
country: CN
country: CN
country: CN
country: CN
106.12.73.198
country: CN
country: CN
country: CN
country: CN
61.32.6.30
country: KR
country: KR
country: KR
country: KR
81.71.147.245
country: EU # Country is really world wide
167.172.133.221
country: US
106.75.214.72
country: CN
country: CN
165.22.14.228
203.195.144.114
country: CN
country: CN
country: CN
country: CN
51.81.34.189
country: EU # Country is really world wide
165.22.14.228
95.181.188.200
country: EU # Country is really world wide
209.141.34.47
103.232.120.109
country: VN
country: VN
country: VN
203.195.144.114
country: CN
country: CN
country: CN
country: CN
102.164.108.43
country: ZA
country: ZA
103.207.11.6
country: IN
country: IN
106.13.182.41
country: CN
country: CN
country: CN
country: CN
106.38.158.131
country: CN
country: cn
106.53.92.254
country: CN
country: CN
country: CN
country: CN
106.55.4.113
country: CN
country: CN
country: CN
country: CN
110.45.155.101
country: KR
country: KR
country: KR
country: KR
country: KR
111.74.11.82
country: CN
country: CN
118.70.170.120
country: vn
country: VN
country: VN
118.89.241.214
country: CN
country: CN
country: CN
country: CN
119.28.88.198
country: HK
country: CN
country: CN
122.152.220.161
country: CN
country: CN
country: CN
country: CN
124.152.118.131
country: CN
country: CN
country: CN
country: CN
125.99.72.27
country: IN
country: IN
country: IN
country: IN
128.199.141.33
country: US
128.199.99.204
country: US
14.225.27.88
country: VN
country: VN
149.129.39.164
country: SG
country: SG
157.230.122.80
159.203.82.179
159.89.82.134
165.84.180.12
country: HK
country: HK
country: ZZ
country: HK
167.172.138.176
country: US
167.99.224.27
178.128.248.121
country: NL
188.187.108.131
country: RU
200.159.91.130
country: BR
country: BR
country: BR
country: BR
202.61.135.122
country: HK
country: HK
203.189.253.170
country: IN
country: IN
218.89.222.16
country: CN
country: CN
country: CN
36.112.172.125
country: CN
country: CN
43.226.69.103
country: CN
country: CN
country: CN
45.55.189.252
51.68.44.154
country: FR
58.87.72.225
country: CN
country: CN
country: CN
country: CN
59.111.89.240
country: CN
country: CN
66.249.155.245
91.126.18.130
country: ES
95.181.131.153
country: RU
61.32.6.30
country: KR
country: KR
country: KR
country: KR
165.232.65.66
118.24.158.42
country: CN
country: CN
country: ZZ
country: CN
106.53.249.98
country: CN
country: CN
country: CN
country: CN
51.81.34.189
country: EU # Country is really world wide
119.45.60.204
country: CN
country: CN
country: CN
129.211.91.213
country: CN
country: CN
country: ZZ
country: CN
64.227.96.133
- A hozzászóláshoz be kell jelentkezni
Gondolom, megfertőztek egy rakás gépet, és zombi csordák automatikusan szimatolnak törhető gépek után a világ minden tájáról.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Pár napja teszt notimon teszteltem. PPPoE -n kapott publikus -t, 1 perc alatt 2 helyről léptek be rá ssh-n. :D
Pár éve ehhez 5-10 perc kellett. sok éve meg 1-2 nap.
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Nem vagyok tőle boldog. Szokták támadni a gépet, de ez most 1000/nap fölött van már. Egy másik gépen 1800/nap úgy, hogy a gép csak néhány órát volt bekapcsolva, valamint az ssh nem a 22-es porton van egyik gépen sem. Korábbi támadások megálltak néhány tíz, néhány száznál egy hét alatt. Mi a fene van most?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Nincsen semmi, csak a szokasos :D A sok gigabites net, eros gep/telefon stb. Pár hónapja olvastam, hogy egy erős geppel 10GbE-n vagy valami ilyesmi pár pers alatt végig lehet scannelni az egész ipv4 tartományt :D
ipv6-on ez még jóval tovább tart :D
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Nálunk az egyik családtag "WD TV Media Player-t" + my cloud-t teljesen le kellett tiltani. A gigabites neten és belső hálón, akkora forgalmat csinált, hogy az összes többi gép IP-t sem kapott a dhcp-től.
"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett"
és 100 éve még boszorkányt is égettek
- A hozzászóláshoz be kell jelentkezni
ohh, ugyan. Webszerver, honeypot: kb masodpercenként 80-100 csatlakozas ssh-ra, orankent kb 1500 uj ip cimmel gazdagodik a tuzfal
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Hízlalod vele a tűzfalad? Ha jól sejtem, a fail2ban való erre.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
honeypot és az ebből jövő eredményt elosztottan kezelem (több szerverre is felkerül az adott ip cím)
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Van arra valami szabály, táblázat, hogy magyarországi szolgáltatók - az összes lehetséges - milyen IP-tartományból oszt címeket? Mert ha igen, csinálnék egy allow list-et, aztán mindenki más már a router-ről lepattanna, országon belülről meg be tudnék ssh-zni a gépre. Akkor is támadható maradnék, csak jelentősen megcsappanna ezek száma.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Port knocking?
- A hozzászóláshoz be kell jelentkezni
A geoip kifejezésre guglizz
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
iptables geoip modulja pont erre jó
Az erre alkalmas geoip adatbázis régebben a maxmind-től ingyen leszedhető volt, valamit azóta tekertek a dolgon.
összerakás után kb. ennyi az egész:
iptables -A INPUT -m geoip --source-country HU -j ACCEPT
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Túl lassú...
Nálam az ipset vált be
https://linoxide.com/linux-how-to/block-ips-country-ipset/
https://mattwilcox.net/web-development/unexpected-ddos-blocking-china-w…
Aláírás _Franko_ miatt törölve.
RIP Jákub.
neut @
- A hozzászóláshoz be kell jelentkezni
en is ezt az ipdeny-t allitottam be nemreg a gepen, de ha nembizol benne, a geoiprol le lehet tolteni country databaset csv-bol, azt feldolgozva lehet etetnei az ipset/iptables-t
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
epp arra jartam, catoltam a scriptet, ha valakit erdekel:
function populateipset()
{
COUNTRY=$1
IPSET=$2
GEONAME_ID=$(grep $COUNTRY $TMPDIR/GeoLite2-Country-CSV_*/GeoLite2-Country-Locations-en.csv |cut -d, -f1)
(echo "create $IPSET hash:net family inet hashsize 4096 maxelem 65536"; \
grep $GEONAME_ID $TMPDIR/GeoLite2-Country-CSV_*/GeoLite2-Country-Blocks-IPv4.csv|cut -d, -f1|sed "s/^/add $IPSET /")|ipset restore -!
}
TMPDIR=$(mktemp -d -t geoip-XXXXXXXXXX);
YOUR_LICENSE_KEY=`sed -nE 's/LicenseKey (.+)/\1/p' /etc/GeoIP.conf`
wget -qO $TMPDIR/GeoLite2-Country-CSV.zip "https://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-Country-CSV&license_key=$YOUR_LICENSE_KEY&suffix=zip"
unzip -q -d $TMPDIR $TMPDIR/GeoLite2-Country-CSV.zip
#populateipset China china
populateipset Hungary hungary
rm -rf $TMPDIR
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Túl lassú...
És? Nem backbone előtti tűzfalba kell... kutyát nem érdekli, ha a lánc végén van valami ami nyolc microseccel tovább tart.
- A hozzászóláshoz be kell jelentkezni
Nekem nem volt mindig pontos, a magyar IP-re néha más EU-s országot mondott.
- A hozzászóláshoz be kell jelentkezni
Ja, előfordul.
Pl. Digi-nél is néha.
- A hozzászóláshoz be kell jelentkezni
Konkrétan Digi-m van. :-)
- A hozzászóláshoz be kell jelentkezni
00000000 ssh:notty 106.12.132.224
00000000 ssh:notty 51.161.32.211
0000 ssh:notty 185.153.196.230
0101 ssh:notty 87.251.77.206
0 ssh:notty 185.153.196.230
0 ssh:notty 45.141.84.126
10203010 ssh:notty 106.12.132.224
10203010 ssh:notty 51.161.32.211
111111 ssh:notty 185.153.196.230
111111 ssh:notty 45.141.84.126
1111 ssh:notty 185.153.196.230
1111 ssh:notty 45.141.84.126
1122334 ssh:notty 106.12.132.224
11235813 ssh:notty 111.229.35.95
11235813 ssh:notty 5.183.80.79
1212 ssh:notty 111.229.35.95
12304560 ssh:notty 111.229.35.95
12312312 ssh:notty 111.229.35.95
123321 ssh:notty 185.153.196.230
123321 ssh:notty 45.141.84.126
12345678 ssh:notty 111.229.35.95
123456mm ssh:notty 106.12.132.224
123456ya ssh:notty 106.12.132.224
123456ya ssh:notty 51.161.32.211
12345j ssh:notty 106.12.132.224
12345j ssh:notty 51.161.32.211
12345 ssh:notty 171.240.194.8
12345 ssh:notty 185.153.196.230
12345 ssh:notty 45.141.84.126
1234 ssh:notty 141.98.9.162
1234 ssh:notty 185.153.196.230
1234 ssh:notty 45.141.84.126
123abcd ssh:notty 171.239.249.229
1.2.3. ssh:notty 111.229.35.95
123 ssh:notty 185.153.196.230
123 ssh:notty 45.141.84.126
1.2.3. ssh:notty 5.183.80.79
1314521. ssh:notty 111.229.35.95
1314521. ssh:notty 5.183.80.79
14725836 ssh:notty 111.229.35.95
1541 ssh:notty 111.229.35.95
1541 ssh:notty 5.183.80.79
159357a ssh:notty 106.12.132.224
15975346 ssh:notty 5.183.80.79
198611 ssh:notty 5.183.80.79
19941994 ssh:notty 106.12.132.224
1e905c ssh:notty 116.98.160.160
22 ssh:notty 171.240.194.8
22 ssh:notty 185.153.196.230
22 ssh:notty 45.141.84.126
31415926 ssh:notty 111.229.35.95
31415926 ssh:notty 5.183.80.79
3user ssh:notty 171.239.249.229
5201314l ssh:notty 106.12.132.224
54321 ssh:notty 5.183.80.79
55667788 ssh:notty 111.229.35.95
55667788 ssh:notty 5.183.80.79
5fe5d4 ssh:notty 116.98.160.160
666666 ssh:notty 185.153.196.230
7410 ssh:notty 111.229.35.95
77585215 ssh:notty 106.12.132.224
888888a ssh:notty 106.12.132.224
888888 ssh:notty 185.153.196.230
94.152.3 ssh:notty 34.75.54.3
94.23.11 ssh:notty 54.37.91.197
94.231.1 ssh:notty 54.37.91.197
94.23.1. ssh:notty 54.37.91.197
94.250.1 ssh:notty 34.75.54.3
aaa12312 ssh:notty 106.12.132.224
aab ssh:notty 152.136.173.58
aam ssh:notty 101.36.109.214
aaron ssh:notty 185.153.196.230
aa ssh:notty 159.89.237.57
aa ssh:notty 165.227.182.136
aax ssh:notty 124.205.84.21
aay ssh:notty 101.36.109.214
abd ssh:notty 61.157.18.2
abe ssh:notty 220.85.233.146
abf ssh:notty 198.27.66.37
abm ssh:notty 118.89.138.117
abm ssh:notty 177.73.2.57
abn ssh:notty 167.71.254.137
abp ssh:notty 160.153.252.187
abt ssh:notty 159.65.137.109
aby ssh:notty 172.81.206.23
acb ssh:notty 124.207.98.213
acc ssh:notty 106.54.57.203
acc ssh:notty 129.204.33.4
acc ssh:notty 45.141.84.126
acm ssh:notty 122.35.120.59
acm ssh:notty 182.61.168.185
acq ssh:notty 122.51.77.182
acx ssh:notty 122.51.77.182
adam ssh:notty 185.153.196.230
adam ssh:notty 45.141.84.126
add ssh:notty 116.98.160.160
ade ssh:notty 121.46.26.126
adf ssh:notty 129.211.94.145
adim ssh:notty 116.98.160.160
adl ssh:notty 106.52.122.203
admian ssh:notty 116.98.160.160
admin1 ssh:notty 185.153.196.230
admin2 ssh:notty 45.141.84.126
administ ssh:notty 116.98.160.160
Administ ssh:notty 141.98.9.165
administ ssh:notty 171.239.249.229
administ ssh:notty 185.153.196.230
Administ ssh:notty 185.153.196.230
administ ssh:notty 45.141.84.126
Administ ssh:notty 45.141.84.126
admin ssh:notty 116.110.76.168
admin ssh:notty 116.98.160.160
admin ssh:notty 139.59.130.53
admin ssh:notty 141.98.81.194
admin ssh:notty 141.98.81.196
admin ssh:notty 141.98.81.202
admin ssh:notty 141.98.9.164
Admin ssh:notty 141.98.9.164
admin ssh:notty 141.98.9.166
admin ssh:notty 141.98.9.167
admin ssh:notty 171.227.208.166
admin ssh:notty 171.239.249.229
admin ssh:notty 171.240.194.8
admin ssh:notty 185.153.196.230
Admin ssh:notty 185.153.196.230
admin ssh:notty 185.156.214.22
admin ssh:notty 186.47.81.189
admin ssh:notty 222.127.151.230
admin ssh:notty 24.179.47.155
admin ssh:notty 27.69.245.10
admin ssh:notty 45.141.84.126
Admin ssh:notty 45.141.84.126
admin ssh:notty 61.149.89.249
admin ssh:notty 87.241.1.186
admin ssh:notty 87.251.77.206
admi ssh:notty 116.98.160.160
adm ssh:notty 171.240.194.8
adm ssh:notty 185.153.196.230
adm ssh:notty 45.141.84.126
adn ssh:notty 118.27.19.96
adn ssh:notty 165.22.223.121
adrienne ssh:notty 111.229.35.95
adrienne ssh:notty 5.183.80.79
adz ssh:notty 157.245.98.160
aep ssh:notty 118.89.138.117
aep ssh:notty 177.73.2.57
aeq ssh:notty 122.35.120.59
aeq ssh:notty 182.61.168.185
ae ssh:notty 109.168.109.50
aff ssh:notty 202.153.37.194
afj ssh:notty 5.3.6.82
afs ssh:notty 160.153.252.187
agent ssh:notty 185.153.196.230
agent ssh:notty 45.141.84.126
agf ssh:notty 109.168.109.50
agm ssh:notty 61.157.18.2
ags ssh:notty 160.153.252.187
ahb ssh:notty 118.89.138.117
ahb ssh:notty 177.73.2.57
ahh ssh:notty 121.46.26.126
ahj ssh:notty 165.232.105.80
aht ssh:notty 206.189.180.178
ahx ssh:notty 148.240.70.42
aidvolun ssh:notty 171.239.249.229
aini1314 ssh:notty 111.229.35.95
aini1314 ssh:notty 5.183.80.79
ainiyibe ssh:notty 51.161.32.211
aishiter ssh:notty 111.229.35.95
aja ssh:notty 124.207.98.213
ajc ssh:notty 122.53.98.243
ajd ssh:notty 111.229.194.156
ajf ssh:notty 165.232.105.80
ajj ssh:notty 159.89.237.57
ajn ssh:notty 34.95.29.237
aj ssh:notty 34.95.29.237
ajs ssh:notty 153.127.37.59
ajs ssh:notty 61.149.254.214
aka ssh:notty 124.205.84.21
akk ssh:notty 220.85.233.146
ak ssh:notty 81.70.21.113
.
.
.
5220 line-t nem akarok beilleszteni..
- A hozzászóláshoz be kell jelentkezni
Látom, téged is megkínáltak rendesen. :(
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Egyik gépemen 5600 volt a napi próbálkozás. (Van fail2ban)
- A hozzászóláshoz be kell jelentkezni
En nem hasznalom az ssh-t default porton. Persze ez nem vedelem, de atlag bot nem nagyon scannel alternativ portokra.
Ezen felul a pam_google_authenticator-t hasznalom ami tud rate limit-et is.
WireGuard mogott pedig nem ker OTP-t.
Ezen felul ezeket huzom be a routerembe:
http://feeds.dshield.org/block.txt
http://www.spamhaus.org/drop/drop.lasso
https://lists.blocklist.de/lists/all.txt
https://api.abuseipdb.com/api/v2/blacklist (ide reg kell)
- A hozzászóláshoz be kell jelentkezni
Foglalkoznom kell vele, eléggé frusztráló. Ez eddig nem így volt.
su -
Password:
Last failed login: Sat Dec 5 10:00:47 CET 2020 from 14.63.167.192 on ssh:notty
There were 3140 failed login attempts since the last successful login.
3140 sikertelen próbálkozás az utolsó sikeres óta. Az az utolsó sikeres tegnap este általam volt, azóta alig néhány órát volt bekapcsolva a gépem.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
ha keves iprol van sok probalkozas, akkor gyorsban megteszi a fail2ban. aztan amikor raersz akkor lehet egyeb tiltasokat tenni ahogy itt ajanlottak
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Elmúlt két óra. Ez alatt:
su -
Password:
Last failed login: Sat Dec 5 12:09:00 CET 2020 from 43.254.156.48 on ssh:notty
There were 3798 failed login attempts since the last successful login.
Nagyon gyorsan foglalkoznom kell ezzel érdemben.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Most még rövidebb idő alatt 5060. Iziben csinálok egy új OpenWrt/LEDE image-et, benne valamilyen megoldással. Elegem lett.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
A mandinert is le DDoS-olták, le kellett vágni a netről.
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Ja, le bizony. Az L7 támadást még csak-csak meg lehetett fogni, viszonylag egyszerűen szűrhető volt a HTTP kérések mintázata alapján (bár ezt is variálták, több ezer IP címről egyébként, amik folyamatosan bővültek), de volt ott L3-L4 is relatíve nagy sávszéllel (60 Gbps), amitől a szolgáltató megfeküdt, és jobb híján blackhole-ra tette a mandiner IP-t. Kifogyhatatlan tűzerőnek tűnt, vagy 10 órán keresztül nem szűnt meg.
- A hozzászóláshoz be kell jelentkezni
Cloudflare (es hasonlok) cdn-eknek ez piskota.
- A hozzászóláshoz be kell jelentkezni
Apropó, melyik portot támadták?
Nekem szép tiszta a logfile. (Az sshd a nem_mondom_meg_melyik porton fut.)
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Nem szívesen mondom, ha nem baj. De nem a 22-t, onnan eltettem az ssh-t.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Nem 22. A többi nem publikus, úgyhogy nem haragszom (-:.
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Konyorgom van meg egyaltalan valaki igy 2020 vegen aki olyan naiv hogy default porton futtat ssh-t?
Fel kell rakni valahova 5000 fole es a probalkozasok 99.9%-a azonnal megszunik.
Raadasul ha valaki igy is megtalalja az eros figyelmezteto jel hogy valoszinuleg celzottan szkennelik a gepet, ergo lehet ra rakni sokkal szigorubb fail2ban-t, ertsd: ha itt is raprobal valaki akkor minden porton ban legalabb 1-2 hetre.
- A hozzászóláshoz be kell jelentkezni
ezt mar parszor letargyaltuk: egy jol beallitott ssh serverhez kepest max a kisebb logfajl az elony
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
a kisebb logfajl az elony
Szerintem ez egy olyan elony, ami miatt mar megeri!
Ha a jovoben talalnak valami exploitalhato hibat az openssh-ban, akkor baj van :/ Ha default porton csung, garantaltan meg fognak probalni bejonni, hiaba van fail2ban, kulcsos login ...
Ha mar non-default porton csucsul akkor atlag bot nem fogja megtalalni. Persze ez kicsit ilyen security by obscurity-szeru, ezert ezen felul mindenkepp meg kell gatolni, hogy egyaltalan be tudjanak csatlakozni.
Mar itt is leirtak ... pl. lehet csak egy jump hostot engedelyezni, vpn, port knocking stb...
- A hozzászóláshoz be kell jelentkezni
Ha mar non-default porton csucsul akkor atlag bot nem fogja megtalalni. Persze ez kicsit ilyen security by obscurity-szeru [...]
Ha lesz olan 0day, amivel be tudnak jönni SSH-n, akkor azt valószínűleg nem a kínai botnet fogja szőnyegbombázásra használni., úgyhogy a port változtatás imho nem sok vizet zavarna már. :)
- A hozzászóláshoz be kell jelentkezni
azert ha a fel vilag ki van zarva a ssh-bol, akkor a kinai botnet nemfog jonni (max csak a magyar). de addig is _nyerhetsz_ idot, hogy kezeld a problemat. bar allitolag ez csak fals szubjektiv biztonsagerzetet ad... :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Miből gondolod, hogy a kínai botnetnek nincsenek magyarországi eszközei? Nincs eladva kismillió kínai IP kamera, router, AP, okos-ez-az, ugye? Amelyekben ha nincs is kínai állami backdoor, akkor is az eredeti több éves szoftver fut, sokszor default név és jelszó kombinációval. Na, ezekről fogod kapni a valódi támadást, szóval nyilván nyerhetsz egy szekérderéknyi időt, bármennyi legyen is az.
Tudod, az a baj ezzel a mentalitással, hogy ténylegesen befoltoztál az ezerlyukú szitádon egy-két igen apró lyukat és teljesen megnyugodtál, hogy nyerhetsz időt, ha jön a liszt. Holott a valóság az, hogy vélhetően észre se veszed, hogy megtörtek, csak ha valami nagyon elbaszott rootkit elkezd feltűnően kripto-bányászni. Hamis biztonságérzet, nem győzöm elégszer hangsúlyozni.
Van grafikonod és riasztási küszöböd például arról, hogy mennyi SSH request jön? Ha nincs, akkor honnan tudod, hogy merről fúj a szél és mekkorák a hullámok? Véletlenül épp ránézel és beszarsz, hogy több ezres számot látsz?
- A hozzászóláshoz be kell jelentkezni
ezt a hamis biztonsagerzet dolgot nem tudom honnan szivod. en tisztaban vagyok vele hogy csomo minden torheto igy-ugy. de szerintem minden dolog ami csokkenti a bejutas P valoszinuseget, azt erdemes megtenni. attol hogy megvan ez-az, meg nem dolok hatra hogy "kesz vagyok".
de ha te ugy gondolod hogy a default porton vilag szamara elerheto kulcsos ssh eleg, lelkeld rajta. mas meg ugy gondolja hogy ez nem eleg. nyilvan ez mellett meg kell alert/monitor rendszer ami a loginolasokat figyeli, stbstb.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
ezt a hamis biztonsagerzet dolgot nem tudom honnan szivod.
Én azt nem tudom, hogy mit szívsz, ha például a port áthelyezésével úgy tudod, hogy objektív szempontból nagyobb biztonságba kerülsz.
mas meg ugy gondolja hogy ez nem eleg.
Aha, más úgy érzi, hogy nem elég.
nyilvan ez mellett meg kell alert/monitor rendszer ami a loginolasokat figyeli, stbstb.
És van ilyen?
- A hozzászóláshoz be kell jelentkezni
Mint mondtam en azt gondolom, hogy nem szabad nyiva hagyni siman WAN fele SSH portot. De ha van ra lehetoseg, akkor mindent elteroen az ismert configtol kell csinalni, hisz akkor egy potencialis tamadonak extra munkat adunk.
- A hozzászóláshoz be kell jelentkezni
Nem a default porton van. A port továbbításom valami ilyesmi:
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp'
option src_dport '5432'
option dest_ip '192.168.0.99'
option dest_port '22'
option name 'ssh hostneve'
Értelemszerűen a port, a hostnév és az IP-cím más. Ha jól látom, ez lett belőle:
-A zone_wan_prerouting -p tcp -m tcp --dport 5432 -m comment --comment "!fw3: ssh hostneve" -j DNAT --to-destination 192.168.0.99:22
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Konyorgom van meg egyaltalan valaki igy 2020 vegen aki olyan naiv hogy default porton futtat ssh-t?
Nálam a default porton van. Igaz, a bejutáshoz kettő próbálkozásból ki kell találni egy 4096 bites RSA kulcsot, és egy 6 karakteres TOTP-t. Egyszer tévedni emberi dolog, a másodiknál jön a fail2ban.
Problem? :)
- A hozzászóláshoz be kell jelentkezni
Egyébként annak örülök, hogy többnyire root login-nal próbálkoznak. A PermitRootLogin no miatt. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ne gondold, hogy ott ül a gép előtt a próbálja kitalálgatni a userneveket, meg hátha van root. Például nmap sciptek automatizálva tolnak végig egy rakat gyakran használt usernevet.
- A hozzászóláshoz be kell jelentkezni
Furcsák ezek a "gyakran használt" user nevek. Végül is a logokban sokszor látom :-D
pl: hye, nmw, oyex, hfsy, hfjg, oqm, qle, fck, cmz, gge, zgqz, rjj, ke, xwe
- A hozzászóláshoz be kell jelentkezni
Ezek a random 3-4 betűsek mostanában lettek divatosak, korábban sokkal inkább tapasztaltam életszerű neveket: guest, postgres, php, admin, meg egy csomó olyan név, ami logikusnak tűnik ebben a szakmában login névnek.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Azt tudja valaki, hogy az xt_geoip_build parancsa egyes leírások szerint miért hoz létre LE és BE alkönyvtárakat? Érzésre a little endian és big endian a tippem. Azért kérdezem, mert Fedorán ez a perl script országonkénti bontásban az aktuális könyvtárba behányta az eredményt, de gyanítom, hogy itt ez little endian. Vajon a mips_24kc az mi? Aztán mi van, ha az LE és BE mégsem ezt jelenti? Már csak azért is, mert mindenféle doksiban azt látom, hogy mindkét könyvtár tartalmát felteszik a router-re.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Válasz magamnak: a mips_24kc nagy indiános, így vélhetően a Fedorára x86_64-re gyártott bináris IP-tartományok nem lesznek jók, hiszen az Intel kis indiános. :(
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Belenéztem a bináris file-ba. Érdekes, mert ránézésre big endian-osnak néz ki:
02 3A A8 00 │ 02 3A AB FF │ 02 3B C4 00 │ 02 3B C7 FF
Ez ebből lett:
2.58.168.0,2.58.171.255,HU
2.59.196.0,2.59.199.255,HU
Ennek az LE változata vajon ez?
00 a8 3a 02 | ff ab 3a 02 | 00 c4 3b 02 | ff c7 3b 02
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
A hálózati címek mindig BE. Ez a host architektúrától független.
- A hozzászóláshoz be kell jelentkezni
Köszönöm. Akkor itt a második step végét tudod nekem értelmezni?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Arra gondolsz, hogy miért van BE és LE is? Nem ismerem a geoip modult, tehát csak tipp: azért, hogy mind2 formátumot használni lehessen, de ne kelljen menet közben konvertálgatni.
- A hozzászóláshoz be kell jelentkezni
Ja, hogy így gyorsítanak a kernel modul futásán? Hol így, hol úgy kell, és egyszerűbb duplikáltan tárolni, mint pakolászni a memóriában? Nem tudom, mert szerintem a file elérés nagyságrendekkel lassabb, ha meg az elején RAM-ba húzza, akkor azzal a lendülettel előállíthatná az LE-t is, ha valamiért annyira ügyetlenül írták meg, hogy kell neki ez is, az is.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Csak az egyik kell, de azt mindkét formátumból be tudja olvasni. Nem tárolja duplán a ram-ban.
- A hozzászóláshoz be kell jelentkezni
Vagy egy etikus hacker hallgató elbaszta az ip címet valamelyik oktató hálózaton. :)
- A hozzászóláshoz be kell jelentkezni
Nem vagyok ennyire naiv. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Közben ránéztem a router logjára. Azt is próbálják felnyomni. :(
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ugy tapasztalom, hogy mennek mindenre, ami ki van engedve a netre.
- A hozzászóláshoz be kell jelentkezni
Nekem bevált, ha sokjegyű számos portra tettem az ssh-t és minden, nem magyar ip címről drop a kapcsolat.
Az eddigi tapasztalat alapján nem Mo-i ip címekről próbálkoznak.
A tűzfal szabályom:
-A INPUT -p tcp -m set ! --match-set hu.zone src -m tcp --dport xxxx -j DROP
Ahol xxxx értelemszerűen a használt ssh port.
Rebootkor egy script segítségével jön létre a lista, esetleg nem árthat mondjuk ezt az ip listát hetente lekérni.
A script semmi érdekes, ennyi csak a lényege:
# Hungary
ipset -F hu.zone
ipset -N hu.zone nethash
for IP in $(wget -O - http://www.ipdeny.com/ipblocks/data/countries/hu.zone)
do ipset -A hu.zone $IP
echo $IP
done
- A hozzászóláshoz be kell jelentkezni
Most vagyok bajban, mert hiányosak az iptables ismereteim. Lehetne a /etc/firewall.user file-ban egy szabály. Például:
iptables -I zone_wan -p tcp --dport 5432:5433 -m geoip --src-cc HU -j ACCEPT
Értelemszerűen a portok mások, de ezt egyelőre hagyjuk. Eleve -A vagy -I? Meg aztán a példában az 5432-es port forwardolódna a desktop gép felé, míg az 5433 lenne a routerre ssh-zás. Nagyobb gondom, hogy hogyan tudom mindezt tesztelni?
Vagy inverz feltétellel DROP szabály kellene? Nem világos, hogy az OpenWrt-ben megadott többi szabály ezzel logikai ÉS vagy VAGY kapcsolatban lesz, szekvenciális-e a végrehajtás, kilép-e a kernel valamelyik target-nél, vagy hogyan van ez. Mert semmire sem megyek a szabállyal, ha egy másik felülírja azt.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
-I a chain elejére, -I chain n a chain n. helyére, -A a chain végére szúrja be a rule-t.
Szekvenciális. Tesztelni online portscanner-rel.
> Meg aztán a példában az 5432-es port forwardolódna a desktop gép felé, míg az 5433 lenne a routerre ssh-zás
Én létrehoznék egy chain-t, amiben a geoip invertáltja drop, és azt -j az input-ból és a forward-ból.
Bocs, nem ellenségeskedés, de a kérdéseid alapján elég hiányosak az iptables ismereteid ahhoz, hogy egy router tűzfalát konfigold.
- A hozzászóláshoz be kell jelentkezni
Otthoni szappantartón OpenWrt/LEDE daily snapshot, nyugalom, nem céges üzemeltetés. :) A -A-ra és -I-re még emlékeztem, de nem teljesen tiszta az egész. Már nem az append és insert, hanem úgy általában az, hogyan burjánzik át egy csomag a filter szabályokon. Ha a szabály sorában teljesül a feltétel, akkor gondolom, a -j target, és ott kilép, ha nem, akkor jön a következő szabály.
Meg aztán amit forward-olni fog, arra az input szabályok alkalmazva lesznek? Ja, most látom, ezt megválaszoltad. Köszönöm.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
eloszor a port alapjan a vizsgalat menjen egy kulon chainbe. majd abban a chainben lehet a magyart acceptelni, a chain vegen meg egy feltetel nelkuli DROP. elotte akar loggolhatsz is, eseleg ebbe a chainbe felvehetsz egyedi whitellist ipket is.
ahogy fenn is irtak, szepen lepked a szabalyokon, es ahol drop/accept/reject/queue/stb -t talal, vegrehajtja, es megall. vannak specialis szabalyok ami utan tortenik valami es folytatodik a lepkedes (return, log)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Ahogy nézem a szabályokat és próbálkozom, egyre többet értek belőle. Úgyis kifaragom! :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Nézem Fedorán a man page-et, meg sem emlékezik olyanról, hogy az ipset-nek lenne -F, -N, -A kapcsolója. Gondolom, a -A az add, a -F talán a flush, a -N pedig a create akar lenni. Bár azt nem tudom, hogyan lehet valamit flush-ölni, ami még nem is létezik. Azt a nethash-t sem értem a for előtti sorban. A többi világos.
Ez a megoldás jobb, mint az iptables geoip modulja? Arra értelemszerűen tudok programot írni, hogy a cím/mask_length párosból kezdőcím,végcím kettőst csináljon, tehát ezt az adatbázist is fel tudom használni a geoip modulhoz.
Most sajnos fontos egyéb elfoglaltságom van, nem tudok vele foglalkozni, de meg fogom csinálni az adatbázis automatikus frissítését a routerben.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Az ipset-nek valoban nincsenek ilyen kapcsoloi, ne keverd, amiket irsz, az iptables kapcsoloi.
- A hozzászóláshoz be kell jelentkezni
Ezt voiper írta, nem én:
# Hungary
ipset -F hu.zone
ipset -N hu.zone nethash
for IP in $(wget -O - http://www.ipdeny.com/ipblocks/data/countries/hu.zone)
do ipset -A hu.zone $IP
echo $IP
done
Ezek szerint valami ilyesmi lenne:
# Hungary
ipset create hu.zone nethash -exist
ipset flush hu.zone
for IP in $(wget -O - http://www.ipdeny.com/ipblocks/data/countries/hu.zone); do
ipset add hu.zone $IP
echo $IP
done
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Igen, igy.
- A hozzászóláshoz be kell jelentkezni
Közben olvasom, hogy az a nethash is rossz, hash:net kell oda, vagy ki kell találni, hogyan tudja memóriában hatékonyan tárolni ezt, s aszerint lehet neki megmondani, hogy mi legyen. Egyébként ez Kadlecsik Józsi munkája? Mármint az ipset.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Bocs, jogos, ennyire nem voltam alapos, igen, az kell. Attol fuggoen, hogy a setet mivel akarod feltolteni, kell ezt a parametert meghatarozni.
Ugy tudom az ove. Nagyon hasznos joszag, szeretem.
- A hozzászóláshoz be kell jelentkezni
nekem ez volt az v1 scriptem:
(echo -n "flush china\ncreate china hash:net family inet hashsize 4096 maxelem 65536"; curl -s http://www.ipdeny.com/ipblocks/data/countries/cn.zone|sed 's/^/add china /')|ipset restore -!
igy nemkell 28ezerszer meghivni az ipset-et loopban. a v2 script mar valtott geoip-re.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Ja, hát aki elolvassa, hogy van restore. :) Mi miatt dobtad az ipset-et és váltottál geoip-re? Mert OpenWrt-ben van mindkettő, s egyelőre nem döntöttem el, melyik mellett maradjak.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
locsemege nem akartalak félrevezetni, nekem ez működött. Igaz, hogy nem openwrt alapon néztem, ez egy debian.
:~# ipset -N test.zone nethash
:~# ipset -A test.zone 15.15.15.15
:~# ipset test test.zone 15.15.15.15
15.15.15.15 is in set test.zone.
:~# ipset version
ipset v6.38, protocol version: 6
:~# cat /etc/debian_version
10.7
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy az iptables-re kompatibilitási okokból meghagyták ezeket a kapcsolókat, hogy a rendszergazdáknak ne kelljen újat tanulniuk, így aztán egy pillanatig sem kételkedem benne. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Teljesen megháborodott a világ a vélhetően fertőzött zombi csordáival. Az utóbbi órákban 8137 betörési kísérletet tapasztaltam, viszont úgy néz ki, sikerült kifaragnom a megfelelő tűzfal szabályt, így vége a játszadozásnak. 22:08-kor volt az utolsó támadási kísérlet, akkor tettem aktívvá a szabályt. Azért azt is tesztelni kell, hogy engem beenged-e.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
hmm, eljatszadoztam ezzel a ipdeny listaval, es osszehasonlitottam a geoip country (lite) db-vel.
talaltam eleg sok ipt, amit a geoip ch-nak mond, de a ipdeny-n nincs benne a cn.zone-ban
pl: 3.5.236.0/22
de talaltam olyat is amire azt mondja hogy nem cn, a cn.zone-ban meg benne van.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Mivel nekem az otthoni gép elérhetősége kell, elég volt ennyi:
-A forwarding_wan_rule -m geoip ! --source-country HU -j DROP
-A input_wan_rule -m geoip ! --source-country HU -j DROP
Elég, ha országon belülről be tudok ssh-zni a router-emre és a gépemre. Majd még az adatbázis frissítését kell megoldanom, de egyelőre jó ez. Lehet, hogy a konverzióra írok egy nyúlfaroknyi C kódot, bár ahhoz jó eséllyel fel kell tennem a gépemre az OpenWrt SDK-ját.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Többnyire root, néha root1, root2, rootftp, dmin - így, 'a' nélkül - login nevekkel próbálkoztak. Már béke van. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Azon túl, hogy idegbajt kapsz, mi bajod van a dologgal?
Ha nem tudnak bejutni, akkor teljesen felesleges ennyire izgulni és bármit tenni; ha hajózni mész a tengerre, akkor fújni fog a szél, ez ilyen.
Ha pedig be tudnak jutni, akkor meg egy jól irányzott próbálkozás is elég, kezelhetsz listákat, tűzfalszabályokat, bármit, attól még ugyanúgy veszélyben vagy, hamis a biztonságérzeted.
- A hozzászóláshoz be kell jelentkezni
Megtalálták a portot, ezért próbálkoznak. Nyilván van kulcs hozzá, hiszen én például legálisan bejutok. Tehát nem lehetetlen bejutni, csak nehéz. Ha DROP a policy, nem pedig REJECT, akkor úgy tűnik, mintha nem is létezne ott a port, mintha ki lenne kapcsolva mögötte a gép. Azon túl, hogy a router-en szűrök, a gépig el sem jut a kérés, le fognak szokni a belépési kísérletekről, hiszen látszólag nincs ott semmi. Nem hamis biztonságérzet. Tegnap néhány óra alatt volt emlékeim szerint 8137 betörési kísérlet, azóta, hogy ezeket filterezem, egy sem.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Megtalálták a portot, ezért próbálkoznak. Nyilván van kulcs hozzá, hiszen én például legálisan bejutok.
És vajon mekkora eséllyel találják el a kulcsot, ha amúgy kötött név-jelszó kombinációkkal próbálkoznak?
Nem hamis biztonságérzet.
Miért, hány százalékról hány százalékra csökkentetted így a bejutási esélyeket? Ezek a cold call próbálkozások nulla kockázattal pattannak le, egy célzott támadás meg úgy hasít át a "védelmeden", hogy észre se veszed.
Tegnap néhány óra alatt volt emlékeim szerint 8137 betörési kísérlet, azóta, hogy ezeket filterezem, egy sem.
Ezek nem betörési kísérletek voltak, mert esélyük se volt bejutni. Semmit nem akadályoztál meg.
- A hozzászóláshoz be kell jelentkezni
Túl sok időm megy a lelked ápolására. kötekszel közéleti kérdésekben, szakmai kérdésekben egyaránt, miközben az ég egy adta világon semmit nem adsz hozzá teszem azt műszaki tartalom tekintetében egy alapvetően műszaki fórumon. És bizony, ez így nem frankó. Részemről távolságtartóan viselkedem, nem látom értelmét az efféle csevegésnek. Keress mást, akibe beleköthetsz. Az ugyanis egy emberi játszma, amikor úgy vetsz fel valamit, hogy meg kellene indokolnom, mit miért teszek. Miért kellene? Különösképp neked miért? Sem a műszaki sem pedig a közéleti, politikai gondolkodásomat és döntéseimet nem fogom hozzád szabni. Ebben a topicban láthatsz példát arra, milyen az érdemi kooperáció. Tanulj belőle!
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Teljesen valid műszaki kérdéseket tettem fel a témával kapcsolatban, de tudod, felőlem küzdhetsz a szélmalmokkal...
Ha én mindössze azzal támadlak, hogy külföldi IP címekről kitartóan próbálok bejutni nálad nem létező viszonylag kevés tételből álló username:password kombinációkkal és tiltod a külföldi IP címeket, akkor ezzel egyáltalán nem növelted a rendszered biztonságát. Ha nem tiltod ezeket, hagyod megtörténni, azzal nem csökkentetted a rendszered biztonságát. Teljesen feleslegesen vagy ideges olyan dolgok miatt, amelyek kockázatmentesek.
Vedd úgy, hogy ha valaki idetéved és elolvassa a sok kooperációs "megoldást", akkor azért tudja meg azt is, hogy ezek nem fokozzák a biztonságot.
- A hozzászóláshoz be kell jelentkezni
Zöldséget beszélsz. Ha volt néhány ezer támadás alig néhány óra alatt, most pedig nulla, akkor csökken a feltörés valószínűsége. Ha teszem azt, eddig 1e-10 volt annak valószínűsége, hogy feltörik a gépet, s most 1e-14 lett ez, akkor nőtt a biztonság.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ha volt néhány ezer támadás alig néhány óra alatt, most pedig nulla, akkor csökken a feltörés valószínűsége.
Szerinted mitől változna a feltörés valószínűsége, ha egyszer vagy ha tíz milliószor próbálok bejutni az aaa:111 kombinációval? Ha van ilyen, akkor elsőre bejutok, ha nincs, akkor tízmilliószor próbálva se jutok be, te meg közben komplett idegösszeomlást kapsz, hogy fel akarnak törni.
Az a tévedésed, hogy ezek nem támadások, mert ezeknek nem növekszik a bejutási kockázata a kérésekkel arányosan, mert ugyanazt a pár száz elemű kombinációt próbálják. Ha lett volna ilyen nálad, már feltörtek volna. Ha nincs ilyen felhasználóneved és jelszód, pláne csak kulcs alapján enged be az SSH, akkor nem tudnak feltörni, bármennyszer is próbálnak bejönni ugyanazokkal a kombinációkkal. Egy közepesen erős jelszóval a brutal force évekbe kerül, észrevennéd, hogy létező felhasználónévvel próbálkoznak.
Ha teszem azt, eddig 1e-10 volt annak valószínűsége, hogy feltörik a gépet, s most 1e-14 lett ez, akkor nőtt a biztonság.
Mitől nőtt volna? Nem próbálkoznak szisztematikusan, nem is támadnak célzottan.
- A hozzászóláshoz be kell jelentkezni
Amit írsz, az is egy feltételezésen alapul, mint ahogyan az is, hogy én azt a modellt vettem alapul, hogy olykor nagy jelszó adatbázisik kerülnek forgalomba, s azzal próbálkoznak, vagy random jelszavakkal.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Amit írsz, az is egy feltételezésen alapul, mint ahogyan az is, hogy én azt a modellt vettem alapul, hogy olykor nagy jelszó adatbázisik kerülnek forgalomba, s azzal próbálkoznak, vagy random jelszavakkal.
Te egy kicsit túldimenzionálod ezt a helyzetet... egyrészt, mégis, mi a lófasznak próbálkoznának egy random otthoni IP tartomány random helyre tett SSH portján egy több milliós adatbázissal... hátha ugyanaz az SSH user:pass, mint amit egy megtört pornóoldalon használtál? Semmi haszna nincs. Itt ismert (=gyári default) vagy gyenge (például admin:admin) user:pass párokkal próbálnak "megtörni" különféle hálózati eszközöket: router-t, AP-t, nyomtatót, kamerát, egyebet.
Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy. Ha gyenge jelszavad van vagy máshol is használod, akkor meg nem vagy védve ezzel a módszerrel. Színtiszta hamis biztonságérzet.
- A hozzászóláshoz be kell jelentkezni
Semmi haszna nincs.
Ezzel vitatkoznek. Anno mikor a mikrotik exploit elszabadult, csunya dolgokat muveltek az otthoni cuccokkal. Ezen felul itt-ott penzt is tudtak lopni.
Parszor szedtem szet ilyen binarist, es az elso par ezer portot scannelik ... meg eleve a a konnyu predara utaznak.
Az "infected" eszkozok scannelnek, igy full automata, nem faj nekik ha vegigtolnak egy rockyou-t :)
Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy.
Es, atomtamadasellenisvedez? Ahogy irtam fentebb is, egy esetleges openssh hiba eseten nem ved. Ezt nem szabad elfelejteni: https://github.com/g0tmi1k/debian-ssh
En Gyuri bacsi modjara, blokkolnam :D
Jumphost, port-knocking (mondjuk http keresre), VPN stb...
- A hozzászóláshoz be kell jelentkezni
Ezzel vitatkoznek. Anno mikor a mikrotik exploit elszabadult, csunya dolgokat muveltek az otthoni cuccokkal. Ezen felul itt-ott penzt is tudtak lopni.
Oszt? Ezt nem lehet megtenni ezek szerint egy magyarországi botnetből? Vagy elkonfigurált GeoIP szűrő által mégis átengedett forgalomból?
Parszor szedtem szet ilyen binarist, es az elso par ezer portot scannelik ... meg eleve a a konnyu predara utaznak.
Oszt? Bárhova teszed, megtalálják hamar, nem erőforrásigényes egy teljes portscan és ugyanott vagy.
Ahogy irtam fentebb is, egy esetleges openssh hiba eseten nem ved.
Ahogy egy csomó egyéb szoftverhiba ellen se véd, az se, ha kreatívan próbálsz védekezni, aztán nyugodtan hátra dőlsz, hogy 0 "támadás" jön. Biztonság vagy biztonságérzet.
Azért mennek más portra is a 22/tcp porton kívül, mert kurva sok a balfasz, aki áttette máshova és hátradőlt megelégedve, hogy védve van.
Azért van distributed próbálkozás, mert kurva sok a balfasz, aki rátett valami szűrést a bejövő forgalomra és hátradőlt megelégedve, hogy védve van.
Holott annyi történt, hogy jelentősen növekedett a szubjektív biztonságérzete, de a biztonsága semmivel se lett jobb.
Jumphost, port-knocking (mondjuk http keresre), VPN stb...
Frissen tartás, értelmes konfiguráció, mint olyan? A támadással arányos védekezés, mint olyan?
- A hozzászóláshoz be kell jelentkezni
Oszt?
Oszt, nem igazan Franko ez a stilus!
Olvasd el megegyszer kerlek amit irtam! Behoztal meg 10 masik szempontot, pedig en csak ketto kijelenteseddel kapcsolatban irtam le a gondolataimat.
A security by obscurity nem tilos, csak nem elegseges -> Az, hogy az SSH service nem a default porton csucsul az egy jo dolog, de nem elegseges.
Igy erdemes meg extra lepeseket is tenni a risk csokkentese erdekeben.
Bárhova teszed, megtalálják hamar, nem erőforrásigényes egy teljes portscan és ugyanott vagy.
Csak sok hostra idoigenyes, ezert nem is maxoljak ki. Az emlitett "balfaszokra" utaznak. De ez igazabol mind1.
Ezt nem lehet megtenni ezek szerint egy magyarországi botnetből? Vagy elkonfigurált GeoIP szűrő által mégis átengedett forgalomból?
De lehet. En nem mondtam, hogy nem.
Frissen tartás, értelmes konfiguráció, mint olyan?
Szerintem ez alap. Ismeretlen hibara viszont nehez updatet talalni. Ezen felul egy 0-day eseten ido kell mig kapsz frissiteseket.
A támadással arányos védekezés, mint olyan?
Itt ismert (=gyári default) vagy gyenge (például admin:admin) user:pass párokkal próbálnak "megtörni"
Te most az eppen aktualis threat-re szukitetted le ezt az aranyt, ami szvsz. hiba.
Ha alapbol zarva van a akarmilyen service port es mondjuk valami kulso sajat/berelt VPN service cimerol engeded be kizarolag a kapcsolatot haza, az ugy jelentosen lecsokkenti a risk-et. Vagy barmi mas megoldas is jo (pl. par dollaros VPS jumphostnak), csak ne tudjanak kozvetlenul kapcsolatot nyitni a service fele.
Ugyhogy firewall ruleokban mindig Gyuri bacsinak van igaza! En blokkolnam!
- A hozzászóláshoz be kell jelentkezni
Az, hogy az SSH service nem a default porton csucsul az egy jo dolog, de nem elegseges.
Ha nem vagy vulnerable és amúgy is megtalálják, akkor minek is?
Igy erdemes meg extra lepeseket is tenni a risk csokkentese erdekeben.
Egészen pontosan milyen kockázatot csökkentesz ilyenkor? Biztonságot vagy biztonságérzetet?
Ismeretlen hibara viszont nehez updatet talalni. Ezen felul egy 0-day eseten ido kell mig kapsz frissiteseket.
Hány olyan 0day SSH sebezhetőség volt, ahol támadható voltál és az védett meg, hogy nem default porton volt az SSH?
Te most az eppen aktualis threat-re szukitetted le ezt az aranyt, ami szvsz. hiba.
Nem, én továbbra is azt mondom, hogy a GeoIP alapú tiltás és a port mozgatása nem fokozza a biztonságot. Csak a biztonságérzetet növeli, hamis képet ad a rendszer biztonságáról.
Ugyhogy firewall ruleokban mindig Gyuri bacsinak van igaza!
Plusz üzemeltetési kockázat, minden egyes felesleges rule...
- A hozzászóláshoz be kell jelentkezni
Ha nem vagy vulnerable és amúgy is megtalálják, akkor minek is?
Te miert zarod be a lakas ajtodat? egy profinak nem akadaly a zar, akkor meg minek is? :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Te miert zarod be a lakas ajtodat? egy profinak nem akadaly a zar, akkor meg minek is? :)
Pont olyan ajtóm és záram van, ami arányos védekezés. Amiről itt most szó van, az nagyjából az, hogy a lábtörlő alól valamelyik virágcserépbe teszed a kulcsot...
Úgy indulnak, hogy full port scan? Igen. Megtalálják az SSH-t, ha nem a 22-es portra teszed? Meg. Mennyi haszna van akkor, hogy nem a 22-es porton van? Semmi.
Ha ettől jobban alszol, csináld. Csak ne terjeszd, hogy biztonságosabb.
- A hozzászóláshoz be kell jelentkezni
Csendben jegyzem meg, a DROP miatt most ott sem látják, ahol amúgy van.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Maximum külhonból nem látják, hogy ott van... :)
- A hozzászóláshoz be kell jelentkezni
Ez így igaz. Különben én sem látnám. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Nem pontos az analógia. Helyesen úgy lenne, hogy átírod a házszámot a kapun, hátha amiatt nem jön be a betörő. :D
- A hozzászóláshoz be kell jelentkezni
Ha visszaolvasod, nekem ezzel a kijelenteseddel van szakmai gondom:
Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy.
Tobb multbeli esemeny is alatamasztja, hogy ez nem eleg.
Ezt a non-default port dolgot te hoztad be ... Azt irtam, hogy ez mind1, ne erre hegyezzuk ki.
Ha nem vagy vulnerable és amúgy is megtalálják, akkor minek is?
Nincs mit megtalaljanak. A service port legyen filterezve, kiveve 1-2 cimnek legyen kizarolag engedelye csatlakozni. Ezen felul mindig azt kell feltetelezni, hogy vulnerable vagy.
Azt kell feltetelezned, hogy korhazba kerulsz es fizikailag keptelen vagy updatelni es pont akkor jon ki egy 0-day. Jon valaki es letitkositja a csaladi fotoidat majd penzt ker erte. Ok? :D
Egészen pontosan milyen kockázatot csökkentesz ilyenkor? Biztonságot vagy biztonságérzetet?
Hol irtam olyat, hogy ez barmilyen kockazatot csokkentene? Tegyuk fel feltorik a VPN szervert es hozzafernek a privat halozathoz. *Lehet* nem talalja meg az ssh service-t a 65000-es porton a tamado.
Analizaltam mar par botot, en azt lattam, hogy 10-bol 1-2 csinal csak full scan-t, igy a szamossagat legalabb csokkentheted, ami jo.
Ezutan meg kellene neki egy kulcs vagy valami vulnerability is. Sok sikert.
Hány olyan 0day SSH sebezhetőség volt, ahol támadható voltál és az védett meg, hogy nem default porton volt az SSH?
Hany olyan eset volt, hogy eluthetett volna valami de te tovabb setaltal es nem is vetted eszre, hogy mi tortent?
Mar nem emlekszem pontosan, de volt talan egy Redhat? ssh update, amiben egy trojan volt, illetve a debian randomizacios fuckup. Ha default porton csung garantaltan megtalalnak, amugy meg lehet nem, fuck knows.
Hany eltitkolt exploit szaladt ki innen-onnan az utobbi 10 evben? :D Ezen felul megbizol egy distroban, aki ilyen-olyen patchet alkalmaz forditas+csomagolas elott. Nyilvan a lancban mindenki crypto-ban jartas szakember...
Nem, én továbbra is azt mondom, hogy a GeoIP alapú tiltás és a port mozgatása nem fokozza a biztonságot. Csak a biztonságérzetet növeli, hamis képet ad a rendszer biztonságáról.
Igen, ebben igazad van. De EN, hol is kerdojeleztem ezt meg? Epp azt irtam, hogy az security by obscurity-nak minosul es nem elegseges.
Plusz üzemeltetési kockázat, minden egyes felesleges rule...
Akkor te nem blokkollnad?
- A hozzászóláshoz be kell jelentkezni
Tobb multbeli esemeny is alatamasztja, hogy ez nem eleg.
Viszont a GeoIP szűrés és a port áthelyezése sem.
Ezt a non-default port dolgot te hoztad be ... Azt irtam, hogy ez mind1, ne erre hegyezzuk ki.
Nem én hoztam be, ezek a megoldási javaslatok születtek arra, hogy ne kerüljön kiírásra, hogy x failed login volt n órája. Az ellen valóban jó, hogy az x/n ne legyen egy viszonylag nagy szám, de a biztonságot nem növeli.
Analizaltam mar par botot, en azt lattam, hogy 10-bol 1-2 csinal csak full scan-t, igy a szamossagat legalabb csokkentheted, ami jo.
Mi lenne, ha támadást analizálnál és nem pár botot?
Igen, ebben igazad van. De EN, hol is kerdojeleztem ezt meg? Epp azt irtam, hogy az security by obscurity-nak minosul es nem elegseges.
Na, akkor most görgess vissza oda, ahonnan indult ez az egész szál.
Akkor te nem blokkollnad?
Nem.
- A hozzászóláshoz be kell jelentkezni
Viszont a GeoIP szűrés és a port áthelyezése sem.
Persze, ugy ahogy az amit te irsz sem es ultimately semmi sem oldja ezt meg tokeletesen.
Egy valodi szakmai erv arra, hogy ne mogasd a portot 1023 fole az lenne, hogy egy sima user is tud listen-elni rajta. Igy ha megall a process indithat a helyen barki amit akar. De most egy otthoni halozatrol van szo, ha mar van shell access akkor mar mind1.
Na, akkor most görgess vissza oda, ahonnan indult ez az egész szál.
Az a baj, hogy nehez igy. Osszemosod az eszreveteleimet mas kijelenteseivel. En nem locsemege-nek irtam, hanem neked.
Picit ugy erzem, altalaban tamadasnak veszik amit irok, de eppen a tudasomat osztom meg, ahogy te is.
Mi lenne, ha támadást analizálnál és nem pár botot?
I do this for a living ... :P
Maradjunk annyiban, hogy en blokkolnam! :D
- A hozzászóláshoz be kell jelentkezni
Persze, ugy ahogy az amit te irsz sem es ultimately semmi sem oldja ezt meg tokeletesen.
Minden biztonság arányosságra törekszik. Aránytalan biztonságnak nincs sok értelme.
Én mindössze annyit írtam, hogy a szálban felhozott megoldási javaslatok nem fokozzák a biztonságot, csak a biztonságérzetet. És úgy látom, hogy ennek a biztonságérzetnek célszáma a "There were X failed login attempts since last N hours." üzenetben az X/N minimalizálása. Semmi több.
Osszemosod az eszreveteleimet mas kijelenteseivel. En nem locsemege-nek irtam, hanem neked.
Akkor nyiss egy új szálat a témában.
Picit ugy erzem, altalaban tamadasnak veszik amit irok, de eppen a tudasomat osztom meg, ahogy te is.
Ha hajózni mész a tengerre, akkor fújni fog a szél és hullámok lesznek. Ha kinyitsz egy portot a nagyvilág felé, akkor próbálgatni fogják. Ez a természete ezeknek a világoknak. Ha kinyitsz egy VPN portot, akkor azt fogják próbálgatni, mindegy, milyen portot nyitsz ki, próbálgatni fogják. Ha ettől ideges leszel ("eléggé frusztráló", "nagyon gyorsan foglalkoznom kell ezzel érdemben", satöbbi), akkor nem való neked a portnyitás, maradj a szárazföldön.
És tudod: fogadni merek egy láda sörbe amúgy, hogy a kérdező nem szokta és nem is tudja detektálni azt, hogy bejutottak-e, vagy már fut-e kártevő a gépén. De ma már nyugodtan aludt, mert az X/N kellően alacsony volt.
- A hozzászóláshoz be kell jelentkezni
Minden biztonság arányosságra törekszik. Aránytalan biztonságnak nincs sok értelme.
A zero-trust model alkotoinak is ird ezt le pls. Valami papirt is publikalj a temaban, hogy hogyan lehet ezt az aranyt pontosan megallapitani!
Akkor nyiss egy új szálat a témában.
Ja, hogy akkor arra amit szakmailag kifogasolok a TE irasodban, nyissak egy teljesen fuggetlen uj szalat? Micsodaaaa?
Ha hajózni mész a tengerre, akkor fújni fog a szél és hullámok lesznek. Ha kinyitsz egy portot a nagyvilág felé, akkor próbálgatni fogják. Ez a természete ezeknek a világoknak. Ha kinyitsz egy VPN portot, akkor azt fogják próbálgatni, mindegy, milyen portot nyitsz ki, próbálgatni fogják. Ha ettől ideges leszel ("eléggé frusztráló", "nagyon gyorsan foglalkoznom kell ezzel érdemben", satöbbi), akkor nem való neked a portnyitás, maradj a szárazföldön.
Meg ezzel is egyet tudnek erteni, csak ha tobb reteged van, akkor egynel tobb dolgot kell baszogatnia, ami tobb ido, nagyobb nehezseg. Ez nem csak a biztonsag erzetet noveli.
És tudod: fogadni merek egy láda sörbe amúgy, hogy a kérdező nem szokta és nem is tudja detektálni azt, hogy bejutottak-e, vagy már fut-e kártevő a gépén
Ha ugy indulsz neki egy vitanak, hogy azt feltetelezed, hogy a masik fel tuti ostoba, akkor konnyen megutheted a bokad.
- A hozzászóláshoz be kell jelentkezni
A zero-trust model alkotoinak is ird ezt le pls.
Á, szóval te a világ összes katonaságánál is erősebb és megbízhatóbb magánhadsereggel véded a cuccaidat? Ha nem, akkor most köpj fel és állj alá.
Valami papirt is publikalj a temaban, hogy hogyan lehet ezt az aranyt pontosan megallapitani!
Pontosan sehogy, de a hasztalan, ám látványos, sőt, látványosan statisztikázható dolgok ezen nem igazán segítenek.
Ja, hogy akkor arra amit szakmailag kifogasolok a TE irasodban, nyissak egy teljesen fuggetlen uj szalat? Micsodaaaa?
Az én írásomban mit is kifogásoltál? Továbbra is annyit állítok, hogy a GeoIP szűrés és a port áthelyezése hamis biztonságérzetet ad, a biztonságot nem befolyásolja.
Meg ezzel is egyet tudnek erteni, csak ha tobb reteged van, akkor egynel tobb dolgot kell baszogatnia, ami tobb ido, nagyobb nehezseg. Ez nem csak a biztonsag erzetet noveli.
Növeli a biztonságot? Kitiltod az IP-k felét és már dupláztad a biztonságot?
1, Ha a szokásos "tamádások" jönnek, mint ebben a témában is látható, azok ártalmatlanok, engedheted mind, nem fognak bejutni, nem növeltél biztonságot.
2, Ha véletlenül elosztott brutal force vagy DDoS támadás jön, azt amúgy is észreveszed, mert kiemelkedő forgalom lesz és nem befolyásolja az, hogy mennyi IP-t tiltasz, nem növeltél biztonságot.
3, Ha elosztott 0day exploit támadás jön, akkor elég egy, ami betalál, nem növeltél biztonságot.
-
Olyan ez, mint SMTP-n anno a greylisting, egy darabig fasza volt, mert lehetett szopatni a spammert, aztán megtanulták és azóta semmi haszna, szinte mindenki ki is kapcsolta. Pont ilyen az SSH port máshova mozgatása és a különféle IP listák alapján való tűzfalazás és a fail2ban, egy darabig fasza volt, mert lehetett szopatni a botokat, aztán megtanulták és azóta semmi haszna, átmennek rajta, mint meleg kés a vajon.
Ha valami hasznos védelmet akarsz, akkor ne ezek legyenek, mert ezek nem védenek és ne vetődj árnyékokra, mert hamis biztonságérzetet ad mindössze.
Ha ugy indulsz neki egy vitanak, hogy azt feltetelezed, hogy a masik fel tuti ostoba, akkor konnyen megutheted a bokad.
Ja, hogyne. De azért érdekelne, hogy futtat-e valamilyen rendszerességgel offline checksum ellenőrzéseket és keres-e gyakori kártevőket. Vagy ott tart még, hogy ez Linux, erre nem kell víruskereső.
- A hozzászóláshoz be kell jelentkezni
Felkelteted az érdeklődésemet. Te hogyan csinálod?
- A hozzászóláshoz be kell jelentkezni
Arányos védelemmel: automatikusan települő security update; riasztásokkal egybekötött monitoring; arányos tűzfalazás, rendszeres időnként offline checksum és ilyesmi. Léggömbhámozással, security by obscurity és egyéb látszattevékenységekkel nem foglalkozok, nem fogok attól jobban aludni, hogy óránként csak 50 és nem 5000 request jön az SSH-ra, mert nem kockázat, ha papírgalacsinnal dobálják a várfalat.
- A hozzászóláshoz be kell jelentkezni
az csak egy szubjektiv biztonsag erzet, hogy majd a monitoring rendszer szolni fog ha bejutottak :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Sehol nem írtam, hogy a monitoring rendszer csak akkor szól, ha bejutottak. Azt írtam, hogy szól, ha valóban támadnak olyan módon, aminek a legvégén valódi esély van a bejutásra. Amíg egyszer nem próbálják meg azt a felhasználónevet, ami létezik, addig minek forgolódjak álmatlanul attól, hogy ebből óránként mennyi volt? Akkor vagyok igen-igen kicsi veszélyben, ha azzal a felhasználónévvel akarnak belépni jelszavakat próbálva, ami létezik, de csak kulccsal lehet bejönni, mert valahonnan kiszivárgott és ki kell nyomozni, hogy hol volt szivárgás. A valódi veszély az lenne, ha lenne kulcsuk is...
Ezt amúgy te észreveszed, hogy van kulcsuk és elsőre bejönnek? Mert a többi, amit művelsz, az közönséges survivorship bias, ott pakolod a páncélt a repülőre, ahol amúgy védett a találatok ellen és nem azt nézed, hogy hol védtelen.
- A hozzászóláshoz be kell jelentkezni
aha, es azzal az ssh 0dayel mi lesz ahol egybol bash-t kap a tamado? nincs usernev, nincs kulcs, nincs logbejegyzes sem... jo hat ilyen a Franko vilagban nem letezik, nem is kell ellene vedekezni :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
aha, es azzal az ssh 0dayel mi lesz ahol egybol bash-t kap a tamado? nincs usernev, nincs kulcs, nincs logbejegyzes sem... jo hat ilyen a Franko vilagban nem letezik, nem is kell ellene vedekezni :)
Megtalálja máshol az SSH-t? Meg. Lesz magyarországi botnet, ahonnan elosztva próbálkozik? Lesz. Bejut a kurvára védettnek gondolt gépedre? Be.
Válaszolj kérlek őszintén: nálad automatikusan települnek a security frissítések? Mert nálam jelenleg maximum 5 percig lesz védtelen rendszer, nálad ez maximum mennyi idő?
- A hozzászóláshoz be kell jelentkezni
unattended-upgrades
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Igen, tudom, hogy van ilyen, a feltett kérdésre válaszolj, őszintén.
- A hozzászóláshoz be kell jelentkezni
valaszoltam, a fenti csomag vegzi, bar nem tudom mi koze van ehhez egy 0day-hez :/
de mind1 hagyjuk. istenhivokkel nincs mar kedvem vitatkozni :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
valaszoltam, a fenti csomag vegzi, bar nem tudom mi koze van ehhez egy 0day-hez :/
Akkor újra: a kérdés az volt, hogy nálad ez mindenhol fut-e. Mivel kerülöd az egyenes választ, gondolom nem fut, az van, mint Ar0n esetén, hogy "korhazba kerulsz es fizikailag keptelen vagy updatelni", de persze két tűzfal közé tenni kell egy harmadikat és az SSH-t szarrá kell tűzfalani, mert attól aztán kurva nagy biztonság lesz.
A 0day-hez annyi köze van, hogy szinte azonnal felkerül a javítás a rendszeredre, akkor is, ha nem tudsz róla, hogy kiderült és jött rá patch... vagy pedig alszol nyugodtan, a rendszereid meg lyukasak, mert a "változás rossz", főleg, ha automatikus.
A nem közismert, javítás nélküli 0day-hez meg annyi köze van, hogy azt nem a te gépeden fogják demonstrálni és ha igen, akkor bizony lófaszt nem véd az, amiről úgy gondolod, hogy csökkenti a feltörés esélyeit...
de mind1 hagyjuk. istenhivokkel nincs mar kedvem vitatkozni :)
Ezt magaddal beszéld meg, mert kettőnk közül te hiszel abban, hogy nagyobb biztonságban attól, hogy nem a default porton van az SSH és egy országra szűkíted bejövő kéréseket. Én meg tudom, hogy ezekkel nem leszek nagyobb biztonságban, felesleges pótcselekedet, színtiszta survivorship bias. Ha már csinálsz valamit, akkor olyat tegyél, amitől növekszik a biztonságod, a biztonságérzetedet hiába növeled, attól még simán feltörnek egy 0day sebezhetőséggel mondjuk egy magyarországi IP kameráról indítva a támadást, mert az ellen nem véd.
- A hozzászóláshoz be kell jelentkezni
Az én írásomban mit is kifogásoltál? Továbbra is annyit állítok, hogy a GeoIP szűrés és a port áthelyezése hamis biztonságérzetet ad, a biztonságot nem befolyásolja.
"Semmi haszna nincs."
"Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy."
"Plusz üzemeltetési kockázat, minden egyes felesleges rule..."
"A támadással arányos védekezés"
Ezt mindet.
Növeli a biztonságot? Kitiltod az IP-k felét és már dupláztad a biztonságot?
Te amugy igy latod amiket irok? "Nincs mit megtalaljanak. A service port legyen filterezve, kiveve 1-2 cimnek legyen kizarolag engedelye csatlakozni."
Ha nem, akkor most köpj fel és állj alá.
Ki az aki bant teged, hogy itt vezeted le a feszultseget? :)
- A hozzászóláshoz be kell jelentkezni
"Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy."
Ha erős jelszavad van, akkor üzemszerű körülmények között (nem üzemszerűt lásd lejjebb) még közepesen gyenge jelszó esetén is minimum évekig tartó brutal force alatt vagy törhető, ha nincs jelszavad, hanem csak kulcsod van, akkor pláne. És persze ehhez ki kell találni a felhasználónevet is, ami létezik az adott rendszeren és ez azért nem triviális, ha nem "admin" vagy "user" az a felhasználónév. Ezekre tudsz tenni metrikát, igen alacsony riasztási küszöbbel, hogy elkezdték próbálgatni valamelyik felhasználót, tehát információ szivárgás van vagy volt, aminek ki kell deríteni a forrását.
Kurvára értelmetlen azon pörögni, hogy olyan felhasználókkal próbálnak belépni, amelyek nálad nem léteznek és olyan metódussal próbálnak, amivel amúgy sem engeded be.
"Plusz üzemeltetési kockázat, minden egyes felesleges rule..."
Egyszer zárod ki magad tűzfalszabállyal, amikor fontos lenne belépned, akkor rájössz, hogy miért üzemeltetési kockázat. Beállítod, hogy csak magyarországi IP engedjen be, aztán kapsz egy olyan IP-t a UPC hálózaton, ami osztrák (megtörtént eset), aztán próbálsz onnan olyan helyre tovább menni, ahonnan be tudsz lépni. Másrészt, ha statikus az IP adatbázisod van, akkor elmászik alatta a világ, egyre többször szaladhatsz bele problémákba; ha dinamikus, akkor vagy kézimunka, ami üzemeltetési kockázat vagy automatizálod, akkor meg máshonnan húzol be üzemeltetési kockázatot. Ha meg elbaszod az automatikát, mert nincs rá out-of-the-box megoldás (nem véletlenül), akkor bizony könnyedén kicsukod magad.
"A támadással arányos védekezés"
Az ellen védekezz, ami veszélyes, annyira, amennyire veszélyes és kockázatos.
A témaindító "támadás" annyi, mintha papírgalacsinnal dobálnák a várfaladat, azt röhögjed ki, ne számolgasd nyüszítve, hogy mennyi papírgalacsin per óra épp a "támadás" mennyisége, teljesen ártalmatlan az egész.
Ha feszegetik valamelyik kaput vagy próbálgatnak jelszavakat, mert tudják a felhasználónevet, akkor erre legyen alacsony küszöbű riasztás és nézd meg, hogy vajon honnan szivároghatott ki egy felhasználónév. Nekem eddig még nem tudták kitalálni, hogy mi a felhasználónév, nemhogy jelszóval próbálkoztak volna, amivel amúgy nem jutnak be...
Ha jön biztonsági javítás, mert kiderül, hogy a szennyvízcsatornán keresztül fel lehet mászni a várba és belülről kinyitni a kaput, akkor legyen automatikus eljárásrended arra, hogy a lehető legkevesebb időn belül felmenjen a security fix, humán interakció nélkül.
Ha kiderül egy 0day sebezhetőség és nincs rá azonnal security fix (ez ritka), akkor is minimum tudjál róla, hogy van 0day sebezhetőség és legyen rá workaround terved, amivel védeni tudod magad. Nem általánosságban, hogy hátha nem jönnek be, ha felezem az IP címeket, hanem tényleges és működő workaround, amivel ténylegesen megvéded magad.
Ha van 0day sebezhetőség és nem derült még ki, akkor van esélye, de igen-igen kicsi, hogy rajtad kezdik kihasználni, mert egy nem javított és ismeretlen 0day sebezhetőségnek komoly ára van a feketepiacon, nem fogják jelentéktelen gépeken ellőni, ahol felmerül, hogy mi van, ha "korhazba kerulsz es fizikailag keptelen vagy updatelni", hanem olyan célpontokon fogják használni, ahol van bőven anyagi haszna is. Ez ellen nem véd az, ami megoldásokat itt látunk, mert humán intelligencia fog támadni, kombinált sebezhetőségekkel, social engineering és egyéb dolgokkal; amikor már botokkal nyomják tömegesen, akkor már napokkal, hetekkel, hónapokkal a security fix után vagyunk.
És persze nézni kell azt, hogy bejutottak-e, mert a sikeres támadást pont nem fogod észrevenni se a tűzfal, se a monitoring, se a többi dolog nem jelzi, főleg, ha ügyesen csinálják. Linkeltem az előbb, ez az SSH hekkelés tipikus survivorship bias, szanaszét lőhetik az SSH logot, nem lesz belőle egyáltalán bajod, viszont mivel sok találat van, egyszerűen pszichológiai okokból akarsz ezzel foglalkozni.
Ki az aki bant teged, hogy itt vezeted le a feszultseget? :)
Az itt olvasott hülyeségek bántanak, amelyek megoldásként születtek a feldobott problémára.
- A hozzászóláshoz be kell jelentkezni
"Az ellen védekezz, ami veszélyes, annyira, amennyire veszélyes és kockázatos."
Koszonom, mostmar akkor ertem! A "brutal force" az!
szanaszét lőhetik az SSH logot, nem lesz belőle egyáltalán bajod
Szeritnem az is baj, ha tarolnom kell vagy ha felporgetik a lemezeimet feleslegesen.
Te csinald igy! En meg majd szomoruan hasznalom a kis kulso par dollaros jumphostomat meg a kulso VPN-emet, hogy elerjem az otthoni SSH-t. Rettegek majd, mert az otthoni halozatom uzemeltetesi kockazatai magasak a 2 darab allow rule miatt. Szomoru leszek mert szerinted hulyeseg.
- A hozzászóláshoz be kell jelentkezni
Koszonom, mostmar akkor ertem! A "brutal force" az!
Nem, a brutal force nem veszélyes. Az a veszélyes, hogy kiszivárgott egy használt felhasználónév, ez egy indikátor, hogy valahol adatszivárgás van a rendszerben, valaki valahol bejutott vagy valaki valahova olyan dolgot publikált, amiben benne van.
Szeritnem az is baj, ha tarolnom kell vagy ha felporgetik a lemezeimet feleslegesen.
Logrotate, mint olyan? A monitoring real-time feldolgozza, utána eldobható a konkrét log, nincs benne hasznos dolog.
En meg majd szomoruan hasznalom a kis kulso par dollaros jumphostomat meg a kulso VPN-emet, hogy elerjem az otthoni SSH-t. Rettegek majd, mert az otthoni halozatom uzemeltetesi kockazatai magasak a 2 darab allow rule miatt. Szomoru leszek mert szerinted hulyeseg.
Hajrá. De azért ez kissé messzebb van attól, hogy zárjuk ki a fél világot és tegyük máshova az SSH portot, mert az majd megvéd.
- A hozzászóláshoz be kell jelentkezni
De azért ez kissé messzebb van attól, hogy zárjuk ki a fél világot és tegyük máshova az SSH portot, mert az majd megvéd.
Jaj, csak errol irtam neked mar egy fel regenyt :)
Hajra "brutal force"!
- A hozzászóláshoz be kell jelentkezni
ez olyan mint a lotto nyeres: aki nem vesz (=probalkozik sshn) szelvenyt, nem nyerhet (=sikeres belepes). nyilvan meg egy csomo mindennek kell egyeznie, pl eltalalni a megfelelo szamokat (=eltalalni a megfelelo u/p). amugy nem feltetlenul rossz az ha a felesleges problakozokat (=zajt) kiszurjuk, lehet koncentaralni a maradek probalkozora.
de amugy igaza van locsemegenek, minden valaszod olyan mintha az lenne az egyeduli es megdonthetetlen igazsag a vilagon, mindenki mas meg egyszeruen hulye. :/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
ez olyan mint a lotto nyeres: aki nem vesz (=probalkozik sshn) szelvenyt, nem nyerhet (=sikeres belepes). nyilvan meg egy csomo mindennek kell egyeznie, pl eltalalni a megfelelo szamokat (=eltalalni a megfelelo u/p).
Bocsánat, de nem, ez olyan, mintha csak öt számot játszanál meg a hatoslottón és várnád, hogy mikor nyersz.
amugy nem feltetlenul rossz az ha a felesleges problakozokat (=zajt) kiszurjuk, lehet koncentaralni a maradek probalkozora.
Ha továbbra is naplózod, csak máshol is, akkor kettő helyen kell nézned, hogy mi a helyzet. Ha meg nem naplózod, akkor nem tudod, hogy mi történik, azt hiszed, hogy biztonságban vagy.
És akkor jönnek az olyan önszopatások, mint amikor kapsz véletlenül egy külföldi GeoIP címet és faszán ki is csuktad magad.
de amugy igaza van locsemegenek, minden valaszod olyan mintha az lenne az egyeduli es megdonthetetlen igazsag a vilagon, mindenki mas meg egyszeruen hulye. :/
Alapvetően az a baj, hogy a biztonság az objektív dolog, a biztonságérzet meg szubjektív dolog. Nincsen semmi baj azzal, hogy ha valaki túlaggódja a dolgokat, akár azzal se, ha paranoiás és ide hallom hogy szinte nyüszít, mert támadják, aztán csinál egy értelemetlen dolgot és megnyugszik, csak tegyük oda, hogy nem az objektív biztonságot fokozta ezzel, hanem a szubjektív biztonságérzetét.
Értem, hogy most már nyugodtan alszik, tök jó dolog, de ne írjuk le, hogy biztonságosabb lett ezzel a rendszere, mert az egyszerűen nem igaz.
- A hozzászóláshoz be kell jelentkezni
a biztonsagot en nem egy bites szamkent kezelem hanem egy allapotot a 0 es a vegtelen kozott valahol. minden olyan dolog ami megtilt/bezar/stb valamit, az odebb loki az allapotot a vegtelen fele, van ami nagyot valtoztat, van ami kisebbet. minel tobb minden van, annal tavolabb van az inserucre 0-tol.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Oké, én megpróbálok hozzád bejutni kizárólag `T29ZbvvG` felhasználónévvel és `AZx5APnT` jelszóval. Mennyit mozdul el a biztonságod a skálán, ha ezt tiltod egy rajtad kívülálló IP lista alapján?
- A hozzászóláshoz be kell jelentkezni
most valtoztathatok jelszot, mert kitalaltad! :D
de latod a mozgas szubjektiv ertek: szerinted 0, szerintem meg picit. hogy pontosan mennyit, nemtudom. de az biztos hogy tavolabb kerultunk a 0-tol mint ahol voltunk.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
most valtoztathatok jelszot, mert kitalaltad! :D
De akkor egyből bejutottam volna, se fail2ban, se GeoIP, se portáthelyezés nem védett volna meg, nemde?
de latod a mozgas szubjektiv ertek
Neked a biztonságérzés van a skáládon, az a szubjektív.
- A hozzászóláshoz be kell jelentkezni
jo hat a megdonthetetlen igazsagokon nem tudok valtoztatni. de nincs baj. ha te ugy gondolod hogy eleg az sshkulcs, akkor ne is csinalj tobbet. en meg csinalok ezt-azt. akik meg olvassak a szalat, eldontik hogy eleg-e a Frako's security, vagy ok is csinalnak-e meg tovabbi "fals" biztonsagi dolgokat :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Attól tartok, a probléma az, hogy kedves @locsemege kolega fél a lebukástól, hogy még ennyi év informatikai és/vagy Linux hókuszpókusz után sem volt szándékában kikommentezni a "PasswordAuthentication" sort az sshd_configjában...
Vagy, ami még nagyobb gáz lenne, ha kiderülne, hogy a "prohibit-password"-ot viszont sikerült eltüntetnie a "PermitRootLogin" mellől.
De, hogy ennél is (technikailag) relevánsabb legyen eme hozzászólásom, kérdezem:
Mit fog csinálni a kedves kolega akkor, amikor egy hazai botnet cuppan rá a portjára kopogtatni??
(Mert feltörhető/lejárt támogatású/távolkeleti IP-kamerák penetrációjának tekintetében igencsak rosszul állunk e téren.) vagy
Mit fog csinálni, ha egyszer külföldre viszi útja, és rájön, hogy szar dolog az embernek maga alatt vágni a fát??
Mert, ha mondjuk egy TV szolgáltató vagy, és valamelyest korlátozni szeretnéd, az adás nézhetőségét a világ egyes tájairól, akkor megértem, hogy van értelme a GEOIP-féle bohóckodásnak, vagy ha egy nagyobb szolgáltató vagy, és mindenképpen szükség van a passwordauth-os ügyfelek kiszolgálására, akkor a fail2ban ssh-ra reszelésének, de azt, hogy a 4-5 biten kifejezhető darabszámú (ráadásul otthoni) felhasználók szintjén miért nem lehet áttérni az ssh, kulcsos használatára, azt nem tudom megérteni!...
Abban, viszont maximálisan igazat adok @_Franko_ kolegának, hogy, ha évek múltán, tfh. egy leendő rendszergazda tanonc ránéz erre a topikra, akkor értelmes, és valódi megoldást is lásson, ne csak hamis biztonságérzetet adó félmegoldást.
Éppen ezért a pikánsabb megjegyzéseimet is idebiggyesztem:
Vajon megéri-e a perfomancia-veszteség a SOHO routeren, (fogadjunk, hogy TP-Link), amit az iptables GEOIP modulja okoz számára?
(Mert itt sincsen ingyen a húsleves)
De mondok jobbat is:
Tedd odébb legalább 10 bitnyivel azt a fránya ssh-portot, és meglátod, hogy újabb hónapokra békén hagynak.
(saját tapasztalat)
- A hozzászóláshoz be kell jelentkezni
Tedd odébb legalább 10 bitnyivel azt a fránya ssh-portot, és meglátod, hogy újabb hónapokra békén hagynak. (saját tapasztalat)
Nem hagynak békén, ugyanúgy megtalálják, mintha a default helyen lenne. Ráadásul a kérdező már áthelyezte és úgy "támadják".
- A hozzászóláshoz be kell jelentkezni
Mostmar csak leirom, hatha idegesit! Poenbol tegnap inditottam egy-egy ssh-t 2 public IP-n 22/65000 porton.
Itt a stat:
22: 12236 db failed attempts
65000: 0 db
Vedelem? Nem. Hasznos, jobb igy? Igen.
- A hozzászóláshoz be kell jelentkezni
de azert majd majd vigyazz az alvassal, mert ez igy nemjo!!!44 :D
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Hatradolni nem fogok ... meg alvas kozben sem! Igerem!
- A hozzászóláshoz be kell jelentkezni
22-re kiajanlottam egy endlessh-t, nezegessek csak. :)
- A hozzászóláshoz be kell jelentkezni
Hát akkor itt az ultimate silver bullet, csak át kell tenni a 65000 portra mindenkinek és problem solved örökre. Halleluja.
- A hozzászóláshoz be kell jelentkezni
Nem! 65535 fölé, és azt soha nem fogják támadni. ;)
- A hozzászóláshoz be kell jelentkezni
Vegre! Erted mar.
- A hozzászóláshoz be kell jelentkezni
vagy 0 alá, a -22-re :D
- A hozzászóláshoz be kell jelentkezni
Nem állítottam, hogy örökre békén hagynak, csak azt, hogy egy ideig.
(Ha az az idő, tfh. másra nem, de legalább arra jó, hogy higgadtan átgondolja az ember a dolgokat.)
Az nekem is feltűnt, hogy az utóbbi hónapokban nagyságrendekkel jobban felszaporodtak az ilyen jellegű próbálkozások.
Ugyanakkor az, azért még mindig igaz, hogy egy DROP policy-s tűzfalon, a teljes tartomány végigszkennelése relatíve hosszú idő, ezért még most is él az a hagyomány, hogy a 10K alattiakat szeretik tesztelni.
És ezt az én statisztikám is alátámasztja:
(elmúlt 2 hónap, nyilvános ip)
3-4K közötti ssh port: 40.384 sikertelen
30-40K közötti ssh port: 94 sikertelen
A fenti GEOIP-re egy (nem állítom, hogy sokkal jobb) alternatíva:
A fail2ban-nal átmenetileg letiltod magát a megcélzott usert, és nem csak a támadó 1db címét.
Ez a nagyon sok forrású botnet ellen egy relatíve "olcsó" védelem, de kétségtelen, a támadás alatt, a valódi user is kiesést fog tapasztalni.
Ami viszont mostanában engem idegesít, azok a célzott adathalász támadások.
Amikor az egész webmail,honlap,stb felületét lemásolják, majd elküldenek az ismert (mondjuk honlapon kintlévő) címekre egy helpdesk levelet, a hamis linkkel, az egyszeri kolega meg, (nem ellenőrizvén a böngésző címsorát) azt hiszi, hogy jó helyen jár, és belép.
(És sajnos egyre javul a magyarságuk is, talán a google translate fejlődésének köszönhetően?)
Korábban ilyenek mifelénk, (talán érdektelenség végett) nem voltak, és ez ellen a GEOIP, meg a fail2ban sem véd...
- A hozzászóláshoz be kell jelentkezni
vpn
- A hozzászóláshoz be kell jelentkezni
+1 a vpn használatra.
Z
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.
- A hozzászóláshoz be kell jelentkezni
A VPN-t nem fogják "támadni"? Vagy annak nincs minden loginnál egy üzenete, hogy a "There were X failed login attempts since last N hours.", ezért nyugodtan hátra lehet dőlni?
- A hozzászóláshoz be kell jelentkezni
Tűzfal => VPN + token => Tűzfal => Port Knocking
- port scanner ip-k: 30 napra tilt
- aki ssh-zni / ftp-zni / winbox / stb. akar: 30 napra tilt
- ami nem adott 8 országból jön eldob
- ping eldob
- kintről minden zárt
- partnerek is csak VPN-en jöhetnek
Kkv szinten béke van, vagy csak azt hisszük! ;-]
Kinél még milyen tipp van ami bevált?
Köszi!
- A hozzászóláshoz be kell jelentkezni
Ahol lehet VPN, de kevés helyen építem ki csak ezért.
Inkább 1-2 VPN kapcsolat, aminek kijárata fix IP-s és ezen IP-ről engedélyezem az SSH-t a többi szervereken.
- A hozzászóláshoz be kell jelentkezni
ICMP-t nem tiltjuk, max korlátozzuk, pl 5 ICMP csomag/sec
- A hozzászóláshoz be kell jelentkezni
Nálunk kintről tiltott, bentről pedig korlátozott.
- A hozzászóláshoz be kell jelentkezni
A VPN-nel az a bajom, hogy léteznek vírusok, malware-k, nem kis számban, amik csak a VPN config fájlt keresgélik, a mit-sem-sejtő user kliens gépén.
- A hozzászóláshoz be kell jelentkezni
2 faktoros auth.
Kulcs, amit épp kiolvashat az általad említett malware + jelszó, amit menet közben gépel be a user ÉS memóriában nem tárol le. Ilyet beállítás van openvpn-re.
Persze, ha keylogger fut a gépen, fertőzött a gép, rég megette a fene. Hálózatra tiszta gépet illik kapcsolni.
Tompítani vpn auth-tal összekötött ip szűréssel tudsz. Vagy tokennel emelni a biztonságon.
- A hozzászóláshoz be kell jelentkezni
En most egy Yubikey-t hasznalok erre. Korabban sima smartcardot hasznaltam.
Ha olyan cimrol kapcsolodok amirol meg soha meg van egy 2 faktoros auth is.
- A hozzászóláshoz be kell jelentkezni
Mi a tapasztalatod vele? Köszi!
- A hozzászóláshoz be kell jelentkezni
Egy yubikey nano-m van. Tulajdonkeppen ugyanolyan mint egy smartcard, a kulcsot az eszkoz generalja es tarolja a HSM moduljaban es azt remelhetoleg soha nem hagyja el.
Mar ~3 eve van meg, nem volt vele gond.
Volt valami minor security problema es kuldtek uj kulcsokat. Szvsz jo ceg.
Ezen felul van benne FIDO, ugyhogy webes cuccokhoz is hasznalom.
- A hozzászóláshoz be kell jelentkezni
Mennyivel tartod biztonságosabbnak, jobbnak a Yubikey-t, mint pl a Google Authenticator appot?
Kb egy éve beszéltem egy ismerőssel, aki azt mondta, hogy teljesen áttértek a cégnél a szoftveres megoldásra. Meglepődtem, mert nagy cégről van szó, akiknél az egyik fő üzletág a biztonsági rendszerek.
- A hozzászóláshoz be kell jelentkezni
Nehez megmondani, jo beallitassal es megfelelo oktatassal szerintem megkozelitheto. Sok emberre azert jo draga egy ilyen hardveres megoldas, valoszinuleg nem eri meg. Ki merem jelenteni, hogy tulzas is egy picit.
De egy harveres megoldas mondjuk tenyleg nehezen duplikalhato.
Btw, nekem amugy sokkal kenyelmesebb egy ilyet hasznalni mint minden ssh loginnal vacakolni valami app-al.
- A hozzászóláshoz be kell jelentkezni
Nem egy kategória a kettő.
A google authenticator tudomásom szerint egy TOTP generátor.
Ehhez képest a Yubikey ezer másik dolgot is tud, pl. privát-publikus kulcspárt generálni, és azzal authetikálni.
- A hozzászóláshoz be kell jelentkezni
Ez egyértelmű, de ha meg akarom védeni a postafiókomat, github fiókomat,... jelent-e plusz biztonságot?
Párszor nekifutottam, hogy veszek, de mindig elakadtam ott, hogy ha a kulcscsomómra teszem, akkor az egész kulcscsomót viszem a géphez, két gépet használok,... Ha nem teszem a kulcscsomómra, kb soha nem lesz nálam. A telefon mindig nálam van.
Vagy a leggyakrabban használt gép be van állítva megbízható gépnek, és csak az idegen helyen való bejelentkezéshez van használva?
Tényleg érdekel, hogy milyen pluszt ad a gyakorlatban. Hogy érdemes használni.
- A hozzászóláshoz be kell jelentkezni
jelent-e plusz biztonságot?
Igen, nagyon sok hardveres vedelem van benne arra, hogy ne lehessen duplikalni, kiolvasni belole az informaciot.
Vagy a leggyakrabban használt gép be van állítva megbízható gépnek, és csak az idegen helyen való bejelentkezéshez van használva?
Ez altalaban rad van bizva. Ha elmented a gepet akkor igen, ennyi.
Tényleg érdekel, hogy milyen pluszt ad a gyakorlatban. Hogy érdemes használni.
Van benne TRNG. Nekem a kulcsomat is ez generalta es soha nem hagyja el a belsejet, olyan mint egy smartcard.
Minden software megoldas, igazabol csak egy hack :)
- A hozzászóláshoz be kell jelentkezni
Tehát azért biztonságosabb, mert a telefonomat feltörhetik távolról, a hardveres megoldást fizikailag is meg kell szerezni?
A szoftveres megoldásokat nevezhetjük simán hacknek, de a szoftveres megoldásokkal könnyebb alkalmazkodni az aktuális körülményekhez.
- A hozzászóláshoz be kell jelentkezni
a telefonomat feltörhetik távolról, a hardveres megoldást fizikailag is meg kell szerezni?
Amikor regisztralod a authenticatort altalaban beolvasol egy QR kodot. Ha az megvan barkinek akkor ugyanazt az OTP-t tudja generalni. Masik, hogy megbizolt egy 3rd partyban.
A szoftveres megoldásokat nevezhetjük simán hacknek, de a szoftveres megoldásokkal könnyebb alkalmazkodni az aktuális körülményekhez.
Ez igy van. Igy mindig fel kell merni, hogy mit vedunk, mekkora a kockazat es jonnek meg az anyagiak is.
Barcsak mindenhol lenne lehetoseg softveres OTP hasznalatara.
- A hozzászóláshoz be kell jelentkezni
Pont azért szoktam rákérdezni, hogy kapjak személyes véleményeket, tapasztalatokat, hogy könnyebb legyen a kockázatokat meghatározni.
- A hozzászóláshoz be kell jelentkezni
Az U2F funkcioja miatt valoszinuleg nem erdemes ilyet venni.
- A hozzászóláshoz be kell jelentkezni
Ha lehet hinni a leírásoknak, a WireGuard VPN rejtőzködő üzemmódban figyel UDP-n: nem válaszol olyan kérésre, ami nem megfelelő kulccsal érkezik. Elvileg így nem lehet észrevenni szkenneléssel. Eleve nincs egy meghatározott port, én 50000 fölé szoktam állítani.
- A hozzászóláshoz be kell jelentkezni
Ez igy van, en ki is probaltam ezt regen!
- A hozzászóláshoz be kell jelentkezni
Nálam is sok próbálkozás van a magas porton elérhető ssh-n, és még attól is több a port szkennelés az otthoni routeren. Tényleg nagyon megugrott az utóbbi időben.
Nem csak a közvetlen támadások (gagyi próbálkozások) miatt teszem el magasabb portra az ssh-t, ..., hanem hogy egyszerűen feketelistához tudjam adni a próbálkozó IP-ket. Ma port szkennelésre, ssh törésre használják a botnetet, holnap már nem érdekel mire, mert tűzfalon tiltva vannak. Tudom, hogy nem az ilyen "védelmektől" alszik nyugodtan az ember, változnak az IP-k,... de egy kis plusz, amit könnyen be tudok állítani az otthoni routeren.
- A hozzászóláshoz be kell jelentkezni
Ha már így szóba került, hogy több támadás éri az otthoni eszközöket, érdekel, hogy van-e olyan, aki átnézte a saját rendszerét, hogy minden rendben van-e? Esetleg módosított-e valamit?
- A hozzászóláshoz be kell jelentkezni
Ummm, azt hiszem en nyeretem :)
# lastb | awk '/ssh/ {printf("%s\t%s\t%s\n", $1, $2, $3);}' | sort -u | wc -l
499113
#
Ez egy dev szerver ami lehet, hogy itt ott dodgy egy kicsit - a prod parjanal csak 3-4k ilyen probalkozas van.
- A hozzászóláshoz be kell jelentkezni